kernel.git/drivers/usb/gadget/function, branch linux-5.14.y

usb: gadget: f_uac2: fixed EP-IN wMaxPacketSize

2021-10-13T07:41:49Z

commit 0560c9c552c1815e7b480bc11fd785fefc82bb27 upstream. Async feedback patches broke enumeration on Windows 10 previously fixed by commit 789ea77310f0 ("usb: gadget: f_uac2: always increase endpoint max_packet_size by one audio slot"). While the existing calculation for EP OUT capture for async mode yields size+1 frame due to uac2_opts->fb_max > 0, playback side lost the +1 feature. Therefore the +1 frame addition must be re-introduced for playback. Win10 enumerates the device only when both EP IN and EP OUT max packet sizes are (at least) +1 frame. Fixes: e89bb4288378 ("usb: gadget: u_audio: add real feedback implementation") Cc: stable Tested-by: Henrik Enquist Tested-by: Jack Pham Signed-off-by: Pavel Hofman Link: https://lore.kernel.org/r/20210924080027.5362-1-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_uac2: Populate SS descriptors' wBytesPerInterval

2021-09-30T08:13:08Z

commit f0e8a206a2a53a919e1709c654cb65d519f7befb upstream. For Isochronous endpoints, the SS companion descriptor's wBytesPerInterval field is required to reserve bus time in order to transmit the required payload during the service interval. If left at 0, the UAC2 function is unable to transact data on its playback or capture endpoints in SuperSpeed mode. Since f_uac2 currently does not support any bursting this value can be exactly equal to the calculated wMaxPacketSize. Tested with Windows 10 as a host. Fixes: f8cb3d556be3 ("usb: f_uac2: adds support for SS and SSP") Cc: stable Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210909174811.12534-3-jackp@codeaurora.org [jackp: Backport to 5.14 with minor conflict resolution] Signed-off-by: Jack Pham Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_uac2: Add missing companion descriptor for feedback EP

2021-09-30T08:13:08Z

commit 595091a1426a3b2625dad322f69fe569dc9d8943 upstream. The f_uac2 function fails to enumerate when connected in SuperSpeed due to the feedback endpoint missing the companion descriptor. Add a new ss_epin_fback_desc_comp descriptor and append it behind the ss_epin_fback_desc both in the static definition of the ss_audio_desc structure as well as its dynamic construction in setup_headers(). Fixes: 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add feedback endpoint support") Cc: stable Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210909174811.12534-2-jackp@codeaurora.org [jackp: Backport to 5.14 with minor conflict resolution] Signed-off-by: Jack Pham Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_audio: EP-OUT bInterval in fback frequency

2021-09-30T08:12:53Z

commit f5dfd98a80ff8d50cf4ae2820857d7f5a46cbab9 upstream. The patch increases the bitshift in feedback frequency calculation with EP-OUT bInterval value. Tests have revealed that Win10 and OSX UAC2 drivers require the feedback frequency to be based on the actual packet interval instead of on the USB2 microframe. Otherwise they ignore the feedback value. Linux snd-usb-audio driver detects the applied bitshift automatically. Tested-by: Henrik Enquist Signed-off-by: Pavel Hofman Cc: stable Link: https://lore.kernel.org/r/20210906130822.12256-1-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: fix a potential null pointer dereference

2021-09-18T11:43:39Z

[ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ] f_ncm tx timeout can call us with null skb to flush a pending frame. In this case skb is NULL to begin with but ceases to be null after dev->wrap() completes. In such a case in->maxpacket will be read, even though we've failed to check that 'in' is not NULL. Though I've never observed this fail in practice, however the 'flush operation' simply does not make sense with a null usb IN endpoint - there's nowhere to flush to... (note that we're the gadget/device, and IN is from the point of view of the host, so here IN actually means outbound...) Cc: Brooke Basile Cc: "Bryan O'Donoghue" Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: gadget: u_audio: fix race condition on endpoint stop

2021-08-27T14:07:23Z

If the endpoint completion callback is call right after the ep_enabled flag is cleared and before usb_ep_dequeue() is call, we could do a double free on the request and the associated buffer. Fix this by clearing ep_enabled after all the endpoint requests have been dequeued. Fixes: 7de8681be2cd ("usb: gadget: u_audio: Free requests only after callback") Cc: stable Reported-by: Thinh Nguyen Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210827092927.366482-1-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_uac2: fixup feedback endpoint stop

2021-08-27T14:06:53Z

When the uac2 function is stopped, there seems to be an issue reported on some platforms (Intel Merrifield at least) BUG: kernel NULL pointer dereference, address: 0000000000000008 ... RIP: 0010:dwc3_gadget_del_and_unmap_request+0x19/0xe0 ... Call Trace: dwc3_remove_requests.constprop.0+0x12f/0x170 __dwc3_gadget_ep_disable+0x7a/0x160 dwc3_gadget_ep_disable+0x3d/0xd0 usb_ep_disable+0x1c/0x70 u_audio_stop_capture+0x79/0x120 [u_audio] afunc_set_alt+0x73/0x80 [usb_f_uac2] composite_setup+0x224/0x1b90 [libcomposite] The issue happens only when the gadget is using the sync type "async", not "adaptive". This indicates that problem is coming from the feedback endpoint, which is only used with async synchronization mode. The problem is that request is freed regardless of usb_ep_dequeue(), which ends up badly if the request is not actually dequeued yet. Update the feedback endpoint free function to release the endpoint the same way it is done for the data endpoint, which takes care of the problem. Fixes: 24f779dac8f3 ("usb: gadget: f_uac2/u_audio: add feedback endpoint support") Reported-by: Ferry Toth Tested-by: Ferry Toth Acked-by: Felipe Balbi Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210827075853.266912-1-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_hid: idle uses the highest byte for duration

2021-07-28T06:24:39Z

SET_IDLE value must be shifted 8 bits to the right to get duration. This confirmed by USBCV test. Fixes: afcff6dc690e ("usb: gadget: f_hid: added GET_IDLE and SET_IDLE handlers") Cc: stable Signed-off-by: Maxim Devaev Link: https://lore.kernel.org/r/20210727185800.43796-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_hid: added GET_IDLE and SET_IDLE handlers

2021-07-27T13:55:49Z

The USB HID standard declares mandatory support for GET_IDLE and SET_IDLE requests for Boot Keyboard. Most hosts can handle their absence, but others like some old/strange UEFIs and BIOSes consider this a critical error and refuse to work with f_hid. This primitive implementation of saving and returning idle is sufficient to meet the requirements of the standard and these devices. Acked-by: Felipe Balbi Cc: stable Signed-off-by: Maxim Devaev Link: https://lore.kernel.org/r/20210721180351.129450-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_hid: fixed NULL pointer dereference

2021-07-27T13:54:51Z

Disconnecting and reconnecting the USB cable can lead to crashes and a variety of kernel log spam. The problem was found and reproduced on the Raspberry Pi [1] and the original fix was created in Raspberry's own fork [2]. Link: https://github.com/raspberrypi/linux/issues/3870 [1] Link: https://github.com/raspberrypi/linux/commit/a6e47d5f4efbd2ea6a0b6565cd2f9b7bb217ded5 [2] Signed-off-by: Maxim Devaev Signed-off-by: Phil Elwell Cc: stable Link: https://lore.kernel.org/r/20210723155928.210019-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman