Now run(4) fetches parameters from ic->ic_wme.wme_params array, which is never initialized
(and can be safely removed). This patch replaces &ic->ic_wme.wme_params with
&ic->ic_wme.wme_chanParams.cap_wmeParams (contains parameters for local station;
used by other drivers with WME support).
Tested:
* me: STA: run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address 38:83:45:11:78:ae
Now device will use retry limit, which is set via 'ifconfig <interface>
maxretry <number>'.
Tested:
* Tested on WUSB54GC, STA mode.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3689
The MAC can be fetched from the key struct.
I added the ndis updates to make it compile.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3657
This diff includes:
* Transmitter Addresses, Keys and TKIP MIC addition to the Security Key Table.
* Proper SEC Control Registers initialization and maintenance.
* Additional flags and values in TX descriptor, which are required for encryption support.
* Error checking in RX path.
Tested:
* Tested on WUSB54GC, STA (WEP, TKIP, CCMP), HOSTAP (CCMP) and IBSS (CCMP, WPA-None) modes.
* rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, STA mode (CCMP+TKIP)
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3640
Note: I manually had to merge this; I merged in the "put beacon_offsets
into vap" commit before this.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3628
Don't override the NIC MAC address with an overridden MAC address for
a VAP.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3625
Tested:
* rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528, STA mode
Note: haven't tested AP mode yet; will do once the rest of the
AP mode / power save commits are in.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3624
Move the mbuf free responsibility to the caller of the hardware xmit
function, not the hardware xmit function itself.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3621
* Remove unused sc_txtap_len/sc_rxtap_len fields.
* Remove unused ackrate variable.
* Remove unneded warning in rum_update_mcast().
* Use nitems().
* Replace some hardcoded values for RT2573_MAC_CSR1 register.
* Remove second argument for RUM_LOCK_ASSERT() - it is always the same.
Submitted by: <s3erios@gmail.com>
Differential Revision: https://reviews.freebsd.org/D3605
The fullmac firmware doesn't seem to populate a useful rssi indicator
in the RX descriptor, so if one plotted said values, they'd basically
look like garbage.
The reference driver implements a "get current rssi" firmware command
which I guess is really meant for station operation only (as hostap
operation would need rssi per station, not a single firmware read.)
So:
* populate sc_currssi during each calibration run;
* use this in the RX path instead of trying to reconstruct the RSSI
value and passing it around as a pointer;
* do up a quick hack to map the rssi hardware value to some useful
signal level;
* the survey results provide an RSSI value between 0..100, so just
do another quick hack to map it into some usefulish signal level;
* supply a faked noise floor - I haven't yet found how to pull it
out of the firmware.
The scan results and the station RSSI information is now more useful
for indicating signal strength / distance.
This logic is mostly crimed from the reference driver and the linux
r92su driver.
I verified that it (a) worked on the rsu hardware I have, and (b)
did traffic testing whilst watching what ath(4) sent as a hostap.
It successfully sent MCS8..15 rates (which requires 2-stream reception)
as well as MCS0..7 (which is 1-stream.)
Tested:
* RTL8712, 1T1R NIC, MCS rates 0..7.
* RTL8712, 1T2R NIC, MCS rates 0..15
TODO:
* Find a 2T2R NIC!
* include opt_wlan.h like a good little wlan driver;
* add a function to free the mbufq /and/ the node references on it, or we will leak
said node references;
* free the mbufq upon NIC shutdown otherwise we may end up with a full list that
we never begin transmit work on, and thus never drain it;
* .. which frees it upon NIC detach too;
* ensure urtwn_start() gets called after the completion of frame TX even if the
pending queue is empty, otherwise transmit will stall. It's highly unlikely that
the usb tx queue would be empty whilst the incoming send queue is full, but hey,
who knows.
This passes some iperf testing with and without the NIC being actively removed during
said active iperf test.
Tested:
* urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R ; STA mode
in the join message so the firmware would pick it up.
* Strip out the direct hardware fiddling for 40MHz mode - the firmware
we're using doesn't require it (the rtl8712su firmware does; it
is less 'fullmac' than what we're using.)
* Fix the mbuf handling during errors - rsu_tx shouldn't free mbufs;
it's up to the caller to do so. This brings it in line with
what other drivers do or should be doing.
Tested:
* RTL8712, HT40 channel, STA mode (during this commit)
Refer to the usb_quirk(4) manual page for more details on how to use
this new feature.
Submitted by: Maxime Soule <btik-fbsd@scoubidou.com>
PR: 203249
MFC after: 2 weeks
* Add a new method to control NIC poweron / network-sleep / power off;
* Add in A-MPDU TX negotiation support, but comment it out because it
does break TX traffic;
* blank out the tx buffer before sending a firmware message, just in case;
* go into network-sleep once associated;
TODO:
* figure out why ampdu negotiation isn't working and breaking TX traffic,
then enable it.
to do it directly.
Ensure that we re-queue starting transmit upon TX completion.
This solves two issues:
* It stops tx stalls - before this, if the transmit path filled the
mbuf queue then it'd never start another transmit.
* It enforces ordering - this is very required for 802.11n which
requires frames to be transmitted in the order they're queued.
Since everything remotely involved in USB has an unlock/thing/relock
pattern with that mutex, the only way to guarantee TX ordering is
to 100% defer it into a separate thread.
This now survives an iperf test and gets a reliable 30mbit/sec.
Correctly (I hope!) remove net80211 references before doing so.
Just doing a dumb mbufq drain isn't enough.
If enough traffic occurs and the mbuf queue fills up then transmit
stalls (which I'm not fixing in this commit!) but then the mbuf queue
stays full until the driver is removed. There's also the net80211
node refcounting leak.
This just ensures that during rsu_stop and detach the mbuf queue
is purged (and references!) so the queue-full situation can be
recovered from.
setup pieces and so (at least) transmit doesn't work.
It'll just fall back to being a straight HT20 device and negotiate
HT20 only.
Tested by: Idwer Vollering <vidwer@gmail.com>
requirements.
Don't start the opmode and join path until a pending survey is finished.
This seems to reliably fix things.
Ideally I'd just finish off the net80211 pluggable scan stuff and implement
the methods here so if_rsu can just drive the scan machinery.
However, that's a .. later thing.
Whilst here, remove the getbuf debugging; it's okay to run out of transmit
buffers under load; it however isn't okay to not be able to send commands.
I'll fix that later.
* Add a tunable to enable 11n if it's available, so to not anger people
who upgrade.
kenv hw.usb.rsu.enable_11n=1 before inserting the device.
* Add initial 11n htconfig bits;
* Enable 40MHz mode if it's available;
* Add 11n channels;
* Set 11n bits in the firmware.
It works for RX; I haven't tested TX aggregation just yet.
However the firmware doesn't do RX re-ordering, so I have to tie it into
the net80211 A-MPDU RX reorder path before I flip this on by default.
I've verified that I'm indeed actually seeing MCS 0->7 rates being received.
I haven't dug into whether it's actually transmitting 11n rates; I'll dig into
that later.
* the tx descriptor TID is priority, not TID.
* the tx descriptor queue id mapping is separate from the
TID/priority; rather than just "BE".
TODO:
* go and re-re-re-verify the queue mappings; the linux and openbsd
mappings aren't exactly the same. I need to verify all of this
before I try to flip on 11n RX.
* Do 1T1R for now, until we read the config out of ROM and use it.
* Disable turbo mode, I dunno what this is, but the linux drivers
have this disabled.
* Set the firmware endpoints to what we read from USB.
Tested:
* RTL8712 cut 3, STA mode
data queues.
This is similar to the openbsd and rtlwifi/r92su drivers.
Note: this driver still assumes it's a 4-endpoint device; I'll enforce
that in a follow-up commit.
There is an issue with interrupts at the moment, but it works with
polling mode set (hw.usb.xhci.use_polling=1).
Reviewed by: hselasky
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3665
This allows for arbitrary channel info to be placed in the input call rather
than the totally gross hack of overriding ic_curchan.
Without this I'm sure ic_curchan setting was racing with the scan code
setting the channel itself..
The firmware in this NIC sends management frames. So far I'm not sure which
ones it handles and which ones it doesn't handle - but this is what openbsd
does.
The association messages are handled by the firmware; the key negotiation
for 802.1x and WPA are done as raw frames, not management frames.
This successfully allows it to associate to my home networks whereas it didn't
work beforehand.
Tested:
* RTL8712, cut 3, STA mode
TODO:
* The firmware does send a join response with a status code; that should be
logged in a more obvious way to assist with debugging. Ie, the firmware
is the thing that is saying "couldn't join, sorry!", not net80211.
* yes, when a "sta disconnect" message comes through we should, like,
disconnect things. We're not currently generating beacon miss messages,
and net80211 isn't disconnecting things via software beacon miss receive.
Tested:
* RTL8712, cut 3, STA mode
* use an ath/iwn style debug bitmap - it's still global rather than per-device,
but it's better than debug levels
* disable bgscan - it just makes things unstable/unpredictable for now.
Tested:
* if_rsu - RTL8712 cut 3, STA mode
connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.
Reviewed by: adrian
Sponsored by: Netflix
Sponsored by: Nginx, Inc.
intervals less than 250us was not handled properly. Add support for
high-bandwidth ISOCHRONOUS packets. USB webcams, USB audio and USB DVB
devices are expected to work better. High-bandwidth INTERRUPT
endpoints is not yet supported.
MFC after: 2 weeks
the kernel is tapping an USB transfer. This leads to a NULL pointer
access. The solution is to only trace while the USB bus lock is
locked.
MFC after: 2 weeks
like RPI-B and RPI-2.
Description of problem:
USB transfers can process data in their callbacks sometimes causing
unacceptable latency for other USB transfers. Separate BULK completion
callbacks from CONTROL, INTERRUPT and ISOCHRONOUS callbacks, and give
BULK completion callbacks lesser execution priority than the
others. This way USB audio won't be interfered by heavy USB ethernet
usage for example.
Further serve USB transfer completion in a round robin fashion,
instead of only serving the most CPU hungry. This has been done by
adding a third flag to USB transfer queue structure which keeps track
of looping callbacks. The "command" callback function then decides
what to do when looping.
MFC after: 2 weeks
* 286410
* 286413
* 286416
The initial commit broke a variety of debug and features that aren't
in the GENERIC kernels but are enabled in other platforms.
with the net80211 stack.
Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
driver about any changes: number of wlan(4) interfaces, number of them
in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
driver experiences errors and can not attribute them to any specific
interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@,
op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not
tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances
of problems are low. The wtap wasn't compilable even before this change.
But the ndis driver is complex, and it is likely to be broken with this
commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740
Sponsored by: Nginx, Inc.
Sponsored by: Netflix
The ftdi chip itself has a "get bitmode" command that doesn't actually
return the current bitmode, just a snapshot of the gpio lines. The chip
apparently has no way to provide the current bitmode.
This implements the functionality at the driver level. The driver starts
out assuming the chip is in UART mode (which it will be, coming out of
reset) and keeps track of every successful set-bitmode operation so that
it can always return the current mode with UFTDIIOC_GET_BITMODE.
Remove NAKing limit and pause IN and OUT transactions for 125us in
case of NAK response for BULK and CONTROL endpoints. This gets the
receive latency down and improves USB network throughput at the cost
of some CPU usage.
MFC after: 1 month
xhci_start_controller() to xhci_init(). These values don't change at run-
time so there's no point of acquiring them on every USB_HW_POWER_RESUME
instead of only once during initialization. In r276717, reading the first
couple of registers in question already had been moved as a prerequisite
for the changes in that revision.
- Identify ASMedia ASM1042A controllers.
- Use NULL instead of 0 for pointers.
MFC after: 3 days
variant of Microsoft RNDIS, i. e. their unofficial version of CDC ACM,
has been disabled in r261544 for resolving a conflict with umodem(4).
Eventually, in r275790 that problem was dealt with in the right way.
However, r275790 failed to put probing of RNDIS devices in question
back.
- Initialize the device prior to querying it, as required by the RNDIS
specification. Otherwise already determining the MAC address may fail
rightfully.
- On detach, halt the device again.
- Use UCDC_SEND_ENCAPSULATED_{COMMAND,RESPONSE}. While these macros are
resolving to the same values as UR_{CLEAR_FEATURE,GET_STATUS}, the
former set is way more appropriate in this context.
- Report unknown - rather: unimplemented - events unconditionally and
not just in debug mode. This ensures that we'll get some hint of what
is going wrong instead of the driver silently failing.
- Deal with the Microsoft ActiveSync requirement of using an input buffer
the size of the expected reply or larger - except for variably sized
replies - when querying a device.
- Fix some pointless NULL checks, style bugs etc.
This changes allow urndis(4) to communicate with a Microsoft-certified
USB RNDIS test token.
MFC after: 3 days
Sponsored by: genua mbh
1) Use the TX FIFO empty interrupts to poll the transmit FIFO usage,
instead of using own software counters and waiting for SOF
interrupts. Assume that enough FIFO space is available to execute one
USB OUT transfer of any kind when the TX FIFO is empty.
2) Use the host channel halted event to asynchronously wait for host
channels to be disabled instead of waiting for SOF interrupts. This
results in less turnaround time for re-using host channels and at the
same time increases the performance.
The network transmit performance measured by "iperf" for the "RPi-B v1
2011/12" board, increased from 45MBit/s to 65Mbit/s after applying the
changes above.
No regressions seen using:
- High Speed (BULK, CONTROL, INTERRUPT)
- Full Speed (All transfer types)
- Low Speed (Control and Interrupt)
MFC after: 1 month
Submitted by: Daisuke Aoyama <aoyama@peach.ne.jp>
stage processing is only allowed after the setup complete event has
been received. Else a race may occur and the OUT data can be corrupted.
While at it ensure resetting a FIFO has the required wait loop.
MFC after: 3 days
interface without breaking ABI or API compatibility with existing drivers.
The existing data structures used to communicate between the kernel and
driver portions of PPS processing contain no spare/padding fields and no
flags field or other straightforward mechanism for communicating changes
in the structures or behaviors of the code. This makes it difficult to
MFC new features added to the PPS facility. ABI compatibility is
important; out-of-tree drivers in module form are known to exist. (Note
that the existing api_version field in the pps_params structure must
contain the value mandated by RFC 2783 and any RFCs that come along after.)
These changes introduce a pair of abi-version fields which are filled in
by the driver and the kernel respectively to indicate the interface
version. The driver sets its version field before calling the new
pps_init_abi() function. That lets the kernel know how much of the
pps_state structure is understood by the driver and it can avoid using
newer fields at the end of the structure that it knows about if the driver
is a lower version. The kernel fills in its version field during the init
call, letting the driver know what features and data the kernel supports.
To implement the new version information in a way that is backwards
compatible with code from before these changes, the high bit of the
lightly-used 'kcmode' field is repurposed as a flag bit that indicates the
driver is aware of the abi versioning scheme. Basically if this bit is
clear that indicates a "version 0" driver and if it is set the driver_abi
field indicates the version.
These changes also move the recently-added 'mtx' field of pps_state from
the middle to the end of the structure, and make the kernel code that uses
this field conditional on the driver being abi version 1 or higher. It
changes the only driver currently supplying the mtx field, usb_serial, to
use pps_init_abi().
Reviewed by: hselasky@
'BUS_PROBE_DEFAULT'. This allows bhyve's 'ppt' driver to claim ownership
of the device and pass it through to the guest.
In the common case where there are no competing drivers for USB controllers
this change is a no-op.
Reviewed by: hselasky
MFC after: 2 weeks
Previously, the driver was trying to blink the LED in the newstate
function, but that only gets called once (unlike OpenBSD's net80211
stack). Move the LED blinking to set_channel().
While there, don't try to set the channel when we switch to the SCAN
state. This is already accomplished by the set_channel() function.
MFC after: 1 week
been done by U-Boot. This allows the USB to work when we load the kernel
directly.
No dma sync is performed after these operations as the data we read/write
is not used by the cpu after the calls to the maimbox driver.
Differential Revision: https://reviews.freebsd.org/D1940
Reviewed by: imp, Michal Meloun (meloun AT miracle.cz)
MFC after: 1 Week
Sponsored by: ABT Systems Ltd
when re-enumerating a FULL speed device. Else the wrong max packet
setting might be used when trying to re-enumerate a FULL speed device.
MFC after: 3 days
interrupt status bit. According to the UHCI controller specification
the host controller halted interrupt is non-maskable.
PR: 156596
Tested by: adrian @
MFC after: 1 week
has been removed and the driver has been greatly simplified and
optimised for FreeBSD. The driver is currently not built by default.
Requested by: Bruce Simpson <bms@fastmail.net>
allocations if only one element should be allocated per page
cache. Make one allocation per element compile time configurable. Fix
a comment while at it.
Suggested by: ian @
MFC after: 1 week
that we should use a normal-TRB if there are more TRBs extending the
data-stage TRB. Add a dedicated state bit to the internal USB transfer
flags to handle this case.
Reported by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
MFC after: 1 week
every operation to retrieve the bs_cookie value almost nothing actually uses.
The bus_space struct contains a private data pointer (poorly named bs_cookie,
now renamed to bs_privdata) which is used only by a few old armv4 xscale
implementations. The bus_space functions were all defined to take this
value as the first parameter instead of the bus_space_tag_t, requiring all
the inline macro and function expansions to dereference the tag to pass it
to another function, which never uses it. Now all the functions take the tag
as the first parameter and retrieve the privdata if they need it.
Also fix a couple bus_space_unmap() implementations that were calling
kva_free() instead of pmap_unmapdev().
Discussed with: cognet
This makes Mac OS X happy when it returns back from suspending.
o Switch notify state after data is transferred, but not before.
o Consider there is also Super Speed mode.
o Do not set stall bit on any pipes in device mode as Mac OS X seems
don't support it.
In collaboration with: hselasky@
Required when communicating to Mac OS X USB host stack.
o Also don't set stall bit to TX pipe in device mode as seems Mac OS X
don't clears it as it should.
Discussed with: hselasky@
simultaneously detaching kernel drivers on the same USB device we can
get stuck in the "usb_wait_pending_ref_locked()" function because the
conditions needed for allowing detach are not met. The "destroy_dev()"
function waits for all system calls involving the given character
device to return. Character device system calls may lock the USB
enumeration lock, which is also held when "destroy_dev()" is
called. This can sometimes lead to a deadlock not noticed by
WITNESS. The current solution is to ensure the calling thread is the
only one holding the USB enumeration lock and prevent other threads
from getting refs while a USB device detach is ongoing. This turned
out not to be sufficient. To solve this deadlock we could use
"destroy_dev_sched()" to schedule the device destruction in the
background, but then we don't know when it is safe to free() the
private data of the character device. Instead a callback function is
executed by the USB explore process to kill off any leftover USB
character devices synchronously after the USB device explore code is
finished and the USB enumeration lock is no longer locked. This makes
porting easier and also ensures us that character devices must
eventually go away after a USB device detach.
While at it ensure that "flag_iserror" is only written when "priv_mtx"
is locked, which is protecting it.
MFC after: 5 days
devices which don't support the synchronize cache SCSI command are
likely to also not support the prevent-allow medium removal SCSI
command.
PR: 185747
MFC after: 1 week
socket-buffer implementations, introduce a return value for MCLGET()
(and m_cljget() that underlies it) to allow the caller to avoid testing
M_EXT itself. Update all callers to use the return value.
With this change, very few network device drivers remain aware of
M_EXT; the primary exceptions lie in mbuf-chain pretty printers for
debugging, and in a few cases, custom mbuf and cluster allocation
implementations.
NB: This is a difficult-to-test change as it touches many drivers for
which I don't have physical devices. Instead we've gone for intensive
review, but further post-commit review would definitely be appreciated
to spot errors where changes could not easily be made mechanically,
but were largely mechanical in nature.
Differential Revision: https://reviews.freebsd.org/D1440
Reviewed by: adrian, bz, gnn
Sponsored by: EMC / Isilon Storage Division
scatter-gather XHCI TRB entries for its payload data. The XHCI
controller can handle at least 65536 bytes per scatter-gather list
entry.
MFC after: 1 week
Suggested by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
is called from "xhci_configure_reset_endpoint()". Ensure the 3-strikes
error feature is always enabled except for ISOCHRONOUS transfers.
MFC after: 1 week
Suggested by: marius@
- Simplify MSI allocation to what is actually needed for a single one.
- Release the MSI and the corresponding bus resource as appropriate when
either the interrupt resource cannot be allocated or setting up the
interrupt fails.
- Error out when interrupt allocation or setup fails and polling is
disabled.
- Release the MSI after the corresponding bus resource so the former is
not leaked on detach.
- Remove a redundant softc member.
MFC after: 3 days
re-using a hardware propritary transfer descriptor, PTD, in USB host
mode. If the PTD's are recycled too quickly, it has been observed that
the hardware simply fails to schedule the requested job or resets
completely disconnecting all devices.
SAF1761 OTG driver. Currently the driver logic is very simple and
double buffering the USB transactions is not done. Also you need to
use an external USB high speed USB HUB for reliable FULL speed
outgoing ISOCHRONOUS traffic, because the internal one chokes on
so-called split transfers above 188 bytes.
search (i.e. without returning any result) and you would end up with a
random MAC address.
Change the search algorithm to a recursive one to ensure that all the nodes
on DTS will be verified.
The previous algorithm could not keep up if the DTS has too many sub-nodes.
While here, fix the punctuation on comments.
the r241987 commit message, instead of having users locally overriding
the value using tunables in /boot/loader.conf .
Found by: Adam Parco
Discussed with: Nick Hibma
E5372 with different product IDs.
Interestingly, the standard E5372 IDs (12d1:1506) are currently listed in
u3g.c and are the same as the E3131. However, the R215/E5372 is an NCM
device and works well with cdce(4) whereas the E3131 isn't. More work
may be needed to better identify the other device IDs.
MFC after: 1 week
ports. The current bitmap array was too small to hold more than 16
bits and would at some point toggle the context size, which then would
trigger an enumeration fault and cause a fallback to the EHCI
companion controller, if any.
MFC after: 3 days
Huawei. It might appear as if the firmware is allocating memory blocks
according to the USB transfer size and if there is initially a lot of
data, like at the answering machine prompt, it simply dies without any
apparent reason. The simple workaround for this is to force a zero
length packet at hardware level after every 512 bytes of data. This
will force the other side to use smaller memory blocks aswell.
MFC after: 1 week
- Cleanup some register reads and writes to use existing register
access macros.
- Ensure code which only applies to the control endpoint is not run
for other endpoints in the data transfer path.
MFC after: 3 days
ethernet class.
Note: This is untested as I do not have a device like this. That is
reflected in the MFC timeout.
PR: 192345
Submitted by: rozhuk.im gmail.com
MFC after: 4 weeks
