kernel/linux.git/include/linux/usb.h, branch v5.11.6

USB: correct API of usb_control_msg_send/recv

2020-09-25T14:33:58+00:00

They need to specify how memory is to be allocated, as control messages need to work in contexts that require GFP_NOIO. Signed-off-by: Oliver Neukum Link: https://lore.kernel.org/r/20200923134348.23862-9-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman

USB: add usb_control_msg_send() and usb_control_msg_recv()

2020-09-16T09:02:32+00:00

New core functions to make sending/receiving USB control messages easier and saner. In discussions, it turns out that the large majority of users of usb_control_msg() do so in potentially incorrect ways. The most common issue is where a "short" message is received, yet never detected properly due to "incorrect" error handling. Handle all of this in the USB core with two new functions to try to make working with USB control messages simpler. No more need for dynamic data, messages can be on the stack, and only "complete" send/receive will work without causing an error. Link: https://lore.kernel.org/r/20200914153756.3412156-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

USB: move snd_usb_pipe_sanity_check into the USB core

2020-09-16T09:02:23+00:00

snd_usb_pipe_sanity_check() is a great function, so let's move it into the USB core so that other parts of the kernel, including the USB core, can call it. Name it usb_pipe_type_check() to match the existing usb_urb_ep_type_check() call, which now uses this function. Cc: Jaroslav Kysela Cc: "Gustavo A. R. Silva" Cc: Eli Billauer Cc: Emiliano Ingrassia Cc: Alan Stern Cc: Alexander Tsoy Cc: "Geoffrey D. Bennett" Cc: Jussi Laako Cc: Nick Kossifidis Cc: Dmitry Panchenko Cc: Chris Wulff Cc: Jesus Ramos Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20200914153756.3412156-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

usb: linux/usb.h: drop duplicated word in comment

2020-07-15T14:48:11+00:00

Drop the doubled word "the" in a comment. Signed-off-by: Randy Dunlap Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/20200715045701.22949-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman

USB: Fix up terminology in include files

2020-07-02T21:01:11+00:00

USB is a HOST/DEVICE protocol, as per the specification and all documentation. Fix up terms that are not applicable to make things match up with the terms used through the rest of the USB stack. Acked-by: Felipe Balbi Link: https://lore.kernel.org/r/20200701171555.3198836-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

usb: fix kernel-doc warnings and formatting in

2020-07-01T12:04:04+00:00

Fix kernel-doc warnings in : ../include/linux/usb.h:713: warning: Function parameter or member 'use_generic_driver' not described in 'usb_device' ../include/linux/usb.h:1253: warning: Function parameter or member 'match' not described in 'usb_device_driver' ../include/linux/usb.h:1253: warning: Function parameter or member 'id_table' not described in 'usb_device_driver' Also drop an extra blank line and fix indentation. Fixes: 77419aa403ca ("USB: Fallback to generic driver when specific driver fails") Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available") Signed-off-by: Randy Dunlap Cc: Bastien Nocera Link: https://lore.kernel.org/r/7014bab2-268c-69f6-7ef5-57fbd45c8b08@infradead.org Signed-off-by: Greg Kroah-Hartman

USB: Replace zero-length array with flexible-array member

2020-02-23T18:24:51+00:00

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20200220132017.GA29262@embeddedor Signed-off-by: Greg Kroah-Hartman

USB: Fallback to generic driver when specific driver fails

2020-02-12T19:01:55+00:00

If ->probe fails for a device specific driver, ask the driver core to reprobe us, after having flagged the device for the generic driver to be forced. Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-6-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Select better matching USB drivers when available

2020-02-12T19:01:55+00:00

Now that USB device drivers can reuse code from the generic USB device driver, we need to make sure that they get selected rather than the generic driver. Add an id_table and match vfunc to the usb_device_driver struct, which will get used to select a better matching driver at ->probe time. This is a similar mechanism to that used in the HID drivers, with the generic driver being selected unless there's a better matching one found in the registered drivers (see hid_generic_match() in drivers/hid/hid-generic.c). Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-5-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Make it possible to "subclass" usb_device_driver

2020-02-12T19:01:54+00:00

The kernel currenly has only 2 usb_device_drivers, one generic one, one that completely replaces the generic one to make USB devices usable over a network. Use the newly exported generic driver functions when a driver declares to want them run, in addition to its own code. This makes it possible to write drivers that extend the generic USB driver. Note that this patch is not enough for another driver to automatically get selected. Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-3-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman