PCIe allows for MSI-X BAR to be either dedicated, or MSI-X Table may
be co-located in some functional BAR. In the later case xhci(4) is
unable to allocate active resource for the table because BAR is
already activated.
Handle it by checking for this special case, and not try to alloc
resource if MSI-X BAR is IO.
Reported and tested by: emaste
Reviewed by: emaste, hselasky
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D26913
vendor ID string to say just "Microchip Technology" -- the buyout of
Standard Microsystems happened in 2012 and the SMC/SMSC names are pretty
much retired at this point.
PR: 241406
This update adds support for:
HW VLAN tagging
HW checksum offload for IPv4 and IPv6
tx and rx aggreegation (for full gige speeds)
multiple transactions
In my testing, I am able to get 900-950Mbps depending upon
TCP or UDP, which is a significant improvement over the previous
91Mbps (~8kint/sec*1500bytes/packet*1packet/int).
Reviewed by: hselasky
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D25809
In r178354 with the introduction of multi-bss ("vap") support factoring
out started and with r193340 ieee80211_media_change() no longer returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should not
be called directly but is registered with ieee80211_vap_attach() instead.
Some drivers have not been fully converted. After fixing the return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra
function, where possible as well.
PR: 248955
Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
At least on Orange Pi PC Plus even the host mode does not work without
enabling the phy and setting it to the host mode.
The driver will now parse dr_mode property and will try to configure
itself and the phy accordingly.
OTG mode is not supported yet, so it is treated as the device / peripheral
mode.
The phy is enabled -- powered on -- only for the host mode.
The device mode requires support from a phy driver, e.g., aw_usbphy on
Allwinner platform.
aw_usbphy does not support the device mode, so it cannnot work yet.
MFC after: 6 weeks
Otherwise, I get this panic:
panic: awusbdrd_reg: Invalid register 0x342
It looks that musb code both writes and reads at least MUSB2_REG_TXDBDIS.
MFC after: 5 weeks
X-MFC after: r365399
Investigating a hang I found having some more error information
available would be helpful, so be more verbose and also tell cam/xpt
status in case of error/panic.
Reviewed by: hselasky
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D26287
While debugging a hang I noticed that in case of error in
umass_cam_attach_sim() we miss a cam_sim_free() call.
Added that to not leak resources.
Reviewed by: hselasky
MFC after: 3 days
Differential Revision: D26287
The "Intel Sunrise Point-LP USB 3.0 controller" doesn't update the wMaxPacket
field in the control endpoint context automatically causing a BABBLE error code
on the initial first USB device descriptor read, when the bMaxPacketSize is not
8 bytes.
Reported by: wulf@
PR: 248784
MFC after: 1 week
Sponsored by: Mellanox Technologies
For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.
Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.
Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.
Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.
ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.
Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.
MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091
The AMD's Ryzen 3 3200g XHCI controllers apparently need the evaluate
control endpoint context command, but we don't need to issue this
command when the bMaxPacketSize is received after the read of the USB
device descriptor, because this part should be handled automatically.
PR: 248784
Tested by: emaste, hselasky
MFC after: 1 week
Sponsored by: Mellanox Technologies
It was a driver for a USB FM tuner that was available in the market in 2002. I
wrote the driver in 2003. I've not used it since 2005 or so, so it's time to
retire this driver. No userland code ever interfaced to the special device it
created. There's no user base: the last bug I received on this driver was in
2004.
Relnotes: Yes
The XHCI specification says that the XHCI controller should detect
reception of the USB device descriptors, and automatically update
the max packet size in the control endpoint context.
Differential Revision: https://reviews.freebsd.org/D26104
Reviewed by: kp@
MFC after: 1 week
Sponsored by: Mellanox Technologies
- hoist all request / response structures from function level to top level
- replace magic numeric literals with constants
- regroup types, data and functions
- remove setting of the id field in responses as they are completely
overwritten with data from the device
- centralize setting of the id field as it is always set to the value of
request type
- fix setting and querying of open-drain vs push-pull configuration of
an output pin -- it's always in one of those configurations
- detect special pin configurations: a pin in a special configuration is
neither general purpose input or output
- there is still no support for setting special configurations
MFC after: 2 weeks
The newer hardware revisions of the Raspberry Pi 4 removed the ability of
the VIA VL805 xhci controller to load its own firmware. Instead the
firmware must be installed at the appropriate time by the VideoCore
coprocessor.
Submitted by: Robert Crowston <crowston_protonmail.com>
Differential Revision: https://reviews.freebsd.org/D25261
Handle the fact that parts of usb(4) can be compiled into the boot
loader, where M_WAITOK does not guarantee a successful allocation.
PR: 240545
Submitted by: Andrew Reiter <arr@watson.org> (original version)
Reviewed by: hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25706
Create an acpi attachment for the DWC USB OTG device. This is present in
the Raspberry Pi 4 in the USB-C port normally used to power the board. Some
firmware presents the kernel with ACPI tables rather than FDT so we need
an ACPI attachment.
Submitted by: Greg V <greg_unrelenting.technology>
Approved by: hselasky (removal of All rights reserved)
Differential Revision: https://reviews.freebsd.org/D25203
description of items residing in a so-called union. FreeBSD currently
only supports 4 such pop levels.
If the push level is not restored within the processing of the same
HID item, an invalid memory location may be used for subsequent HID
item processing.
Verify that the push level is always valid when processing HID items.
Reported by: Andy Nguyen (Google)
MFC after: 3 days
Sponsored by: Mellanox Technologies
This specifically fixes that TX frames are large enough now to hold a 3900 odd
byte AMSDU (the little ones); me flipping it on earlier messed up transmit!
Tested:
* if_run, STA mode, TX/RX TCP/UDP iperf. TCP is now back to normal and
correctly does ~ 3200 byte AMSDU/fast frames (2x1600ish byte MSDUs).
* Set the tx/rx chains based on the existing MIMO eeprom reads
* Add 3-chain rates
Tested:
* MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), 2g/5g STA
* MAC/BBP RT3593 (rev 0x0402), RF RT3053 (MIMO 3T3R), 2g/5g STA
Now that I'm a proud owner of an ASUS USB-N66, I can test 2G/5G and
3-stream configurations.
For now, just flip on 5G HT rates. I've tested this in both
5G HT20 and 5G 11a modes. It's still one stream for now until
we verify that the number of streams reported (ie the MIMO below)
is actually the number of 11n streams, NOT the number of antennas.
(They don't have to match! You can have more antennas than MIMO
streams!)
Tested:
* run0: MAC/BBP RT3593 (rev 0x0402), RF RT3053 (MIMO 3T3R)
* Enable self-generated 11n frames
* add MCS rates for 1-stream and 2-stream rates; will do 3-stream
once the rest of this tests out OK with other people.
* Hard-code 1 stream for now
* Add A-MPDU RX mbuf tagging
* RTS/CTS if doing RTSCTS in HT protmode as well as legacy; they're
separate configuration flags
* Update the amrr rate index stuff - walk the rates array like others
to find the right one - this now works for MCS and CCK/OFDM rates
* Add support for atheros fast frames/AMSDU support as we can generate
those in net80211.
TODO:
* HT40 isn't enabled yet
* No A-MPDU support just yet; that requires some more firmware research
and maybe porting some ath(4) A-MPDU support/tracking into net80211
* Short preamble flags aren't set yet for MCS; need to check the linux
driver and see what's going on there
* Add 3x3 rates and set tx/rx stream configuration appropriately
* More 5GHz testing; I have a 3x3 dual band USB NIC coming soon that'll
let me test this.
* Figure out why the RX path isn't performing as fast as it could -
there's only a single buffer loaded at a time for the receive path
in the USB bulk handler and this may not be super useful.
Tested:
* RT5390 usb, 1x1, RF5370 (2GHz radio), STA mode - A-MSDU TX, A-MPDU RX
Submitted by: Ashish Gupta <ashishgu@andrew.cmu.edu>
Differential Revision: https://reviews.freebsd.org/D22840
