Add support for the "snps,dis_rxdet_inp3_quirk" quirk needed
at least on SolidRun's HoneyComb.
Reviewed by: manu, mw
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32921
Currently, to support 64-byte contexts, xhci_ctx_[gs]et_le(32|64) take a
pointer to the field within a 32-byte context and, if 64-byte contexts
are in use, compute where the 64-byte context field is and use that
instead by deriving a pointer from the 32-byte field pointer. This is
done by exploiting a combination of 64-byte contexts being the same
layout as their 32-byte counterparts, just with 32 bytes of padding at
the end, and that all individual contexts are either in a device
context or an input context which itself is page-aligned. By masking out
the low 4 bits (which is the offset of the field within the 32-byte
contxt) of the offset within the page, the offset of the invididual
context within the containing device/input context can be determined,
which is itself 32 times the number of preceding contexts. Thus, adding
this value to the pointer again gets 64 times the number of preceding
contexts plus the field offset, which gives the offset of the 64-byte
context plus the field offset, which is the address of the field in the
64-byte context.
However, this involves a fair amount of lying to the compiler when
constructing these intermediate pointers, and is rather difficult to
reason about. In particular, this is problematic for CHERI, where we
compile the kernel with subobject bounds enabled; that is, unless
annotated to opt out (e.g. for C struct inheritance reasons where you
need to be able to downcast, or containerof idioms), a pointer to a
member of a struct is a capability whose bounds only cover that field,
and any attempt to dereference outside those bounds will fault,
protecting against intra-object buffer overflows. Thus the pointer given
to xhci_ctx_[gs]et_le(32|64) is a capability whose bounds only cover the
field in the 32-byte context, and computing the pointer to the 64-byte
context field takes the address out of bounds, resulting in a fault when
later dereferenced.
This can be cleaned up by using a different abstraction. Instead of
doing the 32-byte to 64-byte conversion on access to the field, we can
do the conversion when getting a pointer to the context itself, and
define proper 64-byte versions of contexts in order to let the compiler
do all the necessary arithmetic rather than do it manually ourselves.
This provides a cleaner implementation, works for CHERI and may even be
slightly more performant as it avoids the need to mess with masking
pointers (which cannot in the general case be optimised by compilers to
be reused across accesses to different fields within the same context,
since it does not know that the contexts are over-aligned compared with
the C ABI requirements).
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32554
When EVDEV_SUPPORT was introduced, the USB transfers may be running
after the main FIFO is closed. In connection to this a race may appear
which can lead to use-after-free scenarios. Fix this for all FIFO
consumers by initializing and resetting the FIFO queues under the
lock used by the client. Then the client driver will see an empty
queue in all cases a race may appear.
Found by: pho@
MFC after: 1 week
Sponsored by: NVIDIA Networking
While IEEE80211_R_BAND was defined, there was no place to store the
band. Add a field for that, adjust ieee80211_lookup_channel_rxstatus()
to require it, and update drivers passing "R_{FREQ|IEEE}" in already to
provide the band as well. For the moment keep the fall-back code
requiring all three fields.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D30662
Change the probe return value from BUS_PROBE_DEFAULT to BUS_PROBE_GENERIC
given this is the "generic" attach method. This allows individual
drivers using XHCI generic but needing their own intialisation to
gain priority for attaching over the generic implementation.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32257
When a usb device is detached, usb_pc_dmamap_destroy() called
bus_dmamap_destroy() while the map was still loaded. That's harmless on x86
architectures, but on all other platforms it causes bus_dmamap_destroy() to
return EBUSY and leak away any memory resources (including bounce buffers)
associated with the mapping, as well as any allocated map structure itself.
This change introduces a new is_loaded flag to the usb_page_cache struct to
track whether a map is loaded or not. If the map is loaded,
bus_dmamap_unload() is called before bus_dmamap_destroy() to avoid leaking
away resources.
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D32208
We can now set promisc and allmulti modes.
Filtering of given multicast addresses is not supported.
Changing the mode is done by sending a command described in:
"USB CDC Subclass Specification for Ethernet Devices v1.2, section 6.2.4".
This means that at least in theory this feature should work with all
modems that are using this driver.
This fixes Huawei E3372h-320 running new firmware in "HiLink" mode.
Previously it would reset a few seconds after its mode was changed
with "usb_modeswitch".
Setting RX filter to default value at the end of attach function
fixed that.
Sponsored by: Stormshield
Obtained from: Semihalf
Differential revision: https://reviews.freebsd.org/D31766
MFC after: 2 weeks
Reviewed by: hps
After switching the dongle to the Huawei alternate mode(modem mode)
with usb_modeswitch the serial interfaces had all of their ids set to
0xFF.
After modifying umodem to work with that it attached successfully and
I've managed to configure device with standard AT commands to get
internet connection.
folder, only keeping the zero length packet API introduced in sys/dev/usb
after more reports of USB serial devices not supporting ZLPs.
Reported by: mav@
MFC after: 1 week
Sponsored by: NVIDIA Networking
port devices. If it gets eaten it is fine. Many USB device side implementations
don't properly support the clear endpoint halt command and if they do, data is lost
because the transmit FIFO is typically reset when this command is received.
Tested by: jmg
MFC after: 1 week
Sponsored by: NVIDIA Networking
xpt_bus_register and xpt_bus_deregister returns a hybrid error that's
neither a cam_status, nor an errno, but a mix of both. Update
xpt_bus_register and xpt_bus_deregister to return an errno. The vast
majority of current users compare against zero, which can also be
spelled CAM_SUCCESS. Nobody uses CAM_FAILURE, so remove that symbol
to prevent comfusion (nothing returns it either).
Where the return value is saved, ensure that the variable 'error' is
used to store an errno and 'status' is used to store a cam_status where
it makes the code clearer (usually just in functions that already mix
and match). Where the return value isn't used at all, avoid storing it
at all.
Reviewed by: scottl@, mav@ (earlier version)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30860
This makes it more usable in that dhclient will autolaunch from devd
now when cdce devices are plugged in.. It also sets the baudrate, but
this isn't exported via tools, and CDCE doesn't have a good way to
specify the media type, so there isn't a good way to tell userland
what the speed is currently...
Reviewed by: hps
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D30625
Now that the upper layers all go through a layer to tie into these
information functions that translates an sbuf into char * and len. The
current interface suffers issues of what to do in cases of truncation,
etc. Instead, migrate all these functions to using struct sbuf and these
issues go away. The caller is also in charge of any memory allocation
and/or expansion that's needed during this process.
Create a bus_generic_child_{pnpinfo,location} and make it default. It
just returns success. This is for those busses that have no information
for these items. Migrate the now-empty routines to using this as
appropriate.
Document these new interfaces with man pages, and oversight from before.
Reviewed by: jhb, bcr
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D29937
Use the accessor function to get the softc for this sim. This also drops
an unneeded cast.
Sponsored by: Netflix
Reviewed by: mav@, hselasky@
Differential Revision: https://reviews.freebsd.org/D30360
The second set of USB transfer is requested by hkbd(4) and
should improve HID keyboard handling in kdb and panic contexts.
MFC after: 1 week
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D30486
Which happens when USB transfer setup is failed.
MFC after: 1 week
PR: 254974
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D30485
This fixes inability to start USB xfers in a case when FIFO has been
already open()-ed but no read() or poll() calls has been issued yet.
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D30343
This fixes lose of evdev events after moused has been killed.
While here use bitwise operations for UMS_EVDEV_OPENED flag.
Reviewed by: hselasky
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D30342
behind USB HUBs are detected and the USB reset counter logic will kick in
preventing enumeration of continuously failing ports.
Submitted by: phk@
Tested by: bz@
PR: 237666
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
says it should be max 10 milliseconds.
This may fix some USB enumeration issues:
> usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_IOERROR, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 3 failed,
Found by: Zhichao1.Li@dell.com
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
0 milliseconds and 2 seconds inclusivly. Some style fixes while at it.
The USB specification has minimum values and maximum values,
and not only minimum values.
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
