For these devices, the number of supported ports is read from a register
in BAR 0.
PR: kern/134878
Submitted by: David Wood david of wood2 org uk
MFC after: 1 week
The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.
The specifics:
* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130.
This is needed due to the different location the RTC registers live
with this chip; hopefully this will be undone in the future.
This does currently mean that enabling this option will break non-AR9130
builds, so don't enable it unless you're specifically building an image
for the AR913x SoC.
* Add the new probe, attach, EEPROM and PLL methods specific to Howl.
* Add a work-around to ah_eeprom_v14.c which disables some of the checks
for endian-ness and magic in the EEPROM image if an eepromdata block
is provided. This'll be fixed at a later stage by porting the ath9k
probe code and making sure it doesn't break in other setups (which
my previous attempt at this did.)
* Sprinkle Howl modifications throughput the interrupt path - it doesn't
implement the SYNC interrupt registers, so ignore those.
* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods
were
* Sprinkle some other Howl workarounds in the reset path.
* Hard-code an alternative setup for the AR_CFG register for Howl, that
sets up things suitable for Big-Endian MIPS (which is the only platform
this chip is glued to.)
This has been tested on the AR913x based TP-Link WR-1043nd mode, in
legacy, HT/20 and HT/40 modes.
Caveats:
* 2ghz has only been tested. I've not seen any 5ghz radios glued to this
chipset so I can't test it.
* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least,
it isn't implemented in ath9k. Please don't enable this.
* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.
allocated, not the maximum number of messages the device supports. The
spec only requires the former, and I believe I implemented the latter due
to misunderstanding an e-mail. In particular, this fixes an issue where
having several devices that all support 16 messages can run out of
IDT vectors on x86 even though the driver only uses a single message.
Submitted by: Bret Ketchum bcketchum of gmail
MFC after: 1 week
adding appropriate #ifdefs. For module builds the framework needs
adjustments for at least carp.
Reviewed by: gnn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after: 4 days
the watchdog, via the watchdog(9) interface.
For that, the WD_LASTVAL bitwise operation is used. It is mutually
exclusive with any explicit timout passing to the watchdogs.
The last timeout can be returned via the wdog_kern_last_timeout()
KPI.
- Add the possibility to pat the watchdogs installed via the watchdog(9)
interface from the kernel.
In order to do that the new KPI wdog_kern_pat() is offered and it does
accept normalized nanoseconds or WD_LASTVAL.
- Avoid to pass WD_ACTIVE down in the watchdog handlers. All the control
bit processing should over to the upper layer functions and not passed
down to the handlers at all.
These changes are intended to be used in order to fix up the watchdog
tripping in situation when the userland is busted, but protection is still
wanted (examples: shutdown syncing / disk dumping).
Sponsored by: Sandvine Incorporated
Reviewed by: emaste, des, cognet
MFC after: 2 weeks
will generate a short terminated USB transfer if
the maximum NCM frame size is greater than what
the driver can handle.
Reported by: Matthias Benesch
MFC after: 7 days
Approved by: thompsa (mentor)
- Also a couple minor tweaks to the TX code from the same source.
- Add the INET ioctl code which has been missing from this driver,
and which caused IP aliases to reset the interface.
- Last, some minor logic changes that just reflect upcoming
hardware support, but have no other functional effect now.
MFC after a week
Writing the TX power registers is the same between all of these chips
and later NICs (AR9287, AR9271 USB, etc.) so this will reduce code
duplication when those NICs are added to the HAL.
spurious (and fatal) interrupt errors.
One user reported seeing this:
Apr 22 18:04:24 ceres kernel: ar5416GetPendingInterrupts: fatal error,
ISR_RAC 0x0 SYNC_CAUSE 0x2000
SYNC_CAUSE of 0x2000 is AR_INTR_SYNC_LOCAL_TIMEOUT which is a bus timeout;
this shouldn't cause HAL_INT_FATAL to be set.
After checking out ath9k, ath9k_ar9002_hw_get_isr() clears (*masked)
before continuing, regardless of whether any bits in the ISR registers
are set. So if AR_INTR_SYNC_CAUSE is set to something that isn't
treated as fatal, and AR_ISR isn't read or is read and is 0, then
(*masked) wouldn't be cleared. Thus any of the existing bits set
that were passed in would be preserved in the output.
The caller in if_ath - ath_intr() - wasn't setting the masked value
to 0 before calling ath_hal_getisr(), so anything that was present
in that uninitialised variable would be preserved in the case above
of AR_ISR=0, AR_INTR_SYNC_CAUSE != 0; and if the HAL_INT_FATAL bit
was set, a fatal condition would be interpreted and the chip was
reset.
This patch does the following:
* ath_intr() - set masked to 0 before calling ath_hal_getisr();
* ar5416GetPendingInterrupts() - clear (*masked) before processing
continues; so if the interrupt source is AR_INTR_SYNC_CAUSE
and it isn't fatal, the hardware isn't reset via returning
HAL_INT_FATAL.
This doesn't fix any underlying errors which trigger
AR_INTR_SYNC_LOCAL_TIMEOUT - which is a bus timeout of some
sort - so that likely should be further investigated.
- Centralize PCI resource allocation/release.
- Enable flowid (TSS) support.
- Added "per-fastpath" locks and watchdog timeouts.
- Fixed problem where the CQ producer index was advanced beyond
the size of the CQ ring during initialization.
- Replaced hard-coded debug levels in some debug print statements.
- More style(9) fixes.
MFC after: Two weeks
should respond with all zeroes to any access to slave registers. Test with
PATA devices confirmed such behavior. Unluckily, Intel SATA controllers in
legacy emulation mode behave differently, not making any difference between
ATA and ATAPI devices. It causes false positive slave device detection and,
as result, command timeouts.
To workaround this problem, mask result of legacy-emulated soft-reset with
the device presence information received from the SATA-specific registers.
- TCO_MESSAGEx: TCO specific regs providing the ability to monitor BIOS
bootup activity.
- TCO_NEWCENTURY: reporting RTC year roll over.
- TCO_NMI2SMI_EN, TCO_NMI_NOW: controlling SMIs conversion to NMIs and
NMI trigger.
- SMI_GBL_EN: Enabling SMI delivery for all the northbridge controller.
MFC after: 10 days
This improves hard-reset and hot-plug on these ports.
- Device with ID 0x29218086 is a 2-port variant of ICH9 in legacy mode.
Skip probing for nonexistent slave devices there.
It allows to avoid false positive device detection under Xen, that caused
long probe delays due to subsequent IDENTIFY command timeouts.
MFC after: 1 month
that could have allowed the hardware pidx to reach the cidx even though
the freelist isn't empty. (Haven't actually seen this but it was there
waiting to happen..)
MFC after: 1 week
