kernel/linux.git/include/uapi/linux/usb, branch v6.12.80

USB: gadget: f_hid: Add GET_REPORT via userspace IOCTL

2024-08-22T09:25:59+00:00

While supporting GET_REPORT is a mandatory request per the HID specification the current implementation of the GET_REPORT request responds to the USB Host with an empty reply of the request length. However, some USB Hosts will request the contents of feature reports via the GET_REPORT request. In addition, some proprietary HID 'protocols' will expect different data, for the same report ID, to be to become available in the feature report by sending a preceding SET_REPORT to the USB Device that defines what data is to be presented when that feature report is subsequently retrieved via GET_REPORT (with a very fast < 5ms turn around between the SET_REPORT and the GET_REPORT). There are two other patch sets already submitted for adding GET_REPORT support. The first [1] allows for pre-priming a list of reports via IOCTLs which then allows the USB Host to perform the request, with no further userspace interaction possible during the GET_REPORT request. And another [2] which allows for a single report to be setup by userspace via IOCTL, which will be fetched and returned by the kernel for subsequent GET_REPORT requests by the USB Host, also with no further userspace interaction possible. This patch, while loosely based on both the patch sets, differs by allowing the option for userspace to respond to each GET_REPORT request by setting up a poll to notify userspace that a new GET_REPORT request has arrived. To support this, two extra IOCTLs are supplied. The first of which is used to retrieve the report ID of the GET_REPORT request (in the case of having non-zero report IDs in the HID descriptor). The second IOCTL allows for storing report responses in a list for responding to requests. The report responses are stored in a list (it will be either added if it does not exist or updated if it exists already). A flag (userspace_req) can be set to whether subsequent requests notify userspace or not. Basic operation when a GET_REPORT request arrives from USB Host: - If the report ID exists in the list and it is set for immediate return (i.e. userspace_req == false) then response is sent immediately, userspace is not notified - The report ID does not exist, or exists but is set to notify userspace (i.e. userspace_req == true) then notify userspace via poll: - If userspace responds, and either adds or update the response in the list and respond to the host with the contents - If userspace does not respond within the fixed timeout (2500ms) but the report has been set prevously, then send 'old' report contents - If userspace does not respond within the fixed timeout (2500ms) and the report does not exist in the list then send an empty report Note that userspace could 'prime' the report list at any other time. While this patch allows for flexibility in how the system responds to requests, and therefore the HID 'protocols' that could be supported, a drawback is the time it takes to service the requests and therefore the maximum throughput that would be achievable. The USB HID Specification v1.11 itself states that GET_REPORT is not intended for periodic data polling, so this limitation is not severe. Testing on an iMX8M Nano Ultra Lite with a heavy multi-core CPU loading showed that userspace can typically respond to the GET_REPORT request within 1200ms - which is well within the 5000ms most operating systems seem to allow, and within the 2500ms set by this patch. [1] https://lore.kernel.org/all/20220805070507.123151-2-sunil@amarulasolutions.com/ [2] https://lore.kernel.org/all/20220726005824.2817646-1-vi@endrift.com/ Signed-off-by: David Sands Signed-off-by: Chris Wulff Link: https://lore.kernel.org/r/20240817142850.1311460-2-crwulff@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: add capability for dfu functional descriptor

2024-08-13T08:38:46+00:00

Add the ability for the USB FunctionFS (FFS) gadget driver to be able to create Device Firmware Upgrade (DFU) functional descriptors. [1] This patch allows implementation of DFU in userspace using the FFS gadget. The DFU protocol uses the control pipe (ep0) for all messaging so only the addition of the DFU functional descriptor is needed in the kernel driver. The DFU functional descriptor is written to the ep0 file along with any other descriptors during FFS setup. DFU requires an interface descriptor followed by the DFU functional descriptor. This patch includes documentation of the added descriptor for DFU and conversion of some existing documentation to kernel-doc format so that it can be included in the generated docs. An implementation of DFU 1.1 that implements just the runtime descriptor using the FunctionFS gadget (with rebooting into u-boot for DFU mode) has been tested on an i.MX8 Nano. An implementation of DFU 1.1 that implements both runtime and DFU mode using the FunctionFS gadget has been tested on Xilinx Zynq UltraScale+. Note that for the best performance of firmware update file transfers, the userspace program should respond as quick as possible to the setup packets. [1] https://www.usb.org/sites/default/files/DFU_1.1.pdf Signed-off-by: David Sands Co-developed-by: Chris Wulff Signed-off-by: Chris Wulff Link: https://lore.kernel.org/r/20240811000004.1395888-2-crwulff@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: functionfs: Add DMABUF import interface

2024-02-17T16:00:09+00:00

This patch introduces three new ioctls. They all should be called on a data endpoint (ie. not ep0). They are: - FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a DMABUF object to attach to the endpoint. - FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the DMABUF to detach from the endpoint. Note that closing the endpoint's file descriptor will automatically detach all attached DMABUFs. - FUNCTIONFS_DMABUF_TRANSFER, which requests a data transfer from / to the given DMABUF. Its argument is a structure that packs the DMABUF's file descriptor, the size in bytes to transfer (which should generally be set to the size of the DMABUF), and a 'flags' field which is unused for now. Before this ioctl can be used, the related DMABUF must be attached with FUNCTIONFS_DMABUF_ATTACH. These three ioctls enable the FunctionFS code to transfer data between the USB stack and a DMABUF object, which can be provided by a driver from a completely different subsystem, in a zero-copy fashion. Signed-off-by: Paul Cercueil Acked-by: Daniel Vetter Acked-by: Christian König Link: https://lore.kernel.org/r/20240130122340.54813-4-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

USB: uapi: OTG 3.0

2024-01-28T00:41:00+00:00

Add attribute bits defined in version 3.0 Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20240118183644.16125-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: fix fortify warning

2023-12-15T12:55:45+00:00

When compiling with gcc version 14.0.0 20231206 (experimental) and CONFIG_FORTIFY_SOURCE=y, I've noticed the following warning: ... In function 'fortify_memcpy_chk', inlined from '__ffs_func_bind_do_os_desc' at drivers/usb/gadget/function/f_fs.c:2934:3: ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 588 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This call to 'memcpy()' is interpreted as an attempt to copy both 'CompatibleID' and 'SubCompatibleID' of 'struct usb_ext_compat_desc' from an address of the first one, which causes an overread warning. Since we actually want to copy both of them at once, use the convenient 'struct_group()' and 'sizeof_field()' here. Signed-off-by: Dmitry Antipov Link: https://lore.kernel.org/r/20231214090428.27292-1-dmantipov@yandex.ru Signed-off-by: Greg Kroah-Hartman

usb: raw-gadget: report suspend, resume, reset, and disconnect events

2023-10-27T10:58:16+00:00

Update USB_RAW_IOCTL_EVENT_FETCH to also report suspend, resume, reset, and disconnect events. This allows the code that emulates a USB device via Raw Gadget to handle these events. For example, the device can restart enumeration when it gets reset. Also do not print a WARNING when the event queue overflows. With these new events being queued, the queue might overflow if the device emulation code stops fetching events. Also print debug messages when a non-control event is received. Signed-off-by: Andrey Konovalov Link: https://lore.kernel.org/r/d610b629a5f32fb76c24012180743f7f0f1872c0.1698350424.git.andreyknvl@gmail.com Signed-off-by: Greg Kroah-Hartman

USB: Remove remnants of Wireless USB and UWB

2023-08-09T12:17:06+00:00

Wireless USB has long been defunct, and kernel support for it was removed in 2020 by commit caa6772db4c1 ("Staging: remove wusbcore and UWB from the kernel tree."). Nevertheless, some vestiges of the old implementation still clutter up the USB subsystem and one or two other places. Let's get rid of them once and for all. The only parts still left are the user-facing APIs in include/uapi/linux/usb/ch9.h. (There are also a couple of misleading instances, such as the Sierra Wireless USB modem, which is a USB modem made by Sierra Wireless.) Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/b4f2710f-a2de-4fb0-b50f-76776f3a961b@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

Merge tag 'hardening-v6.5-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2023-07-08T19:08:39+00:00

Pull hardening fixes from Kees Cook: - Check for NULL bdev in LoadPin (Matthias Kaehlcke) - Revert unwanted KUnit FORTIFY build default - Fix 1-element array causing boot warnings with xhci-hub * tag 'hardening-v6.5-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: usb: ch9: Replace bmSublinkSpeedAttr 1-element array with flexible array Revert "fortify: Allow KUnit test to build without FORTIFY" dm: verity-loadpin: Add NULL pointer check for 'bdev' parameter

usb: ch9: Replace bmSublinkSpeedAttr 1-element array with flexible array

2023-07-05T21:11:30+00:00

Since commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC"), UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking bmSublinkSpeedAttr will trigger a warning, so make it a proper flexible array. Add a union to keep the struct size identical for userspace in case anything was depending on the old size. False positive warning was: UBSAN: array-index-out-of-bounds in drivers/usb/host/xhci-hub.c:231:31 index 1 is out of range for type '__le32 [1]' for this line of code: ssp_cap->bmSublinkSpeedAttr[offset++] = cpu_to_le32(attr); Reported-by: Borislav Petkov Closes: https://lore.kernel.org/lkml/2023062945-fencing-pebble-0411@gregkh/ Reported-by: Mirsad Todorovac Closes: https://lore.kernel.org/lkml/9a8e34ad-8a8b-3830-4878-3c2c82e69dd9@alu.unizg.hr/ Cc: Greg Kroah-Hartman Cc: "Gustavo A. R. Silva" Tested-by: "Borislav Petkov (AMD)" Tested-by: Mirsad Todorovac Reviewed-by: "Gustavo A. R. Silva" Link: https://lore.kernel.org/r/20230629190900.never.787-kees@kernel.org Signed-off-by: Kees Cook

usb: ch9: Replace 1-element array with flexible array

2023-06-15T09:43:29+00:00

Since commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3"), UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking wData will trigger a warning, so make it a proper flexible array. Add a union to keep the struct size identical for userspace in case anything was depending on the old size. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202306102333.8f5a7443-oliver.sang@intel.com Cc: Greg Kroah-Hartman Cc: kernel test robot Cc: "Gustavo A. R. Silva" Cc: Dan Williams Cc: "Jó Ágila Bitsch" Signed-off-by: Kees Cook Message-ID: <20230614181307.gonna.256-kees@kernel.org> Signed-off-by: Greg Kroah-Hartman