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
don't implement link power management, LPM.
This fixes error code XHCI_TRB_ERROR_BANDWIDTH for isochronous USB 3.0
transactions.
Submitted by: Horse Ma <Shichun.Ma@dell.com>
MFC after: 1 week
Sponsored by: Mellanox Technologies
Name each ehci driver uniquely.
This remove the warning printed at each arm boot :
module_register: cannot register simplebus/ehci from kernel; already loaded from kernel
A similar fix was done in r333074 but imx_ehci wasn't renamed and generic_ehci wasn't
present at that time.
This driver hasn't been relevant in almost 15 years. It was for a product on the
shelves for about 6 months in 2003/2004. I've not updated the driver since then,
and have had nobody talk to me about it since maybe 2006 or 2007. It doesn't
implement a standard interface, and can be better done with libusb. All the
action has moved to webcamd for newer, more fully featured hardware. It makes no
appearances in the nycbug dmesg archive.
Relnotes: yes
MFC After: 3 days
key is pressed at the same time as a regular key, that means key with
modifier is output. Some automated USB keyboards like Yubikeys need this.
This fixes a regression issue after r357861.
Reported by: Adam McDougall <mcdouga9@egr.msu.edu>
PR: 224592
PR: 233884
MFC after: 3 days
Sponsored by: Mellanox Technologies
Skip device mode switch step on Fountain-based devices as they don't
support RAW_SENSOR_MODE command, so failing to attach.
This was reproduced on PowerBook G4 (model PowerBook5,6) equipped with
product ID 0x020e
Reviewed by: hselasky
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D24005
maximal input report size instead of wMaxPacketSize.
If the USB frame length is set to 1024 bytes, WMT_BSIZE, the EETI controller
will pack multiple touch events in the packet and the current code will only
process the first touch event.
As a result some important events are lost like releasing the finger from the
touchscreen.
Use the maximal input report size as buffer size instead.
PR: 244718
Tested by: Oskar Holmlund <oskar.holmlund@ohdata.se>, wulf
MFC after: 3 days
Discussed with: hselasky
Limiting frame size to maximum packet size breaks devices which have input
report size larger than wMaxPacketSize. Maximal input report size should be
used instead.
Revert the commit as it have not been MFC-ed yet.
Discussed with: hselasky
will pack multiple touch events in the packet and the current code will only
process the first touch event.
As a result some important events are lost like releasing the finger from the
touchscreen.
Use the maximum maximum packet size as buffer size instead.
Submitted by: Oskar Holmlund <oskar.holmlund@ohdata.se>
PR: 244718
MFC after: 3 days
Sponsored by: Mellanox Technologies
Touch Digitizer V04 report descriptor declares 'Contact Count Maximum' usage
as constant. That was not supported by descriptor parser.
PR: 232040
Reported by: Sergei Akhmatdinov <sakhmatd@darkn.space>
MFC after: 1 week
because it clobbers the super speed link status when a device is in super
speed mode. Currently the power bit is not needed for anything in the USB
hub driver.
This fixes USB warm reset for super speed devices.
Tested by: Shichun.Ma@dell.com
MFC after: 3 days
Sponsored by: Mellanox Technologies
This fixes a regression issue after r357861.
Reported by: James Wright <james.wright@jigsawdezign.com>
PR: 224592
PR: 233884
MFC after: 3 days
Sponsored by: Mellanox Technologies
key-codes from the USB keyboard. Negative key-codes are currently skipped.
While at it use the bit size value provided by the HID location structure
instead of assuming a value of 8.
This fixes a regression issue after r357861.
Reported by: Minoru TANABE <kotanabe3@gmail.com>
PR: 224592
PR: 233884
MFC after: 3 days
Sponsored by: Mellanox Technologies
if_capabilities indicates capabilities supported by the hardware;
if_capenable which are enabled. Note that rx checksum is still disabled
in the driver at compile time.
Submitted by: Johannes <iz-rpi04@hs-karlsruhe.de>
MFC after: 2 weeks
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked). Use it in
preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Reviewed by: hselasky, kib
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D23632
Add support for decoding pressed keys as a bitmap. The keys in the
bitmap are described in the interface specific HID descriptor. Some
keyboards even have multiple input interfaces, only using the bitmap
method when the event array is full. That typically means when more
than seven keys are pressed simultaneously.
The internals of the USB keyboard driver have been slightly reworked
to keep track of all keys in a single bitmap having 256 bits. This
bitmap is then divided into blocks of 64-bits as an optimisation.
Simplify automatic key repeat logic, because only the last key pressed
can be repeated.
PR: 224592
PR: 233884
Tested by: Alex V. Petrov <alexvpetrov@gmail.com>
MFC after: 1 week
Sponsored by: Mellanox Technologies
This avoids getting the XHCI_TRB_ERROR_CONTEXT_STATE error code from the XHCI
controller when the endpoint is disabled or already stopped.
Suggested by: Shichun.Ma@dell.com
MFC after: 1 week
Sponsored by: Mellanox Technologies
The newer versions of RPi FDT flipped the order of the interrupts
specification and added an 'interrupt-names' property for driver aide in
finding the correct interrupt, rather than assuming the positions. Use it if
it's available, or fallback to the old method if there is no interrupt-names
property with a usb value.
This has been tested with both old RPi3B FDT and new RPi3B FDT, USB again
works on the latter.
Reported by: Tom Yan <tom.ty89 gmail com>
MFC after: 3 days
Do not configure any endpoint twice, but instead keep track of which
endpoints are configured on a per device basis, and use an evaluate
endpoint context command instead. When changing the configuration make
sure all endpoints get deconfigured and the configured endpoint mask
is reset.
This fixes an issue where an endpoint might stop working if there is
an error and the endpoint needs to be reconfigured as a part of the
error recovery mechanism in the FreeBSD USB stack.
Tested by: Shichun.Ma@dell.com
MFC after: 1 week
Sponsored by: Mellanox Technologies
r356087 made it rather innocuous to double-register built-in keyboard
drivers; we now set a flag to indicate that it's been registered and only
act once on a registration anyways. There is no misleading here, as the
follow-up kbd_delete_driver will actually remove the driver as needed now
that the linker set isn't also consulted after kbdinit.
Keyboard drivers are generally registered via linker set. In these cases,
they're also available as kmods which use KPI for registering/unregistering
keyboard drivers outside of the linker set.
For built-in modules, we still fire off MOD_LOAD and maybe even MOD_UNLOAD
if an error occurs, leading to registration via linker set and at MOD_LOAD
time.
This is a minor optimization at best, but it keeps the internal kbd driver
tidy as a future change will merge the linker set driver list into its
internal keyboard_drivers list via SYSINIT and simplify driver lookup by
removing the need to consult the linker set.
Most keyboard drivers are using the genkbd implementations as it is;
formally use them for any that aren't set and make
genkbd_get_fkeystr/genkbd_diag private.
These invocations were directly calling enkbd_diag(), rather than
indirection back through kbdd_diag/kbdsw. While they're functionally
equivent, invoking kbdd_diag where feasible (i.e. not in a diag
implementation) makes it easier to visually identify locking needs in these
other drivers.
The datasheets for these chips claim the maximum is 921,600, but testing
shows these two higher rates also work (but no rates above 921,600 other
than these two work; these represent dividing the base buad clock by 3 and 2
respectively).
o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.
Some places in network code may need to verify that an ethernet address
is not the 'zero' address. Provide a standard macro ETHER_IS_ZERO for
this purpose, similar to the ETHER_IS_BROADCAST macro already available.
This patch also removes previous ETHER_IS_ZERO definitions in several
USB ethernet drivers, in favor of this centrally-located macro.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Submitted by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed by: erj@
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D21240
When epoch(9) was introduced to network stack, it was basically
dropped in place of existing locking, which was mutexes and
rwlocks. For the sake of performance mutex covered areas were
as small as possible, so became epoch covered areas.
However, epoch doesn't introduce any contention, it just delays
memory reclaim. So, there is no point to minimise epoch covered
areas in sense of performance. Meanwhile entering/exiting epoch
also has non-zero CPU usage, so doing this less often is a win.
Not the least is also code maintainability. In the new paradigm
we can assume that at any stage of processing a packet, we are
inside network epoch. This makes coding both input and output
path way easier.
On output path we already enter epoch quite early - in the
ip_output(), in the ip6_output().
This patch does the same for the input path. All ISR processing,
network related callouts, other ways of packet injection to the
network stack shall be performed in net_epoch. Any leaf function
that walks network configuration now asserts epoch.
Tricky part is configuration code paths - ioctls, sysctls. They
also call into leaf functions, so some need to be changed.
This patch would introduce more epoch recursions (see EPOCH_TRACE)
than we had before. They will be cleaned up separately, as several
of them aren't trivial. Note, that unlike a lock recursion the
epoch recursion is safe and just wastes a bit of resources.
Reviewed by: gallatin, hselasky, cy, adrian, kristof
Differential Revision: https://reviews.freebsd.org/D19111
