supports IPv4/IPv6 checksum offloading and VLAN tag insertion/
stripping as well as WOL. Because uether does not provide a way
to announce driver specific offload capabilities to upper stack,
checksum offloading support needs more work and will be done in
future.
Special thanks to ASIX for donating sample hardware.
H/W donated by: ASIX Electronics
Reviewed by: hselasky
option that is highly recommended to be adjusted in too much
documentation while doing nothing in FreeBSD since r2729 (rev 1.1).
ipcs(1) needs to be recompiled as it is accessing _KERNEL private
variables.
Reviewed by: jhb (before comment change on linux code)
Sponsored by: Sandvine Incorporated
Specifics:
* add 4920MHz-4980MHz for 11a and 11n/HT20
* add 5040MHz-5080MHz for 11a and 11n/HT20
* add 5500MHz-5700MHz for 11a and 11n/HT20 (DFS needed)
* add 5500MHz-5680MHz for 11n/HT40 (DFS needed)
TODO:
* add correct HT40 bands for 4920-4980 and 5040-5080
For the curious:
There's been many revisions to the Japan regulatory rules.
Apparently, the requirements require old cards certified on a previous
version of the rules to obey the older rules, not the newer rules.
The regdomain.xml outlines the -current- restrictions.
The card driver (eg the ath_hal regulatory domain code) may include
previous revisions of the Japan rules.
The ath_hal regdomain code populates the initial channel list based on
what the EEPROM indicates is possible. The regdomain.xml database imposes
further restrictions on this.
So regdomain.xml only needs to have the -current- rules. If the card
was certified on an earlier set of JP rules, it may only support a subset
of those channels - these are calculated at device attach and this
restricted list is kicked to net80211. regdomain.xml operates on -this-
list of channels.
And thus, the correct regulatory behaviour for Japan is handled with only
one regdomain.xml Japan database entry.
(phew.)
Obtained from: Linux wireless-regdb
system timer is stopped during shutdown and that the pause() statement in ukbd
causes infinite hang in this regard. The fix is to use mi_switch() instead of
pause() to do the required task switch to ensure that the required USB processes
get executed.
Reported by: Mike_Karels@mcafee.com
MFC after: 1 week
r179247 introduced a possibility of devfs_allocv() returning spurious
ENOENT. If the vnode is selected by vnlru daemon for reclamation, then
devfs_allocv() can get ENOENT from vget() due to devfs_close() dropping
vnode lock around the call to cdevsw d_close method.
Use LK_RETRY in the vget() call, and do some part of the devfs_reclaim()
work in devfs_allocv(), clearing vp->v_data and de->de_vnode. Retry the
allocation of the vnode, now with de->de_vnode == NULL.
The check vp->v_data == NULL at the start of devfs_close() cannot be
affected by the change, since vnode lock must be held while VI_DOOMED
is set, and only dropped after the check.
Reported and tested by: Kohji Okuno <okuno.kohji jp panasonic com>
Reviewed by: attilio
MFC after: 3 weeks
checking IFF_DRV_RUNNING and simplify the code. This also involves holding
the driver lock in the rx_ch callout.
- Just use ifp instead of sc->sc_ifp.
Submitted by: jhb (mostly)
allowing their use to be disabled via device hints though). This matches
what the corresponding Linux driver provided by LSI does. Tested with
SAS1064.
- There's no need to keep track of the RIDs used.
- Don't allocate MSI/MSI-X as RF_SHAREABLE.
- Remove a comment which no longer applies since r209599.
- Assign NULL rather than 0 to pointers.
MFC after: 1 month
bridge is blacklisted. In that case just return from pci_alloc_msix_method(),
otherwise we continue without a single MSI-X resource, causing subsequent
attempts to use the seemingly available resource to fail or when booting
verbose a NULL-pointer dereference of rle->start when trying to print the
IRQ in pci_alloc_msix_method().
Reviewed by: jhb
MFC after: 1 week
loop in nfscl_getcl() when a forced dismount is in progress,
because nfsv4_lock() will return 0 without sleeping when
MNTK_UNMOUNTF is set.
This patch fixes it so it won't loop calling nfsv4_lock()
for this case.
MFC after: 2 weeks
delivered to parent when the child exists.
Submitted by: Petr Salinger <Petr.Salinger seznam cz> (Debian/kFreeBSD)
MFC after: 1 week
X-MFC-note: bump __FreeBSD_version
cycle mode as timecounter just works fine. My best guess is that a firmware
update has fixed this, check at run-time whether it advances and use a
positive quality if it does. The latter will cause this timecounter to be
used instead of the tick counter based one, which just sucks for SMP.
- Remove a redundant NULL assignment from the timecounter initialization.
as STX_CTRL_PERF_CNT_CNT0_SHIFT actually is zero, if we were using the
second counter in the upper 32 bits this would be required though as the MI
timecounter code doesn't support 64-bit counters/counter registers.
- Remove a redundant NULL assignment from the timecounter initialization.
- Consistently use the newly introduced sc_mac_rxcfg throughout the driver
instead of reading the old content of CAS_MAC_RX_CONF.
- Increment if_iqdrops instead of if_ierrors in case of RX buffer allocation
failure.
- According to the Cassini datasheet the RX MAC should also be disabled in
cas_setladrf() before changing its configuration.
- Add error messages to gem_disable_{r,t}x() and take advantage of these
throughout the driver instead of duplicating their functionality all over
the place.
sets GEM_MAC_RX_CONFIG based on sc_mac_rxcfg which in turn is initialized
to zero, before reading the supposedly default configuration we were
effectively not basing sc_mac_rxcfg and thus GEM_MAC_RX_CONFIG on the
default configuration. Solve this by calling gem_setladrf() after reading
in the default configuration of GEM_MAC_RX_CONFIG. This also avoids the
need to distinguish whether gem_setladrf() should enable the RX MAC again
and should be slightly more correct as we're now doing all of the RX MAC
configuration in the intended step.
