down. The ingress queue lock was unused and has been removed as part of
these changes.
- An in-flight egress update from the SGE must be handled before the
queue that requested it is destroyed. Wait for the update to arrive.
- Interrupt handlers must stop processing rx events for a queue before
the queue is destroyed. Events that have not yet been processed
should be ignored once the queue disappears.
MFC after: 1 week
from scratch. Remove htole16() calls, rxon.chan is an uint8_t,
ieee80211_chan2ieee() does return an ic_ieee as an int, but I heavily
doubt a htole16() will buy us anything here.
- IWN_TXOP_TO_US is equal to IEEE80211_TXOP_TO_US
- use IEEE80211_DUR_TU
- ieee80211_add_rates/ieee80211_add_xrates are public, use em
- copied ieee80211_add_ssid it is not public
Instead of spinning in a tight loop for up to 15 seconds, polling for device
readiness while it spins up, return reset completion just after PHY reports
"connect well" or 100ms connection timeout. If device was found, use callout
for checking device readiness with 100ms period up to full 31 second timeout.
This fixes system freeze for 5-10 seconds on drives hot plug-in.
- make SATA SIMs announce capabilities to handle SDB with Notification bit;
- make PMP driver honor this SIMs capability;
- make SATA XPT to negotiate and enable this feature for ATAPI devices.
This feature allows supporting SATA ATAPI devices to inform system about
some events happened, that may require attention. In my case this allows
LG GH22LS50 SATA DVR-RW drive to report tray open/close events. Events
reported to CAM in form of AC_SCSI_AEN async. Further they could be used
as a hints for checking device status and reporting media change to upper
layers, for example, via spoiling mechanism of GEOM.
diversity.
This is bit dirty and likely should be revised at a later date,
with an eye to unifying/tidying up the whole diversity setup
and allowing developers to do "tricky stuff" as they desire.
For now, this works.
* add a new method, specifically for doing per-RX packet
antenna diversity
* set that HAL method only if it's Kite and a Kite chip that
does diversity.
* add a diversity flag to the HAL debugging section
* add a check to make sure the kite diversity code doesn't run
on boards that don't require it, as not all Kite chips will
implement it.
* add some debug statements when the diversity code makes
changes to the antenna diversity/combining setup.
controller port readiness (that should set just after PHY ready signal),
reduce wait time from 10s to 1s before trying more aggressive reset method.
This should improve system responsibility in some failure conditions.
Note: this HAL currently only supports the AR9285.
From Linux ath9k:
The problem is that when the attenuation is increased,
the rate will start to drop from MCS7 -> MCS6, and finally
will see MCS1 -> CCK_11Mbps. When the rate is changed b/w
CCK and OFDM, it will use register desired_scale to calculate
how much tx gain need to change.
The output power with the same tx gain for CCK and OFDM modulated
signals are different. This difference is constant for AR9280
but not AR9285/AR9271. It has different PA architecture
a constant. So it should be calibrated against this PA
characteristic.
The driver has to read the calibrated values from EEPROM and set
the tx power registers accordingly.
Instead of spinning in a tight loop for up to 15 seconds, polling for device
readiness while it spins up, return reset completion just after PHY reports
"connect well" or 100ms connection timeout. If device was found, use callout
for checking device readiness with 100ms period up to full 31 second timeout.
This fixes system freeze for 5-10 seconds on drives hot plug-in.
bus driver at detach, hence ehci_detach() does exactly this since r199718.
Submitted by: Luiz Otavio O Souza
MFC after: 7 days
Approved by: thompsa (mentor)
SCSI status errors to CAM (that was wrong, as it too often turned retriable
wire errors into non-retriable REQUEST SENSE errors), do it only for STALL
errors on control pipe of the CBI devices. STALL on control pipe is just
a one of the ways to report error for CBI devices.
PR: usb/150401, usb/154593.
Reviewed by: hselasky
MFC after: 1 week
ctl/ext noise floor values.
This routine doesn't check to see whether the radio is MIMO
capable - instead, it simply returns either the raw values,
the "nominal" values if the raw values aren't yet available
or are invalid, or '0' values if there's no valid channel/
no valid MIMO values.
Callers are expected to verify the radio is a MIMO radio
(which for now means it's an 11n chipset, there are non-11n
MIMO chipsets out there but I don't think we support them,
at least in MIMO mode) before exporting the MIMO values.
upper-level HAL.
Right now the per-chain noise floor values aren't used anywhere in
the upper-level HAL, so the driver currently has no real reference
to compare the per-chain RSSI values to.
This is needed before per-chain RSSI values (for ctl and ext radios)
are can be thrown upstairs to the net80211 code.
safer for i386 because it can be easily over 4 GHz now. More worse, it can
be easily changed by user with 'machdep.tsc_freq' tunable (directly) or
cpufreq(4) (indirectly). Note it is intentionally not used in performance
critical paths to avoid performance regression (but we should, in theory).
Alternatively, we may add "virtual TSC" with lower frequency if maximum
frequency overflows 32 bits (and ignore possible incoherency as we do now).
chain to be corrupted.
- Removed many console print warnings and replaced with driver maintained
counters.
- Several style(9) fixes.
MFC after: One week.
improves command timeout handling.
Many thanks to Areca for continuing to support FreeBSD.
Submitted by: Ching-Lung Huang <ching2048 areca com tw>
MFC after: 2 months
This fixes a long standing bug in mxge(4) where "ifconfig mxge0 $IP"
did not bring the interface into a RUNNING state, like it does on
most (all?) other FreeBSD NIC drivers.
Thanks to gnn for mentioning the bug, and yongari for pointing out that
ether_ioctl() invokes ifp->if_init() in SIOCSIFADDR.
MFC after: 7 days
- Add the change made in em to the actual unrefreshed number
of descriptors is used as a basis in rxeof on the way out
to determine if more refresh is needed. NOTE: there is a
difference in the ring setup in igb, this is not accidental,
it is necessitated by hardware behavior, when you reset the
newer adapters it will not let you write RDH, it ALWAYS sets
it to 0. Thus the way em does it is not possible.
- Change the sysctl handling of flow control, it will now make
the change dynamically when the variable setting changes rather
than requiring a reset.
- Change the eee sysctl naming, validation found the old unintuitive :)
- Last but not least, some important performance tweaks in the TX
path, I found that UDP behavior could be drastically hindered or
improved with just small changes in the start loop. What I have
here is what testing has shown to be the best overall. Its interesting
to note that changing the clean threshold to start at a full half of
the ring, made a BIG difference in performance. I hope that this
will prove to be advantageous for most workloads.
MFC in a week.
show that there are perfectly working PM timers with occasional "hiccups",
probably because of an SMI. Now we ignore the maximum if it happens once in
the test loop and the width is small enough. Also, relax normal width a bit
to count in a boundary case.
Unlike other controllers which have more advanced jumbo support,
these controllers have one send ring, one standard receive producer
ring and one receive return ring. In order to receive jumbo frames
on the controllers, driver now will increase Rx buffer size to 9k.
Two Rx modes are supported on these controllers and I chose
standard Rx BDs over extended Rx BDs. The extended Rx BD mode
allows up to 4 segmentations for each Rx BDs such that kernel does
not have to allocate large buffer of contiguous memory for
receiving. The extended Rx BD mode is already used on controllers
that have separate jumbo receive ring. However, using extended Rx
BDs on BCM5714/BCM5715/BCM5780 reduces the number of Rx BDs to 256
entries which in turn may reduce the performance. Also UMA backed
page allocator for jumbo frame returns contiguous memory so using
extended Rx BD has no advantage on FreeBSD unless highly customized
local allocator implemented in driver is used.
To use jumbo buffers in standard receive ring, Rx buffer allocation
handler was changed to allocate MJUM9BYTES sized mbuf.
PR: kern/155192
Tested by: Vijay Singh <vijju.singh <> gmail dot com>
Submitted by: mjacob (initial version)
on the fact that real hardware has almost fixed cost to read the ACPI timer.
It is virtually always false for hardware emulation and it makes no sense to
read it multiple times, which is already quite expensive for full emulation.
From the ath9k source:
==
11N: we can no longer afford to self link the last descriptor.
MAC acknowledges BA status as long as it copies frames to host
buffer (or rx fifo). This can incorrectly acknowledge packets
to a sender if last desc is self-linked.
==
Since this is useful for pre-AR5416 chips that communicate PHY errors
via error frames rather than by on-chip counters, leave the support
in there, but disable it for AR5416 and later.
- Add more fields for USB device and host mode
- Add more information to USB PF header so that decoding
can easily be done by software analyzer tools like
Wireshark.
- Optimise usbdump to display USB streams in text format
more efficiently.
- Software using USB PF must be recompiled after
this commit, due to structure changes.
MFC after: 7 days
Approved by: thompsa (mentor)
environments into the kernel environment.
The eventual aim is to replace these with specific drivers for
the various bootloaders (redboot, uboot, etc.) This however will
work for the time being until it can be properly addressed.
Submitted by: Aleksandr Rybalko <ray@dlink.ua>
get's defragged due to a mapping failure the header
pointers will be invalidated and can result in a
TSO or other failure down the line. So, when the
remapping occurs force a retry thru the offload
calculation code. Thanks to Andrew Boyer for discovering
this and cooking up the fix!!
to calculate the outstanding descriptors that need to be
refreshed at any time, and use THAT in rxeof to determine
if refreshing needs to be done. Also change the local_timer
to simply fire off the appropriate interrupt rather than
schedule a tasklet, its simpler.
MFC in two weeks
bus driver will now remember the size of a BAR obtained during the initial
bus scan and use that size when doing lazy resource allocation rather than
resizing the BAR. The bus driver will now also report unallocated BARs to
userland for display by 'pciconf -lb'. Psuedo-resources that are not BARs
(such as the implicit I/O port resources for master/slave ATA controllers)
will no longer be listed as BARs in 'pciconf -lb'. During resume, BARs are
restored from their new saved state instead of having the raw registers
saved and restored across resume. This also fixes restoring BARs at
unusual loactions if said BAR has been allocated by a driver.
Add a constant for the offset of the ROM BIOS BAR in PCI-PCI bridges and
properly handle ROM BIOS BARs in PCI-PCI bridges. The PCI bus now also
properly handles the lack of a ROM BIOS BAR in a PCI-Cardbus bridge.
Tested by: jkim
Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'll be added in a subsequent commit.
Kernel configuration files now need both 'ath' and 'ath_pci' devices; both
modules need to be loaded for the ath device to work.
in the RX path when doing 11n and block-ack'ed frames. Apparently, the MAC
will loop over that self-linked descriptor and treat it as "good enough"
for (incorrectly!) ACKing the frames in the block-ack.
Until I figure out how to work around this issue in the future, this counter
will tell me if packet RX processing ever gets to the point where it's
touching the self-linked descriptor. If there's ever enough packets to get
to that point, BA's will be invalid and likely very unhappy.
of active DMA cycle. dc_setcfg() also has to wait until the DMA
engine is stopped so using a common function to handle the job is
better than duplicating the code.
No objection from: marius
makes controller to receive bad frames and i82557 will also receive
bad frames since fxp(4) have to receive VLAN oversized frames. If
fxp(4) encounter DMA overrun error, the received frame size would
be 0 so the actual frame size after checksum field extraction the
length would be negative(-2). Due to signed/unsigned comparison
used in driver, frame length check did not work for DMA overrun
frames. Correct this by casting it to int.
While I'm here explicitly check DMA overrun error and discard the
frame regardless of result of received frame length check.
Reported by: n_hibma
Tested by: n_hibma
MFC after: 1 week
I'll clear how it's supposed to work with Bernhard and then look
at enabling this in the correct situations.
But this -does- enable HT RTS protection (using the appropriate legacy
rates) if this bit of code is enabled.
by default.
Adventourous souls with an AR9220/AR9280 or later and who have a device
that sends PS-POLL frames may wish to try tinkering with this option and
get back to me.
Linux ath9k only enables this for AR9280 and later NICs; so
create a capability for it so it isn't enabled for earlier
NICs.
Enabling hardware PS-POLL support will come in a later commit
and will be disabled by default.
Even though they map to setting the error filter register,
ath9k also writes them untouched to AR_RX_FILTER.
The Force-BSSID match bit can stay high, as it maps to a
misc mode register setting rather than an RX filter bit.
The phyerr, radar and bssid-match bits aren't real bits, they map
to enabling bits in other registers. Move those out of the way of
valid RX filter bits.
Add a few new fields from ath9k - compba, ps-poll, mcast-bcast-all.
Changes since 7.8.0 (from the official changelog):
- Fixed sporadic interrupt generation for associated CQ when processing
a local invalidate work request
- Changes to core scheduling to avoid starving requests from the host
under heavy RDMA Read Request load (e.g. packets to the wire)
- Programmed the tp tx resource limiter in function of the traffic (only
affects iWarp)
- Increased the egress NIC gather list length from 36 to 46 entries
MFC after: 1 week
the channel width is ni->ni_chw, which is set to the negotiated channel
width. ni->ni_htflags is the capability, rather than the negotiated
value.
Teach both the TX path and the sample rate module about this.
This seems to work fine for STA but not HT/20 AP mode.
Further discussion with net80211 people will need to take place
to ensure that the right flags are set based on the negotiated
capabilities of the remote peer, rather than whatever the local
parameters are.
Sending short-gi frames in 20mhz may work on some chips but
it certainly isn't supported on anything currently supported
by the HAL; and sending HT40 frames in HT20 mode just plain
won't work.
settings, it seems that our defines are backwards and don't match what
is in the EEPROM documentation or internal driver.
The ath9k code used to have a bitfield here, rather than a uint8_t, and
there were #defines used to swap the order based on the endian of the
platform - this wasn't because of nybble or bit ordering of the
underlying host but because of what the compiler was doing.
This may be the reason for the backwards field numbers, as ath9k had
similar issues.
the AR9285 so I'll leave it off for that.
Ath9k sources indiciate that one of the ANI modes interferes with
RIFS detection, so match ath9k and disable that.
* The existing interrupt mitigation code didn't mitigate anything - the
per-packet TX/RX interrupts are still occuring. It's possible this
worked for the AR5416 but not any later chipsets; I'll investigate and
update as needed.
* Set both the RX and TX threshold registers whilst I'm at it.
This is verified to work on the AR9220 and AR9160. I'm leaving it off
by default in case it's truely broken, but I need to have it enabled
when doing 11n testing or interrupt loads exceed 10,000 interrupts/sec.
queue has its own interrupt. If the exact number that we need is not a
power of 2 and we're using MSI, then switch to interrupt multiplexing.
While here, replace the magic numbers with something more readable.
MFC after: 3 days
At least one AR5416 user has reported measurable throughput drops
with this option. For now, disable it and make it a run-time
twiddle. It won't take affect until the next radio programming
trip though (eg channel scan, channel change.)
so there's no need to enable the RX of invalid frames just to do ANI.
The if_ath code and AR5212 ANI code setup the RX filter bits to enable
receiving OFDM/CCK errors if the device doesn't have the hardware
MIB counters. It isn't initialising it for the AR5416+ because all of
those chips have hardware MIB counters.
This fixes the odd (and performance affecting!) situation where if ani
is enabled (via sysctl dev.ath.X.intmit) then suddenly there's be a very
large volume of phy errors - which is good to track, but not what was
intended. Since each PHY error is a received (0 length) frame, it can
significantly tie up the RX side of things.
It's still not ready for prime-time - there's some TX niggles with these 11n
cards that I'm still trying to wrap my head around, and AMPDU-TX is just not
implemented so things will come to a crashing halt if you're not careful.
"extended capabilities" to refer to the new set of capability structures
starting at offset 0x100 in config space for PCI-express devices. For now
both function names will still work. I will merge this to older branches
to ease driver portability, but 9.0 will ship with a new pci_find_extcap()
function that locates extended capabilities instead.
Reviewed by: imp
MFC after: 1 week
This fix modifies the const addac initval array, rather than modifying
a local copy. It means that running >1 AR9160 on a board may prove to
be unpredictable.
The AR5416 init path also does something similar, so supporting
>1 AR5416 of different revisions could cause problems.
The later fix will be to create a private copy of the Addac data
for the AR5416, AR9160 (and AR9100 when it's merged in) and then
modify that as needed.
Obtained From: Linux ath9k
I found this when trying to figure out why the RX PHY error count
didn't match the OFDM error count ANI was using. It turns out
there was two problems:
* What this commit addresses - using the wrong mask for OFDM errors,
and
* The RX filter is set incorrectly after a channel scan (at least)
even if interference mitigation is enabled by default.
ANI is still disabled by default for the AR5416 and later chips.
bring it in line with the rest of the register initialisation.
I've verified that the 2/5ghz board values written to the
chip match what was previously written.
* add pspoll/uapsd queue setup defaults;
* enable the exponential backoff window rather than the random
backoff window when doing TX contention management.
would be a problem, make sure it isn't overwritten by whatever is in
there at cold reset.
This brings the > ar5416 init path treatment of AR_MISC_MODE.
report descriptor information, sysctl utility
will show it for us.
- Modify sysctl node description to make it more
understanable.
Found by: Alexander Best <arundel@freebsd.org>
Submitted by: Eygene Ryabinkin <rea@freebsd.org>
MFC after: 14 days
Approved by: thompsa (mentor)
value is updated after that we read it in the queue-head. This patch can
fix problems with BULK timeouts. The issue was found on a Nvidia chipset.
MFC after: 14 days
Approved by: thompsa (mentor)
* Pull out the static rix stuff into a different function
* I know this may slightly drop performance, but check if a static
rix is needed before each packet TX.
* Whilst I'm at it, add a little extra debugging to the rate
control stuff to make it easier to follow what's going on.
Give it a good go (32 attempts) and then print out a warning that's
going to occur whether HAL debugging is enabled or not. Then don't
abort the radio setup; just continue merrily along.
This should fix the issue that users were having where scanning would
occasionally fail on the active channel, causing traffic to cease
until the radio scanned again.
not needed.
These calibrations are only applicable if the chip operating mode
engages both interleaved RX ADCs (ie, it's compensating for the
differences in DC gain and DC offset -between- the two ADCs.)
Otherwise the chip reads values of 0x0 for the secondary ADC
(as I guess it's not enabled here) and thus writes potentially
bogus info into the chip.
I've tested this on the AR9160 and AR9280; both behave themselves
in 11g mode with these calibrations disabled.
for fixing them based on the ath9k related TXQ fixes.
I've done this so people can go over the history of the diffs to the original
AR5212 routines (which AR5416 and later chips use) to see what's changed.
enables broadcast filtering. Make sure to clear the bit to receive
broadcast frames. While I'm here rename the bit definition to
reflect reality.
Reported by: brad@OpenBSD
MFC after: 1 week
This commit really is "fix the OFDM duration calculation to match reality when
running in 802.11g mode."
The AR5212 init vals set AR_MISC_MODE to 0x0 and all the bits that can be set are
set through code.
The AR5416 and later initvals set AR_MISC_MODE to various other values (with
the AR5212 AR_MISC_MODE options cleared), which include AR_PCU_CCK_SIFS_MODE .
This adds 6uS to SIFS on non-CCK frames when transmitting.
This fixes the issue where _DATA_ 802.11g OFDM frames were being TX'ed with
the ACK duration set to 38uS, not 44uS as on the AR5212 (and other devices.)
The AR5212 TX pathway obeys the software-programmed duration field in the packet,
but the 11n TX pathway overrides that with a hardware-calculated duration. This
was getting it wrong because of the above AR_MISC_MODE setting. I've verified
that 11g data OFDM frames are now being TXed with the correct ACK+SIFS duration
programmed in.
Since ath9k does some slightly different bit fiddling when setting up
the TX queues, it may that the TX queue setup/reset functions will need
overriding later on.
been undergoing test for some weeks. This improves the RX
mbuf handling to avoid system hang due to depletion. Thanks
to all those who have been testing the code, and to Beezar
Liu for the design changes.
Next the igb driver is updated for similar RX changes, but
also to add new features support for our upcoming i350 family
of adapters.
MFC after a week
chipsets that do not have an HT slave at 0:0:0:0. The Linux quirk is
actually specific to Nvidia chipsets and the check I had added was in
the wrong place.
Prodded by: nathanw
- Always enable the HyperTransport MSI mapping window for HyperTransport
to PCI bridges (these show up as HyperTransport slave devices).
The mapping windows in PCI-PCI bridges are enabled by existing code
in the PCI-PCI bridge driver as MSI requests propagate up the device
tree, but Host-PCI bridges don't really show up in that tree.
- If the PCI device at domain 0 bus 0 slot 0 function 0 is not a
HyperTransport device, then blacklist MSI on any other HT devices in
the system. Linux has a similar quirk.
PR: kern/155442
Tested by: Zack Dannar zdannar of gmail
MFC after: 1 week
With this change, driver may not notice updated descriptor status
change when bounce buffers are active. However, rxeof() in next run
will handle the synchronization.
Change dc_rxeof() a bit to return the number of processed frames in
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.
Reviewed by: marius
This does a few things in particular:
* Abstracts out the gain control settings into a separate function;
* Configure antenna diversity, LNA and antenna gain parameters;
* Configure ob/db entries - the later v4k EEPROM modal revisions have
multiple OB/DB parameters which are used for some form of
calibration. Although the radio does have defaults for each,
the EEPROM can override them.
This resolves the AR2427 related issues I've been seeing and makes
it stable at all 11g rates for both TX and RX.
The offsets didn't match the assumption that nfarray[] is ordered by the
chainmask bits and programmed via the register order in ar5416_cca_regs[].
This repairs that damage and ensures that chain 1 is programmed correctly.
(And extension channels will now be programmed correctly also.)
This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416
setups - because Chain 1 would be programmed -80 or -85 dBm, which is
higher than the actual noise floor and thus convincing the radio that
indeed it can't ever transmit.
rather than duplicating them for the v14 (ar5416+) and v4k (ar9285) codebases.
Further chipsets (eg the AR9287) have yet another EEPROM format which will use
these routines to calculate things.
to the TX closed-loop power control registers.
* Modify a couple of functions to take the register chain number,
rather than the regChainOffset value. This allows for the
register chain to be logged.
also does this for sound drivers it's probably not necessary for all
combinations of controllers and drivers. However, given that our sound
drivers completely lack bus_dmamap_sync(9) calls this at least serves
as a workaround when enabling use of the IOMMU streaming buffers on
sparc64 and generally for arm and mips.
MFC after: 2 weeks
Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
The ath9k driver has a unified boundary/pdadc function, whereas
ours is split into two (one for each EEPROM type.) This is why
the AR9280 check is done here where we could safely assume it'll
always be AR9280 or later.
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.
It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
It looks like these apply in both open and closed loop TX power control,
but the only merlin boards i have either have OL -or- a non-default power
offset, not both.
to both make things clearer, and to make it easier to write userland
code which pulls in these definitions without needing to pull in the
rest of the HAL.
This stuff should be deprecated at some point in the future once
the net80211 regulatory domain support encapsulates all of the
defintions here.
This is something bus clock related from what I can gather. It is needed for
the AR9220 based Ubiquiti SR71-12 and SR71-15 Mini-PCI NICs.
(Note: those NICs don't work right now because of earlier changes to handle
power table offset correctly. That'll be resolved in a follow-up commit.)
Merlin (ar9280) and later were full-reset if they're doing open-loop TX
power control but the TSF wasn't being saved/restored.
Add ar5212SetTsf64() which sets the 64 bit TSF appropriately.
value. Controllers that always require "store and forward" mode(
Davicom and PNIC 82C168) have no way to recover from TX underrun
except completely reinitializing hardware. Previously only Davicom
was reinitialized and the TX FIFO threshold was changed not to use
"store and forward" mode after reinitialization since the default
FIFO threshold value was 0. This effectively disabled Davicom
controller's "store and forward" mode once it encountered TX
underruns. In theory, this can cause watchodg timeouts.
Intel 21143 controller requires TX MAC should be idle before
changing TX FIFO threshold. So driver tried to disable TX MAC and
checked whether it saw the idle state of TX MAC. Driver should
perform full hardware reinitialization on failing to enter to idle
state and it should not touch TX MAC again once it performed full
reinitialization.
While I'm here remove resetting TX FIFO threshold to 0 when
interface is put into down state. If driver ever encountered TX
underrun, it's likely to trigger TX underrun again whenever
interface is brought to up again. Keeping old/learned TX FIFO
threshold value shall reduce the chance of seeing TX underrns in
next run.
generally tidy up the TX power programming code.
Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.
This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.
Specifics:
* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone
Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.
Obtained from: linux ath9k
the ataahci(4) and atamarvell(4) drivers share it between the host and
the controller.
- Spell some zeros as BUS_DMA_WAITOK when used as bus_dmamem_alloc() flags.
MFC after: 2 weeks
coherent.
- Add some missing bus_dmamap_sync() calls. This includes putting such
calls before calling reply handlers instead of calling bus_dmamap_sync()
for the request queue from individual reply handlers as these handlers
generally read back updates by the controller.
Tested on amd64 and sparc64.
MFC after: 2 weeks
It defaults to -5 dBm for eeproms earlier than v21.
This apparently only applies to Merlin (AR9280) or later,
earlier 11n chipsets have a power table offset of 0.
All the code in ath9k which checks the power table offset
and takes it into account first ensures the chip is
Merlin or later.
The earlier way of doing debugging would evaluate the function parameters
before calling the HALDEBUG. In the case of detailed register debugging
would mean a -lot- of unneeded register IO and other stuff was going on.
This method evaluates the ath_hal_debug variable before the function
parameters are evaluated, drastically reducing the amount of overhead
enabling HAL debugging during compilation.
- everything related to LRO should be in #ifdef INET blocks
- reorder sge_iq's fields so that the most frequently used are all together
- pull all rx code into t4_intr_data directly
- let go of the ingress queue lock when passing up data
- refill the freelist only if it is short of at least 32 buffers
determining whether to use MRR or not.
It uses the 11g protection mode when calculating 11n related stuff, rather
than checking the 11n protection mode.
Furthermore, the 11n chipsets can quite happily handle multi-rate retry w/
protection; the TX path and rate control modules need to be taught about
that.
* change the BB gating logic to explicitly define which chips are covered;
the ath9k method isn't as clear.
* don't disable the BB gating for now, the ar5416 initvals have it, and the
ar9160 initval sets it to 0x0. Figure out why before re-enabling this.
* migrate the Merlin (ar9280) applicable WAR from the Kite (ar9285) code
(which won't get called for Merlin!) and stuff it in here.
* add dot11rate_label() which returns Mb or MCS based on legacy or HT
* use it everywhere dot11rate() is used
* in the "current selection" part at the top of the debugging output,
otuput what the rate itself is rather than the rix. The rate index
(rix) has very little meaning to normal humans who don't know how
to find the PHY settings for each of the chipsets; pointing out the
rix rate and type is likely more useful.
These flags are just plain wrong - they're the node flags from negotiation,
not the configured flags. I'll jump in later on and figure out exactly
what should be done to properly set these two flags when in both STA mode
(ie, what the AP says is possible and what's configured) and AP mode
(ie, where the AP has a configuration, but then negotiates what's possible
with each node, so per-node configuration can and will differ.)
This allows the 11n 2.4ghz/ht20 mode to associate (but perform poorly still)
and exchange MCS rates with atheros reference APs and a Cisco/Linksys
E3000 AP.
operation. Previously ownership was transferred to hardware before
setting address of new RX buffer such that it was possible for
hardware to use wrong RX buffer address.
While here keep compiler from re-ordering instructions by declaring
descriptor members volatile. Memory barriers would do the same job
but volatile is supposed to be cheaper than using memory barriers,
especially on MP systems.
Submitted by: marius
MFC after: 1 week
mps.c: Hide the 'out of chain frames' warning behind MPS_INFO.
mps_sas.c: Hide the SIM queue freeze/unfreeze messages behind MPS_INFO.
mpsvar.h: Bump the number of chain frames from 1024 to 2048. From
testing, it looks like this makes it less likely that we'll
run out of chain frames, and it doesn't cost much memory
(32K).
MFC after: 3 days
means of allowing vendor specific interface class for audio and MIDI devices.
- Add new quirks for this. The vendor and product list in OpenBSD's
dev/usb/umidi_quirks.c was used as reference.
MFC after: 14 days
Approved by: thompsa (mentor)
causing the size calculation to be truncated to the size of an int
(32-bits on all current architectures).
Submitted by: Anish akgupt3 of gmail
MFC after: 1 week
link flips during alias address insertion or dhclient operation.
While I'm here remove dc_reset() in DC_ISR_BUS_ERR case. Device is
fully reinitialized again in dc_init_locked().
* Turn ath_tx_calc_ctsduration() into a function that
returns the ctsduration, or -1 for HT rates;
* add a printf() to ath_tx_calc_ctsduration() which will be
very loud if somehow that function is called with an MCS
rate;
* Add ath_tx_get_rtscts_rate() which returns the RTS/CTS
rate to use for the given data rate, incl. the short
preamble flag;
* Only call ath_tx_calc_ctsduration() for non-11n chipsets;
11n chipsets don't require the rtscts duration to be
calculated.
It's used to calculate:
* the initial per-rate entries for short/long preamble ACK durations;
* packet durations for TDMA slot decisions;
* RTS/CTS protection durations;
* updating the duration field in the 802.11 frame header
This way invalid durations will generate a warning, prompting for it to be
fixed.
respectively and fix all bus_dma(9) issues seen when bounce buffers
are used.
o Setup frame handling had no bus_dmamap_sync(9) which prevented
driver from configuring RX filter. Add missing bus_dmamap_sync(9)
in both dc_setfilt_21143()/dc_setfilt_xircom() and dc_txeof().
o Use bus_addr_t for DMA segment instead of using u_int32_t.
o Introduce dc_dma_alloc()/dc_dma_free() functions to allocate/free
DMA'able memory.
o Create two DMA descriptor list for each TX/RX lists. This change
will minimize the size of bounce buffers that would be used in
each TX/RX path. Previously driver had to copy both TX/RX lists
when bounce buffer is active.
o 21143 data sheet says descriptor list requires 4 bytes alignment.
Remove PAGE_SIZE alignment restriction and use
sizeof(struct dc_dec).
o Setup frame requires 4 bytes alignment. Remove PAGE_SIZE
alignment restriction and use sizeof(struct dc_dec).
o Add missing DMA map unload for both setup frame and TX/RX
descriptor list.
o Overhaul RX handling logic such that make driver always allocate
new RX buffer with dc_newbuf(). Previously driver allowed to
copy received frame with m_devget(9) after passing the
descriptor ownership to controller. This can lead to passing
wrong frame to upper stack.
o Introduce dc_discard_rxbuf() which will discard received frame
and reuse loaded DMA map and RX mbuf.
o Correct several wrong bus_dmamap_sync(9) usage in dc_rxeof and
dc_txeof. The TX/RX descriptor lists are updated by both driver
and HW so READ/WRITE semantics should be used.
o If driver failed to allocate new RX buffer, update if_iqdrops
counter instead of if_ierrors since driver received the frame
without errors.
o Make sure to unload loaded setup frame DMA map in dc_txeof and
clear the mark of setup frame of the TX descriptor in dc_txeof().
o Add check for possible TX descriptor overruns in dc_encap() and
move check for free buffer to caller, dc_start_locked().
o Swap the loaded DMA map and the last DMA map for multi-segmented
frames. Since dc_txeof() assumes the last descriptor of the
frame has the DMA map, driver should swap the first and the last
DMA map in dc_encap(). Previously driver tried to unload
not-yet-loaded DMA map such that the loaded DMA map was not
unloaded at all for multi-segmented frames.
o Rewrite DC_RXDESC/DC_TXDESC macro to simpler one.
o Remove definition of ETHER_ALIGN, it's already defined in
ethernet.h.
With this changes, dc(4) works with bounce buffers and it shall
also fix issues which might have shown in PAE environments.
Tested by: marius
Previously dc(4) always checked whether there is pending interrupts
and this consumed a lot of CPU cycles in interrupt handler. Limit
the number of processing for TX/RX frames to 16. Also allow sending
frames in the loop not to starve TX under high RX load.
Reading DC_ISR register should be protected with driver lock,
otherwise interrupt handler could be run(e.g. link state change)
before the completion of dc_init_locked().
While I'm here remove unneeded code.
as well as controller has enough free TX descriptors.
Remove check for number of queued frames before attempting to
transmit. I guess it was added to allow draining queued frames
even if there is no link. I'm under the impression this type of
check should be done in upper layer. No other drivers in tree do
that.
ownership to controller before completion of access to the
descriptor. Driver is faking up status word so it should not give
ownership to controller until it completes RX processing.
request TX completion interrupt for every 8-th frames. Previously
dc(4) requested TX completion interrupt if number of queued TX
descriptors is greater than 64. This caused a lot of TX completion
interrupt under high TX load once driver queued more than 64 TX
descriptors. It's quite normal to see more than 64 queued TX
descriptors under high TX load.
This change reduces the number of TX completion interrupts to be
less than 17k under high TX load. Because this change does not
generate TX completion interrupt for each frame, add reclaiming
transmitted buffers in dc_tick not to generate false watchdog
timeouts.
While I'm here add check for queued descriptors in dc_txeof() since
there is no more work to do when there is no pending descriptors.
When the driver ran out of DMA chaining buffers, it kept the timeout for
the I/O, and I/O would stall.
The driver was not freezing the device queue on errors.
mps.c: Pull command completion logic into a separate
function, and call the callback/wakeup for commands
that are never sent due to lack of chain buffers.
Add a number of extra diagnostic sysctl variables.
Handle pre-hardware errors for configuration I/O.
This doesn't panic the system, but it will fail the
configuration I/O and there is no retry mechanism.
So the device probe will not succeed. This should
be a very uncommon situation, however.
mps_sas.c: Freeze the SIM queue when we run out of chain
buffers, and unfreeze it when more commands
complete.
Freeze the device queue when errors occur, so that
CAM can insure proper command ordering.
Report pre-hardware errors for task management
commands. In general, that shouldn't be possible
because task management commands don't have S/G
lists, and that is currently the only error path
before we get to the hardware.
Handle pre-hardware errors (like out of chain
elements) for SMP requests. That shouldn't happen
either, since we should have enough space for two
S/G elements in the standard request.
For commands that end with
MPI2_IOCSTATUS_SCSI_IOC_TERMINATED and
MPI2_IOCSTATUS_SCSI_EXT_TERMINATED, return them
with CAM_REQUEUE_REQ to retry them unconditionally.
These seem to be related to back end, transport
related problems that are hopefully transient. We
don't want to go through the retry count for
something that is not a permanent error.
Keep track of the number of outstanding I/Os.
mpsvar.h: Track the number of free chain elements.
Add variables for the number of outstanding I/Os,
and I/O high water mark.
Add variables to track the number of free chain
buffers and the chain low water mark, as well as
the number of chain allocation failures.
Add I/O state flags and an attach done flag.
MFC after: 3 days
the controller firmware will return all of our commands. Instead, keep
track of outstanding I/Os and return them to CAM once device removal
processing completes.
mpsvar.h: Declare the new "io_list" in the mps_softc.
mps.c: Initialize the new "io_list" in the mps softc.
mps_sas.c: o Track SCSI I/O requests on the io_list from the
time of mpssas_action() through mpssas_scsiio_complete().
o Zero out the request structures used for device
removal commands prior to filling them out.
o Once the target reset task management function completes
during device removal processing, assume any SCSI I/O
commands that are still oustanding will never return
from the controller, and process them manually.
Submitted by: gibbs
MFC after: 3 days
- Use the USB stack's builtin clear-stall feature.
- Wrap some long lines.
- Use memcpy() instead of bcopy().
- Use memset() instead of bzero().
- Tested applications:
/usr/ports/audio/fluidsynth
MFC after: 7 days
Approved by: thompsa (mentor)
frame in DM910x controllers. In r67595(more than 10 years ago) it
was replaced to use "Store and Forward" mode and made controller
generate TX completion interrupt for every frame.
any other media configuration. Otherwise some 21143 controller
cannot establish a link. While I'm here remove the PHY
initialization code in dc_setcfg(). Since dc_setcfg() is called
whenever link state is changed, having the PHY initialization code
in dc_setcfg() resulted in continuous link flips.
After driver resets SIA, use default SIA transmit/receive
configuration instead of disabling autosense/autonegotiation.
Otherwise, controller fails to establish a link as well as losing
auto-negotiation capability. For manual media configuration, always
configure 21143 controller with specified media to ensure media
change. This change makes ANA-6922 establish link with/without
auto-negotiation.
While I'm here be more strict on link UP/DOWN detection logic.
Many thanks to marius who fixed several bugs in initial patch and
even tested the patch on a couple of dc(4) controllers.
PR: kern/79262
Reviewed by: marius
Tested by: marius
port, copy SROM information from base softc as well and run SROM
parser again. This change is necessary for some dual port
controllers to make dc(4) correctly detect PHY media based on first
port configuration table.
While I'm here add a check for validity of the base softc before
duplicating SROM contents from base softc. If driver failed to
attach to the first port it can access invalid area.
PR: kern/79262
Reviewed by: marius
as they're likely not entirely correct, but they give people something
to toy with to compare behaviour/performance.
Disable the anti-noise part, as this apparently interferes with
RIFS. I haven't verified this.
packet duration for the ath_rate_sample module.
This doesn't affect the packet TX at all; only how much time the
sample rate module attributes to a completed TX.
the larger, aligned write+erase sizes the driver currently implements.
This preserves write behaviour but makes the flash driver usable for things
like a read-only FFS or a geom_uzip/geom_compress .
Note that since GEOM will now return the sector size as being smaller,
writes of sector size/alignment will now fail with an EIO. Code which
writes to the flash device will have to be (for now) manually taught
about the flash write blocksize.
caused link re-negotiation whenever application joins or leaves a
multicast group. If driver is running, it would have established a
link so there is no need to start re-negotiation. The re-negotiation
broke established link which in turn stopped multicast application
working while re-negotiation is in progress.
PR: kern/154667
MFC after: 1 week
- Allocate coherent DMA memory for the request/response queue area and
and the FC scratch area.
These changes allow isp(4) to work properly on sparc64 with usage of the
IOMMU streaming buffers enabled.
Approved by: mjacob
MFC after: 2 weeks
While updating Tx stats, already freed node could be referred and cause
page fault. To avoid such panic, spool Tx stats in driver's softc. Then,
on every ratectl interval, grab node though ieee80211_iterate_nodes() and
update ratectl stats.
* Simplify some code in run_iter_func().
* Fix typo
* Use memset instead of bzero (hselasky @)
PR: kern/153938
Submitted by: PseudoCylon <moonlightakkiy@yahoo.ca>
Approved by: thompsa (mentor)
active I/O to several disks (copying large file on ZFS) causes timeout after
just a few seconds of run. Single port 88SX6111 seems like not affected.
Skip reading transferred bytes count for these controllers. It works for
88SX6111, but 88SX6145 always returns zero there. Haven't tested others,
but better to be safe.
correctly:
* pass in whether to allow the hardware to override the duration field
in the main data frame (durupdate_en) - PS_POLL frames in particular
don't have the duration bit overriden;
* there's no rts/cts duration here; that's done elsehwere
- this also includes virtualization support on these devices
Correct some vlan issues we were seeing in test, jumbo frames on vlans
did not work correctly, this was all due to confused logic around HW
filters, the new code should now work for all uses.
Important fix: when mbuf resources are depeleted, it was possible to
completely empty the RX ring, and then the RX engine would stall
forever. This is fixed by a flag being set whenever the refresh code
fails due to an mbuf shortage, also the local timer now makes sure
that all queues get an interrupt when it runs, the interrupt code
will then always call rxeof, and in that routine the first thing done
is now to check the refresh flag and call refresh_mbufs. This has been
verified to fix this type 'hang'. Similar code will follow in the other
drivers.
Finally, sync up shared code for the I350 support.
Thanks to everyone that has been reporting issues, and helping in the
debug/test process!!
Drivers which rely on net80211 to create the beacon need to call
ieee80211_beacon_update() on iv_update_beacon() calls. This is required
that certain bits, e.g. TIM, get updated. A call to ieee80211_beacon_alloc()
is not enough because it does not care about flags which can only change
during runtime. By design a beacon is supposed to be allocated only once
while moving into RUN state.
To handle all possible calls to iv_update_beacon() the run_updateslot()
function has been revived and run_updateprot() has been added.
run_updateslot() handles slot time changes and run_updateprot() changes
to protection, both can change while nodes associate/leave.
Submitted by: Alexander Zagrebin <alex at zagrebin.ru>,
PseudoCylon <moonlightakkiy atyahoo.ca>
MFC after: 3 weeks
There's still a lot of random issues to sort out with the radio side of
things and AMPDU RX handling (and completely missing AMPDU TX handling!)
but if people wish to give this a go and assist in debugging the
issues, they can define ATH_DO_11N to enable it.
I'm just re-iterating - this is here to allow people to assist in
further 11n development; it is not any indication that the 11n support
is complete and functional.
Important notes:
* This doesn't support 1-stream cards yet - (eg AR9285) - the various bits
that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate
1-stream RX; so don't enable 11n unless you've first taught the rate
control module and the net80211 stack to negotiate 1-stream stuff;
* The only rate control module minimally 11n aware is ath_rate_sample;
* ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly
calculated;
* The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for
some reason; this will definitely impact 11n performance;
* AMPDU-TX isn't yet implemented;
* AMPDU-RX may be a bit buggy still and will definitely suffer from the
radio unreliability mentioned above (ie, don't expect 150/300mbit
RX just yet.)
The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)
The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.
This fixes some encryption problems in station mode.
PR: kern/154598
- use device_printf() instead of printf() to give more accurate warnings.
- use memcpy() instead of bcopy().
- add missing #if's for non-FreeBSD compilation.
Approved by: thompsa (mentor)
error address on a decoding error to unlatch it and to allow
us to print a better diagnostics message. This also has the
side effect of clearing the condition, which prevents an
interrupt storm.
Revert back to the previous method of doing it for where a node can be
identified and it's an 11n node.
I'll have to do some further research into exactly what is being messed up
with the sequence number matching and I'll then revisit this.
This doesn't yet take into account HT40 packet durations as the node info
(needed to know if it's a HT20 or HT40 node) isn't available everywhere
it needs to be.
putting descriptors (not buffers) across a 4k page boundary can cause issues.
I've not seen it in production myself but it apparently can cause problems.
So, in preparation for addressing this workaround, (re)-expose the particular
HAL capability bit which marks whether the chipset has support for cross-4k-
boundary transactions or not.
A subsequent commit will modify the descriptor allocation to avoid allocating
descriptor entries that straddle a 4k page boundary.
- entirely eliminate some calls to uio_yeild() as being unnecessary,
such as in a sysctl handler.
- move should_yield() and maybe_yield() to kern_synch.c and move the
prototypes from sys/uio.h to sys/proc.h
- add a slightly more generic kern_yield() that can replace the
functionality of uio_yield().
- replace source uses of uio_yield() with the functional equivalent,
or in some cases do not change the thread priority when switching.
- fix a logic inversion bug in vlrureclaim(), pointed out by bde@.
- instead of using the per-cpu last switched ticks, use a per thread
variable for should_yield(). With PREEMPTION, the only reasonable
use of this is to determine if a lock has been held a long time and
relinquish it. Without PREEMPTION, this is essentially the same as
the per-cpu variable.
* The existing radio config code was for the AR5416/AR9160 and missed out
on some of the AR9280 specific stuff. Include said stuff from ath9k.
* Refactor out the gain control settings into a new function, again pilfered
from ath9k.
* Use the analog register RMW macro when touching analog registers.
Obtained from: Linux ath9k
This fixes two problems -
* All packets need to be processed here, not just aggregate ones - as any
received frames (AMPDU or otherwise) in the given TID (traffic class id)
will update the sequence number and, implied with that, update the window;
* It seems there's situations where packets aren't matching a current node but
somehow need to be tracked. Thus just tag them all for now; I'll figure out
the why later.
Whilst I'm here, bump the stats counters whilst I'm at it.
This fixes AMPDU RX in my tests; the main problems now stem from what look
like PHY level error/retransmits which are impeding general throughput, incl.
AMPDU.
TX chainmask.
since the upper layers don't (yet) know about the active TX/RX chainmasks,
it can't tell the rate scenario functions what to use. I'll eventually sort
this out; this restores functionality in the meantime.
controller in question generates frames with bad IP checksum value
if packets contain IP options. For instance, packets generated by
ping(8) with record route option have wrong IP checksum value. The
controller correctly computes checksum for normal TCP/UDP packets
though.
There are two known RTL8168/8111C variants in market and the issue
I observed happened on RL_HWREV_8168C_SPIN2. I'm not sure
RL_HWREV_8168C also has the same issue but it would be better to
assume it has the same issue since they shall share same core.
RTL8102E which is supposed to be released at the time of
RTL8168/8111C announcement does not have the issue.
Tested by: Konstantin V. Krotov ( kkv <> insysnet dot ru )
This isn't strictly required to TX (at least non-agg and non-HT40,
non-short-GI) frames; but as it needs to be done anyway, just get
it done.
Linux ath9k uses the rate scenario style path for -all- packets,
legacy or otherwise. This code does much the same.
Beacon TX still uses the legacy, non-rate-scenario TX descriptor
setup. Ath9k also does this.
This 11n rate scenario path is only called for chips in the AR5416
HAL; legacy chips use the previous interface for TX'ing.
A-MPDU RX interferes with packet retransmission/reordering.
In local testing, I was seeing A-MPDU being negotiated and then
not used by the AP sending frames to the STA; the STA would then
treat non A-MPDU frames that are retransmits as out of the window
and get plain confused.
The hardware RX status descriptor has a "I'm part of an aggregate"
bit; so this should eventually be tested and then punted to the
A-MPDU reorder handling only if it has this bit set.
make use of the aac_ioctl_event callback, if aac_alloc_command fails. This
can end up in an infinite loop in the while loop in aac_release_command.
Further investigation into the issue mentioned by Scott Long [1] will be
necessary.
[1] http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078740.html
The AR5416 and later TX descriptors have new fields for supporting
11n bits (eg 20/40mhz mode, short/long GI) and enabling/disabling
RTS/CTS protection per rate.
These functions will be responsible for initialising the TX descriptors
for the AR5416 and later chips for both HT and legacy frames.
Beacon frames will remain using the non-11n TX descriptor setup for now;
Linux ath9k does much the same.
Note that these functions aren't yet used anywhere; a few more framework
changes are needed before all of the right rate information is available
for TX.
function; which will be later used by the TX path to determine
whether to use the extended features or not.
* Break out the descriptor chaining logic into a separate function;
again so it can be switched out later on for the 11n version when
needed.
* Refactor out the encryption-swizzling code that's common in the
raw and normal TX path.
The higher levels (net80211, if_ath, ath_rate) need this to make correct
choices about what MCS capabilities to advertise and what MCS rates are
able to be TXed.
In summary:
* AR5416 - 2/3 antennas, 2x2 streams
* AR9160 - 2/3 antennas, 2x2 streams
* AR9220 - 2 antennas, 2x2 sstraems
* AR9280 - 2 antennas, 2x2 streams
* AR9285 - 2 antennas but with antenna diversity, 1x1 stream
- SMBus Controller
- SATA Controller
- HD Audio Controller
- Watchdog Controller
Thanks to Seth Heasley (seth.heasley@intel.com) for providing us code.
MFC after 3 days
apply AR8152 v1.0 specific initialization code. Fix this bug by
explicitly reading PCI device revision id via PCI accessor.
Reported by: Gabriel Linder ( linder.gabriel <> gmail dot com )
After inspecting the ath9k source, it seems the AR5416 and later MACs
don't take an explicit RTS/CTS duration. A per-scenario (ie, what multi-
rate retry became) rts/cts control flag and packet duration is provided;
the hardware then apparently fills in whatever details are required.
The per-rate sp/lpack duration calculation just isn't used anywhere
in the ath9k TX packet length calculations.
The burst duration register controls something different; it seems to
be involved with RTS/CTS protection of 11n aggregate frames and is set
via a call to ar5416Set11nBurstDuration().
I've done some light testing with rts/cts protected frames and nothing
seems to break; but this may break said RTS/CTS and CTS-to-self protection.
that represents the host controller. This makes the FDT PCI support
working an a bare-bones manner. This needs a lot more work, of which
the beginning are at the end of the file, compiled-out with #if 0.
The intend being that both the Marvell PCIE and Freescale PCI/PCIX/PCIE
duplicate the same platform-independent domain initialization, that
should be moved into an unified implementation in the FDT code. Handling
of resources requires help from the platform. A unified implementation
allows us to properly support PCI devices listed in the device tree and
configured according to the device tree specification.
Sponsored by: Juniper Networks
Each different radio chipset has a different "good" range of CCA
(clear channel access) parameters where, if you write something
out of range, it's possible the radio will go deaf.
Also, since apparently occasionally reading the NF calibration
returns "wrong" values, so enforce those limits on what is being
written into the CCA register.
Write a default value if there's no history available.
This isn't the case right now but it may be later on when "off-channel"
scanning occurs without init'ing or changing the NF history buffer.
(As each channel may have a different noise floor; so scanning or
other off-channel activity shouldn't affect the NF history of
the current channel.)
* I messed up a couple of things in if_athvar.h; so fix that.
* Undo some guesswork done in ar5416Set11nRateScenario() and introduce a
flags parameter which lets the caller set a few things. To begin with,
this includes whether to do RTS or CTS protection.
* If both RTS and CTS is set, only do RTS. Both RTS and CTS shouldn't be
set on a frame.
There's two reasons for this:
* the raw and non-raw TX path shares a lot of duplicate code which should be
refactored;
* the 11n-ready chip TX path needs a little reworking.
receive processing.
Remove unnecessary restrictions on the mbuf chain length built during an
LRO receive. This restriction was copied from the Linux netfront driver
where the LRO implementation cannot handle more than 18 discontinuities.
The FreeBSD implementation has no such restriction.
MFC after: 1 week
This is just the bare minimum needed to teach ath_rate_sample to try
and handle MCS rates. It doesn't at all attempt to find the best
rate by any means - it doesn't know anything about the MCS rate
relations, TX aggregation or any of the much sexier 11n stuff
that's out there.
It's just enough to transmit 11n frames and handle TX completion.
It shouldn't affect legacy (11abg) behaviour.
Obtained from: rpaulo@
This will eventually be used by rate control modules and by the TX
code for calculating packet duration when handling rts/cts protection.
Obtained from: sam@, rpaulo@, linux ath9k
covering the whole page, free the page. Otherwise, clear the region and
mark it clean. Not marking the page dirty could reinstantiate cleared
data, but it is allowed by BIO_DELETE specification and saves unneeded
write to swap.
Reviewed by: alc
Tested by: pho
MFC after: 2 weeks
The defaults enabled three chains on the AR5416 even if the card has two
chains. This restores that and ensures that only the correct TX/RX
chainmasks are used.
When HT modes are enabled, all TX chains will be correctly enabled.
This should now enable analog chain swapping with 2-chain cards.
I'm not sure if this is needed for just the AR5416 or whether
it also applies to AR9160, AR9280 and AR9287 (later on); I'll have
to get clarification.
This, along with an initval change which will appear in a subsequent commit,
fixes bus panics that I have been seing with the AR9220 on a Routerstation Pro
(AR7161 MIPS board.)
Obtained from: Linux ath9k
PR: kern/154220
sbuf_new_for_sysctl(9). This allows using an sbuf with a SYSCTL_OUT
drain for extremely large amounts of data where the caller knows that
appropriate references are held, and sleeping is not an issue.
Inspired by: rwatson
the controller has a kind of embedded controller/memory and vendor
applies a large set of magic code via undocumented PHY registers in
device initialization stage. I guess it's a firmware image for the
embedded controller in RTL8105E since the code is too big compared
to other DSP fixups. However I have no idea what that magic code
does and what's purpose of the embedded controller. Fortunately
driver seems to still work without loading the firmware.
While I'm here change device description of RTL810xE controller.
H/W donated by: Realtek Semiconductor Corp.
exact model name is not clear yet. All previous RTL8201 10/100 PHYs
used 0x8201 in MII_PHYIDR2 which in turn makes model number 0x20
but this PHY used new model number 0x08.
capability. One of reason using interrupt taskqueue in re(4) was
to reduce number of TX/RX interrupts under load because re(4)
controllers have no good TX/RX interrupt moderation mechanism.
Basic TX interrupt moderation is done by hardware for most
controllers but RX interrupt moderation through undocumented
register showed poor RX performance so it was disabled in r215025.
Using taskqueue to handle RX interrupt greatly reduced number of
interrupts but re(4) consumed all available CPU cycles to run the
taskqueue under high TX/RX network load. This can happen even with
RTL810x fast ethernet controller and I believe this is not
acceptable for most systems.
To mitigate the issue, use one-shot timer register to moderate RX
interrupts. The timer register provides programmable one-shot timer
and can be used to suppress interrupt generation. The timer runs at
125MHZ on PCIe controllers so the minimum time allowed for the
timer is 8ns. Data sheet says the register is 32 bits but
experimentation shows only lower 13 bits are valid so maximum time
that can be programmed is 65.528us. This yields theoretical maximum
number of RX interrupts that could be generated per second is about
15260. Combined with TX completion interrupts re(4) shall generate
less than 20k interrupts. This number is still slightly high
compared to other intelligent ethernet controllers but system is
very responsive even under high network load.
Introduce sysctl variable dev.re.%d.int_rx_mod that controls amount
of time to delay RX interrupt processing in units of us. Value 0
completely disables RX interrupt moderation. To provide old
behavior for controllers that have MSI/MSI-X capability, introduce
a new tunable hw.re.intr_filter. If the tunable is set to non-zero
value, driver will use interrupt taskqueue. The default value of
the tunable is 0. This tunable has no effect on controllers that
has no MSI/MSI-X capability or if MSI/MSI-X is explicitly disabled
by administrator.
While I'm here cleanup interrupt setup/teardown since re(4) uses
single MSI/MSI-X message at this moment.
ath9k does a few different things here during config - if it's an early
AR5416 with two chains, it enables all three chains for calibration and
then restores the chainmask to the original values after initial
calibration has completed.
The reason behind this commit is to begin breaking out the chainmask
configuration for this specific reason; follow-up commits will add
the chainmask restore in the ar5416Reset() routine.
recent PCIe controllers(RTL8102E or later and RTL8168/8111C or
later) supports either 2 or 4 MSI-X messages. Unfortunately vendor
did not publicly release RSS related information yet. However
switching to MSI-X is one-step forward to support RSS.
RTL8111C generated corrupted frames where TCP option header was
broken. All other sample controllers I have did not show such
problem so it could be RTL8111C specific issue. Because there are
too many variants it's hard to tell how many controllers have such
issue. Just disable TSO by default but have user override it.
* Re-do the structure size/component math to make sure the struct matches
the expected size
* Just to be clear that we care about bitmask ordering, revert my previous
change and instead define that macro if we're on big-endian.
It turns out that the V4K eeprom definitions (used by the AR9285 and
its derivatives) is wrong. These values are at least causing issues
on my AR2427.
With this fix (and initvals in a subsequent commit), the AR2427 behaves
a lot better.
Note - there's still significant drift between the ath9k v4k eeprom
init code (again, used by AR9285 and derivatives) and what's in this
tree. That needs to be investigated and resolved.
prevent sending data when CTS is de-asserted.
In uart_tty_intr(), call uart_tty_outwakeup() when the CTS signal
changed, knowing that uart_tty_outwakeup() will do the right
thing for flow control. This avoids redundant conditionals.
PR: kern/148644
Submitted by: John Wehle <john@feith.com>
MFC after: 3 days
via AHCI-like memory resource at BAR(5). Use it if BIOS was so kind to
allocate memory for that BAR. This allows hot-plug support and connection
speed reporting.
MFC after: 2 weeks
controllers. Experimentation with RTL8102E, RTL8103E and RTL8105E
showed dramatic decrement of TX completion interrupts under high TX
load(e.g. from 147k interrupts/second to 10k interrupts/second)
With this change, TX interrupt moderation is applied to all
controllers except RTL8139C+.
The linux ath9k driver and (from what I've been told) the atheros reference
driver does this; it then leaves discarding 11n frames to the 802.11 layer.
Whilst I'm here, merge in a fix from ath9k which maintains a turbo register
setting when enabling the 11n register; and remove an un-needed (duplicate)
flag setting.
The v1 and v3 interfaces returned the whole EEPROM but the v14/v4k
interfaces just returned the base header. There's extra information
outside of that which would also be nice to get access to.
The rxmonitor hook is called on each received packet. This can get very,
very busy as the tx/rx/chanbusy registers are thus read each time a packet
is received.
Instead, shuffle out the true per-packet processing which is needed and move
the rest of the ANI processing into a periodic event which runs every 100ms
by default.
value. While I'm here enable all clocks before initializing
controller. This change should fix lockup issue seen on AR8152
v1.1 PCIe Fast Ethernet controller.
PR: kern/154076
MFC after: 3 days
This is apparently an AR9285 with the 802.11n specific bits disabled.
This code is completely untested; I'm doing this in response to users
who wish to test the functionality out. It's likely as buggy as the
AR9285 support is in FreeBSD at the moment.
sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further
commits will make it even more crowded. Now is a good time to
shuffle these files out before any more extensive work is done
on them.
Create an ar9003 directory whilst I'm here; ar9003 specific
chipset code will eventually live there.
with these ADC DC Gain/Offset calibrations.
The whole idea is to calibrate a pair of ADCs to compensate for any
differences between them.
The AR5416 returns lots of garbage, so there's no need to do the
calibration there.
The AR9160 returns 0 for secondary ADCs when calibrating 2.4ghz 20mhz
modes. It returns valid data for the secondary ADCs when calibrating
2.4ghz HT/40 and any 5ghz mode.
This removes the chipset-dependent TX DMA completion descriptor groveling.
It should now be (more) portable to other, later atheros chipsets when the
time comes.
The AR9100 at least doesn't have an external serial EEPROM
attached to the MAC; it instead stores the calibration data
in the normal system flash.
I believe earlier parts can do something similar but I haven't
experienced it first-hand.
This commit introduces an eepromdata pointer into the API but
doesn't at all commit to using it. A future commit will
include the glue needed to allow the AR9100 support code
to use this data pointer as the EEPROM.
the completion schedule from the hardware and returns AH_TRUE if
the hardware supports multi-rate retries (AR5212 and above); and
returns AH_FALSE if the hardware doesn't support multi-rate retries.
The sample rate module directly reads the TX completion descriptor
and extracts the TX schedule information from that. It will be
updated in a future commit to instead use this method to determine
the completion schedule.
Since we now have the source code, there's no reason to hide the diag codes
from other areas.
They live in the HAL as they form part of the HAL API and should still be treate
as "potentially flexible; don't publish as a public API." But since they're
already used as a public API (see follow-up commit), we may as well use
them in place of magic constants.
CRITICAL FIX - with stats changes the older 82598 will panic
and trash the stack on driver load, FCOE registers ONLY exist
in 82599 and must not be read otherwise.
kern/153951 - to correct incorrect media type on adapters
with pluggable modules I have eliminated the old static
table in favor of a new dynamic shared code routine. This
also has the benefit of detecting changes when a different
module is inserted.
Performance/enhancement to the Flow Director code from my
linux coworker (the developer of the code).
Fixes from Michael Tuexen - a data corruption problem on the
82599 (CRITICAL), fix so the buf size correctly adjusts as
the cluster changes, and max descriptors are set properly.
Also added 16K clusters for those REALLY big jumbos :)
In the RX path, the RX LOCK was not being released, and this
causes LOR problems. Add the code that igb already has.
Sync with in house shared code, this was necessary for the
Flow Director fix.
MFC in 2 days
reading. (This was already done for writing to a sysctl). This
requires all SYSCTL setups to specify a type. Most of them are now
checked at compile-time.
Remove SYSCTL_*X* sysctl additions as the print being in hex should be
controlled by the -x flag to sysctl(8).
Succested by: bde
for this sensor. Instead of leaving this location empty we use here
the default name 'sensor'.
Submitted by: Justin Hibbits <chmeeedalf at gmail dot com>
Approved by: nwhitehorn (mentor)
DP8381[56] and SiS 900/7016 controllers. After r212119, sis(4) no
longer reinitializes controller if ALLMULTI/PROMISC was changed.
However, RX filter handling code assumed some bits of the RX filter
is programmed by driver initialization. This caused ALLMULTI/PROMISC
configuration is ignored under certain conditions.
Fix that issue by reprogramming all bits of RX filter register.
While I'm here follow recommended RX filter programming steps
recommended by National DP8381[56] data sheet(RX filter should be
is disabled before programming).
Reported by: Paul Schenkeveld < freebsd () psconsult dot nl >
Tested by: Paul Schenkeveld < freebsd () psconsult dot nl >
MFC after: 3 days
- Remove extra unlock from end of ale_start_locked().
- Expand scope of locking in interrupt handler.
- Move ether_ifdetach() earlier and retire now-unneeded DETACH flag.
Tested by: Aryeh Friedman
Reviewed by: yongari (earlier version)
doesn't "fail", it may merely return garbage if it is not a valid ivar
for a given device. Our parent device must be a 'pcib' device, so we
can just assume it implements pcib IVARs, and all pcib devices have a
bus number.
Submitted by: clang via rdivacky
Compile sys/dev/mem/memutil.c for all supported platforms and remove now
unnecessary dev_mem_md_init(). Consistently define mem_range_softc from
mem.c for all platforms. Add missing #include guards for machine/memdev.h
and sys/memrange.h. Clean up some nearby style(9) nits.
MFC after: 1 month
This fixes hostap mode for at least ral(4) and run(4), because there is
no sufficient call into drivers which could be used initialize the node
related ratectl variables.
MFC after: 3 days
GbE controllers. It seems these controllers no longer support
multi-fragmented RX buffers such that driver have to allocate
physically contiguous buffers.
o Retire RL_FLAG_NOJUMBO flag and introduce RL_FLAG_JUMBOV2 to
mark controllers that use new jumbo frame scheme.
o Configure PCIe max read request size to 4096 for standard frames
and reduce it to 512 for jumbo frames.
o TSO/checksum offloading is not supported for jumbo frames on
these controllers. Reflect it to ioctl handler and driver
initialization.
o Remove unused rl_stats_no_timeout in softc.
o Embed a pointer to structure rl_hwrev into softc to keep track
of controller MTU limitation and remove rl_hwrev in softc since
that information is available through a pointer to structure
rl_hwrev.
Special thanks to Realtek for donating sample hardwares which made
this possible.
H/W donated by: Realtek Semiconductor Corp.
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Just let the default case handle all unsupported media types.
- In pnphy_status() don't unnecessarily read a register twice.
- Remove unnused macros.
MFC after: 1 week
configuration, which is used to work around issues with certain setups
(see r161237) by default, should not be triggered as it may in turn
cause harm in some edge cases.
- Even after masking the media with IFM_GMASK the result may have bits
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Announce PAUSE support also for manually selected 1000BASE-T, but for
all manually selected media types only in full-duplex mode. Announce
asymmetric PAUSE support only for manually selected 1000BASE-T.
- Simplify setting the manual configuration bits to only once after we
have figured them all out. This also means we no longer unnecessarily
update the hardware along the road.
- Remove a stale comment.
Reviewed by: yongari (plus additional testing)
MFC after: 3 days
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Simplify ciphy_service() to only set the manual configuration bits
once after we have figured them all out. This also means we no longer
unnecessarily update the hardware along the road.
MFC after: 1 week
complicates the code.
- Don't let atphy_setmedia() announce PAUSE support for half-duplex when
MIIF_FORCEPAUSE is set.
- Simplify e1000phy_service() and ip1000phy_service() to only set the
manual configuration bits once after we have figured them all out. For
ip1000phy_service() this also means we no longer unnecessarily update
the hardware along the road.
MFC after: 1 week
the lock instead of queueing it to a task.
- Do not invoke jme_rxintr() to reclaim any unprocessed but received
packets when shutting down the interface. Instead, just drop these
packets to match the behavior of other drivers.
- Hold the driver lock in the interrupt handler to avoid races with
ioctl requests to down the interface.
Reviewed by: yongari
limit maximum RX buffer size to RE_RX_DESC_BUFLEN instead of
blindly configuring it to 16KB. Due to lack of documentation, re(4)
didn't allow jumbo frame on these controllers. However it seems
controller is confused with jumbo frame such that it can DMA the
received frame to wrong address instead of splitting it into
multiple RX buffers. Of course, this caused panic.
Since re(4) does not support jumbo frames on these controllers,
make controller drop frame that is longer than RE_RX_DESC_BUFLEN
sized frame. Fortunately RTL810x controllers, which do not support
jumbo frame, have no such issues but this change also limited
maximum RX buffer size allowed to RTL810x controllers. Allowing
16KB RX buffer for controllers that have no such capability is
meaningless.
MFC after: 3 days
- failure code in em_xmit got mangled along the way
and was not properly handling errors.
- local timer code had a leftover UNLOCK call that
should be removed.
MFC after 3 days
and just show old (cached) values. Controller will not respond to
the command unless MAC is enabled so DUMP request for down
interface caused request timeout.
RealTek changed TX descriptor format for later controllers so these
controllers require MSS configuration in different location of TX
descriptor. TSO is enabled by default for controllers that use new
descriptor format.
For old controllers, TSO is still disabled by default due to broken
frames under certain conditions but users can enable it.
Special thanks to Hayes Wang at RealTek.
MFC after: 2 weeks
These controllers consist of two Marvell 88SE9128 6Gbps SATA chips and
PLX PCIe bridge. As result, they seem to be agree to work with ahci(4)
as usual HBAs. The only noticed issue is that RAID BIOS disables all
drive caches during boot, though `camcontrol cmd ...` is able to fix that.
Those who wants RAID functionality can still use closed proprietary driver
from HighPoint site.
MFC after: 1 week
install or remove non-SCI interrupt handlers per ACPI Component Architecture
User Guide and Programmer Reference. ACPICA may install such interrupt
handler when a GPE block device is found, for example. Add a wrapper for
ACPI_OSD_HANDLER, convert its return values to ours, and make it a filter.
Prefer KASSERT(9) over panic(9) as we have never seen those in reality.
Clean up some style(9) nits and add my copyright.
DMA boundary bug and runs with PCI-X mode. watchdog timeout was
observed on BCM5704 which lives behind certain PCI-X bridge(e.g.
AMD 8131 PCI-X bridge). It's still not clear whether the root
cause came from that PCI-X bridge or not. The watchdog timeout
indicates the issue is in TX path. If the bridge reorders TX
mailbox write accesses it would generate all kinds of problems but
I'm not sure. This should be revisited.
Tested by: Michael L. Squires (mikes <> siralan dot org)
issue seen on PCIX BCM5704 controller. r216970 fixed the issue but
the DMA address space restriction was applied to all bge(4)
controllers such that it caused unnecessary performance degradation
for controllers that have no such issues.
all new devices added between our r211022 and their git revision
93ad03d60b5b18897030038234aa2ebae8234748
Also correct a Foxconn entry.
MFC after: 1 week
bus_dma(9)'s capability which honors boundary restrictions of DMA
tag for dynamic buffers. However it seems this does not work well
and it triggered watchodg timeouts on controller that has the
hardware bug. It's not clear whether there is still another
hardware bug not mentioned in errata. This should be revisited
since this change shall make use of bounce buffers which in turn
reduces performance a lot on systems that have more than 4GB
memory.
Reported by: Michael L. Squires (mikes <> siralan dot org)
Tested by: Michael L. Squires (mikes <> siralan dot org)
MFC after: 3 days
mechanical change. This opens the door for using PV device drivers
under Xen HVM on i386, as well as more general harmonisation of i386
and amd64 Xen support in FreeBSD.
Reviewed by: cperciva
MFC after: 3 weeks
After controller updates control word in a RX LE, driver converts
it to host byte order. The checksum value in the control word is
stored in big endian form by controller. r205091 didn't account for
the host byte order conversion such that the checksum value was
incorrectly interpreted on big endian architectures which in turn
made all TCP/UDP frames dropped. Make RX checksum offload work
on any architectures by swapping the checksum value.
Reported by: Sreekanth M. ( kanthms <> netlogicmicro dot com )
Tested by: Sreekanth M. ( kanthms <> netlogicmicro dot com )
supposed to be APs and the later 24 are pre-configured as STAs. A wrong
condition during initialization is responsible for not configuring the last
8 array members. This is results in being able to create more than 8,
possible uninitialized, AP-VAPs.
PR: kern/153549
Submitted by: Erik Fonnesbeck <efonnes at gmail.com>
MFC after: 2 weeks
The controller is commonly found on DM&P Vortex86 x86 SoC. The
driver supports all hardware features except flow control. The
flow control was intentionally disabled due to silicon bug.
DM&P Electronics, Inc. provided all necessary information including
sample board to write driver and answered many questions I had.
Many thanks for their support of FreeBSD.
H/W donated by: DM&P Electronics, Inc.
modification of memory which was already free'd and eventually in:
wpi0: could not map mbuf (error 12)
wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
and an usuable device.
PR: kern/144898
MFC after: 3 days
md(4) to using M_WAITOK malloc calls.
M_NOWAITOK allocations may fail when enough memory could be freed, but not
immediately. E.g. SU UFS becomes quite unhappy when metadata write return
error, that would happen for failed malloc() call.
Reported and tested by: pho
MFC after: 1 week
table is present, then the acpi_ec(4) driver will allocate its resources
from nexus0 before the acpi0 device reserves resources for child devices.
Reviewed by: jkim
manual 1000BASE-T modes of DP83865 only work together with other National
Semiconductor PHYs.
- Spell 10BASE-T correctly
- Remove some redundant braces.
condition in proc_rwmem() and to (2) simplify the implementation of the
cxgb driver's vm_fault_hold_user_pages(). Specifically, in proc_rwmem()
the requested read or write could fail because the targeted page could be
reclaimed between the calls to vm_fault() and vm_page_hold().
In collaboration with: kib@
MFC after: 6 weeks
the original amd64 and i386 headers with stubs.
Rename (AMD64|I386)_BUS_SPACE_* to X86_BUS_SPACE_* everywhere.
Reviewed by: imp (previous version), jhb
Approved by: kib (mentor)
controller with Card Read Host Controller. These controllers are
multi-function devices and have the same ethernet core of
JMC250/JMC260. Starting from REVFM 5(chip full mask revision)
controllers have the following features.
o eFuse support
o PCD(Packet Completion Deferring)
o More advanced PHY power saving
Because these controllers started to use eFuse, station address
modified by driver is permanent as if it was written to EEPROM. If
you have to change station address please save your controller
default address to safe place before reprogramming it. There is no
way to restore factory default station address.
Many thanks to JMicron for continuing to support FreeBSD.
HW donated by: JMicron
a 2GHz channel with appropriate flags set to sc->config. Due to not zeroing
sc->config for auth/assoc those flags are still set while trying to connect
on a 5GHz channel.
MFC after: 3 days
Use pci_enable_busmaster instead of setting PCIM_CMD_BUSMASTEREN
directly. There's no need to set PCIM_CMD_MEMEN. The bit is set when a
SYS_RES_MEMORY resource is activated.
Remove redundant pci_* function calls from suspend/resume methods. The
bus driver already saves and restores the PCI configuration.
Write 1 byte instead of 4 when setting the HIFN_TRDY_TIMEOUT register.
It is only 1 byte according to the specification.
Reviewed by: jhb
Approved by: kib (mentor)
configuration registers directly.
Remove pci_enable_io calls where they are redundant. The PCI bus driver
will set the right bits when the corresponding bus resource is activated.
Remove redundant pci_* function calls from suspend/resume methods. The
bus driver already saves and restores the PCI configuration.
Reviewed by: jhb
Approved by: kib (mentor)
This is based on the patch submitted by Yuri Skripachov.
Overview of the changes:
- clarify double-use of some ACPI_BATT_STAT_* definitions
- clean up undefined/extended status bits returned by _BST
- warn about charging+discharging bits being set at the same time
PR: kern/124744
Submitted by: Yuri Skripachov <y.skripachov@gmail.com>
Tested by: Yuri Skripachov <y.skripachov@gmail.com>
MFC after: 2 weeks
allow the child atkbd device to reuse that IRQ resource instead of
reallocating the same IRQ from the parent bus inside the atkbd driver.
- Don't allocate a shared IRQ for the atkbd driver. For AT keyboard
devices on an ISA bus the IRQ is not shareable. Instead, the bus driver
should mark the IRQ shareable if the bus supports shared IRQs.
- Don't identify child devices until after the atkbdc device itself has
attached.
delete the IRQ resource from the psmcpnp device completely.
- Don't allocate the IRQ resource shared. It is not a shareable interrupt
on ISA. The bus driver can set RF_SHAREABLE if the IRQ is actually
shareable on a non-ISA bus.
- Avoid side-effect assignments in if statements when possible.
- Don't use ! to check for NULL pointers, explicitly check against NULL.
- Explicitly check error return values against 0.
- Don't use INTR_MPSAFE for interrupt handlers with only filters as it is
meaningless.
- Remove unneeded function casts.
function always returned the nominal frequency instead of current frequency
because we use RDTSC instruction to calculate difference in CPU ticks, which
is supposedly constant for the case. Now we support cpu_get_nominal_mhz()
for the case, instead. Note it should be just enough for most usage cases
because cpu_est_clockrate() is often times abused to find maximum frequency
of the processor.
There is no need to use an atomic operation at structure initialization
time.
Note that the file changed is not connected to the build at this time.
Reviewed by: jhb (general issue)
Approved by: np
MFC after: 2 weeks
Prior to this change, the addressing method wasn't getting set, and
so the LUN field could be set incorrectly in some instances.
This fix should allow for LUN numbers up to 16777215 (and return an error
for anything larger, which wouldn't fit into the flat addressing model).
Submitted by: scottl (in part)
This bug manifested itself after repeated device arrivals and
departures. The root of the problem was that the last entry in the
reply array wasn't initialized/allocated. So every time we got
around to that event, we had a bogus address.
There were a couple more problems with the code that are also fixed:
- The reply mechanism was being treated as sequential (indexed by
sc->replycurindex) even though the spec says that the driver
should use the ReplyFrameAddress field of the post queue
descriptor to figure out where the reply is. There is no
guarantee that the reply descriptors will be used in sequential
order.
- The second word of the reply post queue descriptor wasn't being
checked in mps_intr_locked() to make sure that it wasn't
0xffffffff. So the driver could potentially come across a
partially DMAed descriptor.
- The number of replies allocated was one less than the actual
size of the queue. Instead, it was the size of the number of
replies that can be used at one time. (Which is one less than
the size of the queue.)
mps.c: When initializing the entries in the reply free
queue, make sure we initialize the full number that
we tell the chip we have (sc->fqdepth), not the
number that can be used at any one time (sc->num_replies).
When allocating replies, make sure we allocate the
number of replies that we've told the chip exist,
not just the number that can be used simultaneously.
Use the ReplyFrameAddress field of the post queue
descriptor to figure out which reply is being
referenced. This is what the spec says to do, and
the spec doesn't guarantee that the replies will be
used in order.
Put a check in to verify that the reply address passed
back from the card is valid. (Panic if it isn't, we'll
panic when we try to deference the reply pointer in any
case.)
In mps_intr_locked(), verify that the second word of the
post queue descriptor is not 0xffffffff in addition to
verifying that the unused flag is not set, so we can
make sure we didn't get a partially DMAed descriptor.
Remove references to sc->replycurindex, it isn't needed
now.
mpsvar.h: Remove replycurindex from the softc, it isn't needed now.
Reviewed by: scottl
