queues. Try to have a set of these per port when possible, fall back
to sharing a common pool between all ports otherwise.
- One control queue per port (used to be one per hardware channel).
- t4_eth_rx now handles Ethernet rx only.
- sysctls to display pidx/cidx for some queues.
MFC after: 1 week
filters working. (All other filters - switch without L2 info rewrite,
steer, and drop - were already fully-functional).
Some contrived examples of "switch" filters with L2 rewriting:
# cxgbetool t4nex0 iport 0 dport 80 action switch vlan +9 eport 3
Intercept all packets received on physical port 0 with TCP port 80 as
destination, insert a vlan tag with VID 9, and send them out of port 3.
# cxgbetool t4nex0 sip 192.168.1.1/32 ivlan 5 action switch \
vlan =9 smac aa:bb:cc:dd:ee:ff eport 0
Intercept all packets (received on any port) with source IP address
192.168.1.1 and VLAN id 5, rewrite the VLAN id to 9, rewrite source mac
to aa:bb:cc:dd:ee:ff, and send it out of port 0.
MFC after: 1 week
hardware supports it.
Since ni->ni_htcap in hostap mode is what the remote end has advertised,
not what has been negotiated/decided, we need to check ourselves what
the current channel width is and what the hardware supports before
enabling short-GI.
It's important that short-GI isn't enabled when it isn't negotiated
and when the hardware doesn't support it (ie, short-gi for 20mhz channels
on any chip < AR9287.)
I've quickly verified this on the AR9285 in 11n mode.
1. Both mmc_read_ivar() and sdhci_read_ivar() use the expression
'*(int *)result = val' to assign to result which is uintptr_t *.
This does not work on big-endian 64 bit systems.
2. The media_size ivar is declared as 'off_t' which does not fit
into uintptr_t in 32bit systems, change this to long.
Submitted by: kanthms at netlogicmicro com (initial version)
This has been disabled until now because there hasn't been any supported
device which has this feature. Since the AR9287 is the first device to
support it, and since now the HAL has functional AR9287+11n support,
flip this on.
which uses a non-standard clock (* 8) while any additional ports use
SUN1699 chips which use a standard clock.
Tested by: N.J. Mann njm of njm me uk
MFC after: 1 week
MCR register on the Sunix Sun1699 chip tends to be set but doesn't
seem to have a function. That is, FreeBSD just works (provided the
correct RCLK is used) regardless.
PR: kern/129663
Diagnostics: Eygene Ryabinkin <rea-fbsd at codelabs.ru>
MFC after: 3 days
AR9287 EEPROM layout.
The AR9287 only supports 2ghz, so I've removed the 5ghz code (but left
the 5ghz edge flags in there for now) and hard-coded the 2ghz-only
path.
Whilst I'm there, fix a typo (ar9285->ar9287.)
This meets basic TX throughput testing - iperf TX tests == 27-28mbit in 11g,
matching the rest of my 11g kit.
I'm assuming for now that the AR9287 is only open-loop TX power control
(as mine is) so I've hard-coded the attach path to fail if the NIC is
not open-loop.
This greatly simplifies the TX calibration path and the amount of code
which needs to be ported over.
This still isn't complete - the rate calculation code still needs to be
ported and it all needs to be glued together.
Obtained from: Linux ath9k
without waiting for device readiness (or at least not updating FIS receive
area in time). To workaround that, special quirk was added earlier to wait
for the FIS receive area update. But it was found that under same PCI ID
0x91231b4b and revision 0x11 there are two completely different chip
versions (firmware?): HBA and RAID. The problem is that RAID version in
some cases, such as hot-plug, does not update FIS receive area at all!
To workaround that, differentiate the chip versions by their capabilities,
and, if RAID version found, skip FIS receive area update waiting and read
device signature from the PxSIG register instead. This method doesn't work
for HBA version when PMP attached, so keep using previous workaround there.
It isn't linked into the build because it's missing the TX power
and PDADC programming code.
This code is mostly based on the ath9k codebase, compared against
the Atheros codebase as appropriate.
What's implemented:
* probe/attach
* EEPROM board value programming
* RX initial calibration
* radio channel programming
* general MAC / baseband setup
* async fifo setup
* open-loop tx power calibration
What's missing before it can be enabled by default:
* TX power / calibration setting code
* closed-loop tx power calibration routines
* TSF2 handling
* generic timer support from ath9k
Obtained from: Atheros, ath9k
(SEMB) is unable to communicate to Storage Enclosure Processor (SEP), in
response to hard and soft resets it should among other things return value
0x7F in Status register. The weird side is that it means DRQ bit set, which
tells that reset request is not completed. It would be fine if SEMB was the
only device on port. But if SEMB connected to PMP or built into it, it may
block access to other devices sharing same SATA port.
Make some tunings/fixes to soft-reset handling to workaround the issue:
- ahci(4): request CLO on the port after soft reset to ignore DRQ bit;
- siis(4): gracefully reinitialize port after soft reset timeout (hardware
doesn't detect reset request completion in this case);
- mvs(4): if PMP is used, send dummy soft-reset to the PMP port to make it
clear DRQ bit for us.
For now this makes quirks in ata_pmp.c, hiding SEMB ports of SiI3726/SiI4726
PMPs, less important. Further, if hardware permit, I hope to implement real
SEMB support.
values for the commands, compared to the internal command values
(HAL_ANI_CMD.)
My eventual aim is to make the HAL_ANI_CMD internal enum match
the public API and then remove all this messiness.
This now allows HAL_CAP_INTMIT users to use a public HAL_CAP_INTMIT_
enum rather than magic constants.
The only magic constants currently used by if_ath are "enable" and
"present". Some local tools of mine allow for direct, manual fiddling
of the ANI variables and I'll convert these to use the public enum API
before I commit them.
of the ANI statistics and committing some tools which use these.
* Change HAL_ANI_* commands _back_ to be numerical, rather than a
bitmap;
* modify access to the ANI control bitmap to convert a command to
a bitmap;
* Fix the ANI noise immunity fiddling for CCK errors - it wasn't
checking whether noise immunity was disabled or not.
which did AR5212 specific initialisation. This would cause some slight
silliness when enabling/disabling ANI.
Just to be completely correct - and to ensure the phy error mask/RX filter
register isn't incorrectly played with - make the ANI control function a
method, have it set appropriately for AR5212/AR5416, and call that from the
ANI control interface.
This should hopefully make it clearer to developers what is going on
and when TPC is being hacked on, make it obvious why it isn't working for
series 1, 2, 3.
I won't flip on setting TX power for TX series 1, 2, 3 until I've done
some further testing with Kite to ensure it doesn't break anything.
(Before people ask - yes, TPC is only needed for 5ghz regdomains and
yes, Kite is a 2.4ghz only chip, but there are potential use cases
for 2ghz TPC. I just need to sit down and ensure it's supported and
functional.)
control the antenna control bits for the four TX series and the
TPC settings for TX series 1, 2, 3.
The specifics:
* The TPC setting for TX series 0 is handled in ctl0.
* TPC is currently disabled, so the per-packet TX power is
set via the global per-rate TX power register, not per packet.
* The antenna control bits don't matter for AR5416 and later
so they should stay 0 (which they currently do); they may
be set for Kite but as there's no TX diversity supported
at the moment (it requires the NIC to be built with an
external antenna switch, matching how antenna diversity
is done on legacy NICs), so again keep them 0.
This is in preparation for supporting per-rate TPC on the
AR5416 and later. The Kite (and soon to come Kiwi) code
sets ctl8-11 to 0x0, which doesn't have any effect at
the moment. When TPC is enabled it would result in the
second, third and fourth TX series attmpts to be done with
a TX power of 0. This commit doesn't change that; it'll
be followed up with some commits to properly set the TPC
registers appropriately.
quality to 950. HPET on modern platforms usually have better resolution and
lower latency than ACPI timer. Effectively this changes default timecounter
hardware from ACPI-fast to HPET by default when both are available.
Discussed with: avg
bits of the register is used for other purposes such that clearing
these bits resulted in unexpected results such as corrupted RX
frames or missing LE status updates. For old controllers like
Yukon EC it had no effect but it caused all kind of troubles on
Yukon Supreme.
This change shall improve stability of controllers like Yukon
Ultra, Ultra2, Extreme, Optima and Supreme.
Rewrite atomic operations for powerpc in order to achieve the following:
- Produce a type-clean implementation (in terms of functions arguments
and returned values) for the primitives.
- Fix errors with _long() atomics where they ended up with the wrong
arguments to be accepted.
- Follow the sys/type.h specifics that define the numbered types starting
from standard C types.
- Let _ptr() version to not auto-magically cast arguments, but leave
the burden on callers, as _ptr() atomic is intended to be used
relatively rarely.
Fix cfi in order to support the latest point.
In collabouration with: bde
Tested by: andreast, nwhitehorn, jceel
MFC after: 2 weeks
which is now disabled by default. The detection is known to cause hangs
on boot with some new Lenovo laptops on FreeBSD/amd64.
Reported by: gnn
Discussed with: jkim
MFC after: 3 months
not true on old PCI based controllers. DAC configuration is read
from EEPROM in device reset phase and driver can override DAC
configuration. However I guess there is an undocumented reason why
EEPROM configuration does not enable DAC so do not blindly override
DAC configuration. Recent PCIe based controllers are supposed to
support 64bit DMA so allow 64bit DMA only on PCIe based controllers.
PR: kern/157184
MFC after: 1 week
IFF_DRV_RUNNING flag. Previously running dhclient or adding alias
addresses reinitialized controller and it resulted in unnecessary
link flips.
Reviewed by: marius
Oxford Semiconductor OX16PCI954 but uses only two ports with a non-default
clock rate.
PR: kern/152034
Tested by: Hans Fiedler hans of hermes louisville edu
MFC after: 1 week
This brings USB bus more in line with how newbus is supposed to be used.
Also, because of the two-pass probing the following message was produced
by devd in default configuration when almost any USB device was
connected:
Unknown USB device: vendor <> product <> bus <>
This should be fixed now.
Note that many USB device drivers pass some information from probe
method to attach method via ivars. For this to continue working we rely
on the fact that the subr_bus code calls probe method of a winning driver
again before calling its attach method in the case where multiple
drivers claim to support a device. This is done because device
description is set in successful probe methods and we want to get a correct
device description from a winning driver. So now this logic is re-used
for setting ivars too.
Reviewed by: hselasky
MFC after: 1 month
When supported by hardware, this allows to control per-port activity, locate
and fault LEDs via the led(4) API for localization and status reporting
purposes. Supporting AHCI controllers may transmit that information to the
backplane controllers via SGPIO interface. Backplane controllers interpret
received statuses in some way (IBPI standard) to report them using present
indicators.
the multicast key search support for AR5212, AR5416 and later.
The general HAL routine ath_hal_getcapability() implement checking this
but it's overridden by a check in ar5212_misc:ar5212GetCapability().
This restores the later functionality in case it's found to be broken
in any of the 11n chipsets.
The other queues, especially the command queue, uses the FIFO mode
which doesn't require the byte count table because queued entries are
processed in order.
Pointed out by: Lucius Windschuh <lwindschuh at googlemail dot com>
Since the returned NF will be -ve, checking for <= 0 is not good
enough. For now, check whether it equals 0 or -1; a future commit
will tidy this mess up and have it return HAL_BOOL instead.
The eeprom Get method should return HAL_OK if fastclock is enabled in the
EEPROM. It was returning the opposite of what it should have.
Submitted by: Matthew Fleming <mdf356@gmail.com>
The code assumed it could return HAL_OK, HAL_EINVAL and other
HAL_STATUS types; so it shouldn't be declared as returning HAL_BOOL.
This commit was brought to you by the Clang compiler.
Submitted by: Matthew Fleming <mdf356@gmail.com>
I've tested this locally and it does indeed read and attach to an AR9287
EEPROM. But a lot more code needs to be ported over to the HAL before
the AR9287 is functional.
I'm importing this separate from the rest of the codebase (and unlinked from
the build for now) in case someone wishes to begin fiddling with porting
the rest of the code over from Linux ath9k.
Obtained from: Linux ath9k
is totally disabled.
The Atheros HAL code does this for Sowl/Howl but not for Owl (AR5416) where
RIFS is disabled by default.
This seems to quieten the occasional baseband hang I've been seeing with
the AR9160 in STA mode under constant heavy traffic load.
Obtained from: Atheros
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.
Reviewed by: marius
Tested by: sbruno
Approved by: re
architectures (i386, for example) the virtual memory space may be
constrained enough that 2MB is a large chunk. Use 64K for arches
other than amd64 and ia64, with special handling for sparc64 due to
differing hardware.
Also commit the comment changes to kmem_init_zero_region() that I
missed due to not saving the file. (Darn the unfamiliar development
environment).
Arch maintainers, please feel free to adjust ZERO_REGION_SIZE as you
see fit.
Requested by: alc
MFC after: 1 week
MFC with: r221853
that for _ptr operations, when not used directly with uintptr_t, we
needed to manually cast.
Use the cast on the _ptr version, where it actually wasn't (please note
that i386 doesn't get it right, while amd64 doesn't seem to compile
cfi neither in LINT, that is why it doesn't fail).
Reported by: sbruno
for the AR9280 based NICs if it's actually enabled.
Some of the OLC code was erroneously called during setup
and calibration. This may have caused some incorrect behaviour.
table which contains the per-rate target TX power.
This code is shared between the v14 eeprom board setup (AR5416, AR9160,
AR9280) and will also be used by the upcoming Kite (AR9287) support.
* grab the main, alt and selected LNA config
* add some optional / disabled logging code
* add a check to reject packets with an invalid main rssi too,
in case the alt is the active receive chain and main is -ve.
Note: The software-controlled combined diversity code is still disabled.
- Use bus_bind_intr() to bind interrupt to a CPU when RSS/TSS is used.
- Use M_DONTWAIT for RSS/TSS buffer allocation.
- Add statistic to track max DRBR queue depth.
- Fix problem in bxe_change_mtu() which referenced the old MTU size
in a debug print statement.
MFC after: Two weeks
disabled for BCM5719 A0 revision due to known hardware errata.
Many thanks to Broadcom for continuing support of FreeBSD.
Submitted by: Geans Pin at Broadcom
AR8132 FastEthernet controller. The PHY has no ability to
establish a gigabit link. Previously only link parters which
support down-shifting was able to establish link.
This change should fix a long standing link establishment issue of
AR8132.
PR: kern/156935
MFC after: 1 week
Casting a pointer to a wide integer is probably not that bad, but I am
still guilty of not testing this.
Pointyhat to: avg
MFC after: 1 week
X-MFC with: r221803
This brings our implementation in line with OSS specification for
systems that support mmap. The change should also improve compatibility
with OSS software not specifically written for FreeBSD, e.g. PulseAudio
OSS plugin.
Reviewed by: kib, jhb
MFC after: 1 week
environments.
In setups where NF calibration can take a while, don't load the CCA
and kick off a new NF calibration if the previous one hasn't yet
completed. This shouldn't happen unless the environment is noisy but
those exist (hi phk!).
Here, if the previous NF hasn't completed when ar5416LoadNf() is run
(which reads the NF), it skips updating the history buffer, loading
the NF CCA array and kicking off the next NF cal. It's hoped it'll
occur in the next long calibration interval.
Obtained from: Atheros, ath9k, my local HAL
This is taking quite a while for some people in some situations
(eg AR5418 in phk's Abusive Radio Environment).
Instead, the rest of the calibration related code should
ensure that a NF calibration has occured before reading NF
values and kicking off another NF calibration.
The channel should also likely be marked as "noisy" (CWINT)
if the NF calibration takes too long.
* Correct some of the silicon revision checks to match what
the Atheros HAL does. (See [1] below.)
* Move the PA cal and init cal method assignment to -after-
the mac version/revision IDs are stored. The AR9285 init
cal was never being called.
* Enable ANI.
Note Kite 1.0 and 1.1 were prototypes that shouldn't be seen
in the wild. Linux ath9k simply removed the prototype code from
their codebase. I'm going to leave it in there for now but
make it conditionally compilable in the future.
Obtained from: Atheros
newer controllers. However, all data sheet I have access has no
indication that buffer manager should not be touched on these
controllers. It seems the buffer manager always runs on BCM5705 or
newer controllers. Some controller(e.g. BCM5719) needs other buffer
manager configuration so driver should enable buffer manager for
all controllers. Both Linux and OpenBSD/NetBSD use the same
approach.
This change polls enable bit of block to know whether specified
block was really stopped as well as enabling buffer manager for all
controllers in driver initialization.
Obtained from: NetBSD
from Atheros as to what/when this is supposed to be enabled.
Using the default RX fast diversity settings seems to help quite
a bit.
Whilst I'm here, change the prototype to return HAL_BOOL rather than int.
For now, the diversity settings are controlled by 'txantenna',
-not- rxantenna. This is because the earlier chipsets had
controllable TX diversity; the RX antenna setting twiddles
the default antenna register. I'll try sort that stuff out at
some point.
Call the antenna switch function from the board setup function
so scans, channel changes, mode changes, etc don't set the
diversity back to a default state too far from what's intended.
Things to todo:
* Squirrel away the last antenna diversity/combining parameters
and restore them during board setup if HAL_ANT_VARIABLE is
defined. That way scans, etc don't reset the diversity settings.
* Add some more public facing statistics, rather than what's
simply logged under HAL_DEBUG_DIVERSITY.
For now, the fixed antenna settings behave better than variable
settings for me. I have some further fiddling to do..
Obtained from: Atheros
The macro which I incorrectly copied into ah_internal.h assumed
that it'd be called with an AR_SREV_MERLIN_20() check to ensure
it was only enabled for Merlin (AR9280) silicon revision 2.0 or
later.
Trouble is, the 5GHz fast clock EEPROM flag is only valid for
EEPROM revision 16 or greater; it's assumed to be enabled
by default for Merlin rev >= 2.0. This meant it'd be incorrectly
set for AR5416 and AR9160 in 5GHz mode.
This would have affected non-default clock timings such as SIFS,
ACK and slot time. The incorrect slot time was very likely wrong
for 5ghz mode.
* Modify AR_SREV_MERLIN_20() to match the Atheros/Linux ath9k behaviour -
its supposed to match Merlin 2.0 and later Merlin chips.
AR_SREV_MERLIN_20_OR_LATER() matches AR9280 2.0 and later chips
(AR9285, AR9287, etc.)
- instead of calling iwn_plcp_signal() for every frame, map the expected
value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
by the hardware are not conform to the std
On legacy channels every once in a while the firmware throws a SYSASSERT
on line 208. On HT channels though this does always happen and I'm not
aware of any workaround currently.
for the given channel is available.
It isn't used yet; ar5416GetWirelessModes() needs to be taught
about this rather than assuming HT20/HT40 is available.
This seems to make the AR9160 behave better during heavy scanning,
where before it'd hang and require a hard reset to recover.
Obtained From: Linux ath9k, Atheros
modifying AR_DIAG_SW.
There's a hardware workaround which sets disabling some errors
early at startup and clears said bits before the PCU begins
receiving - it does this to avoid RX descriptor status errors.
It's possible these bits aren't being completely properly twiddled
in all instances; but in particular if the diag_reg HAL variable
is set it won't be setting these bits correctly. I'll review this
at some point.
* Disable multicast search on mac address and key id - the driver
doesn't use it at the moment and thus adhoc may be broken for
merlin and later.
* Change this to be for Merlin 1.0 (which from what I understand
wasn't ever publicly released) to be more correct.
Apparently all three RX chains need to be enabled before initial calibration
is done, even if only two are configured.
Reorder the alt chain swap bit to match what the Atheros HAL is doing.
Obtained From: ath9k, Atheros
* Shuffle some of the capability numbers around to match the
Atheros HAL capability IDs, just for consistency.
* Add some new capabilities to FreeBSD from the Atheros
HAL which will be be shortly used when new chipsets are added
(HAL SGI-20 support is for Kiwi/AR9287 support); for
TX aggregation (MBSSID aggregate support, WDS aggregation
support); CST/GTT support for carrier sense/TX timeout.
channel when the channel is HT/40.
The new ANI code (primarily for the AR9300/AR9400) in ath9k sets this
register but the ANI code for the previous 11n chips didn't set this.
Unlike ath9k, only set this for HT/40 channels.
Obtained From: ath9k
These describe FCC/Japan channel and DFS behaviour.
The AR9285 and later chips don't set these bits in the eeprom, the correct
behaviour is to just assume all five bits are enabled.
specific.
The Atheros HAL and FreeBSD HAL share the same capabilities up
until HAL_CAP_11D, where things begin to diverge.
I'll look at tidying these up soon.
Obtained from: Atheros
* Add Howl (ar9130) to the list of chips that have DFS/BB/MAC hangs
* Don't treat unknown BB hangs as fatal; ath9k/Atheros HAL don't
treat it as such.
* Add HAL_DEBUG_DFS to the debug fields in ath_hal/ah_debug.h
The BB hang check simply loops over an observation register checking
for a stuck state engine, but it can happen under high traffic
conditions. Ath9k and the Atheros HAL simply log a debug message and
continue.
Private to FreeBSD:
* Add HAL_DEBUG_HANG to the debug fields
* Change the hang debugging to HAL_DEBUG_HANG rather than HAL_DEBUG_DFS
like in the Atheros HAL.
Obtained from: Atheros
For now, these are equivalent macros. AR_SREV_OWL{X}_OR_LATER
will later change to exclude Howl (AR9130) in line with what
the Atheros HAL does.
This should not functionally change anything.
Obtained from: Atheros
A quick story, which is partially documented in the commit.
The silicon revision in Linux ath9k and the Atheros HAL use an
AR_SREV_REVISION mask of 0x07.
FreeBSD's HAL uses the AR5212 AR_SREV_REVISION mask of 0x0F.
Thus the OWL silicon revisions were coming through as 0xA, 0xB,
0xC, rather than 0x0, 0x1 and 0x2.
My ath9k-sourced AR_SREV_OWL_<X> macros were thus using the wrong
silicon revision values and wouldn't correctly match.
This commit does a few things:
* Change the AR_SREV_OWL_<x> macros to use the AR_SREV_REVISION_OWL_*
values, not AR_XSREV_REVISION_OWL macros;
* Disable AR_XSREV_REVISION_OWL_* values;
* Modify the IS_5416 to properly check the MAC is OWL, rather than
potentially matching on non-OWL revisions (which shouldn't happen
unless there's a silicon revision of higher than 0x9 in a later
chip..)
* Add a couple more macros from the Atheros HAL for compatibility.
The main difference now is that the Atheros HAL defines
AR_SREV_OWL_{20,22}_OR_LATER subtly differently - it fails on all HOWL
silicon. The AR_SREV_5416_*_OR_LATER macros match on the relevant OWL
version -and- all HOWL versions, along with subsequent versions.
A subsequent commit is going to migrate the uses of AR_SREV_OWL_X_OR_LATER
to AR_SREV_5416_X_OR_LATER to match what's going on in the Atheros HAL.
There's only two uses of AR_SREV_OWL_X_OR_LATER which currently don't
apply to FreeBSD but it may do in the future.
Yes, it's all confusing!
tick driving logic to xl_tick(). Now xl_tick() handles MII tick as
well as periodic updating of statistics.
This change removes a hack used in interrupt handler where it
wanted to update statistics without driving MII tick.
picking the next available one. This may explain why xl(4) sees TX
underrun error with no queued frame. I hope this addresses a long
standing xl(4) watchdog timeout issue as well.
Obtained from: OpenBSD
RX descriptor ring. Previously it returned the number of frames
that were successfully passed to upper stack which in turn means it
ignored frames that were discarded due to errors. The number of
processed frames in RX descriptor ring is used to detect whether
driver is out of sync with controller's current descriptor pointer.
Returning number of processed frames reduces unnecessary (probably
wrong) re-synchronization.
While here, remove unnecessary local variable initialization.
handler for 3C90x and 3C90xB/C respectively. This simplifies ioctl
handler as well as enhancing readability.
While I'm here don't reprogram multicast filter when driver is not
running.
