wireguard-linux/drivers/usb, branch update-toolchain

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

2024-08-15T14:29:46Z

re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated. Reported-by: Karel Balej Closes: https://lore.kernel.org/linux-usb/D3CKQQAETH47.1MUO22RTCH2O3@matfyz.cz/ Cc: stable@vger.kernel.org Fixes: 651aaf36a7d7 ("usb: xhci: Handle USB transaction error on address command") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240815141117.2702314-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: misc: ljca: Add Lunar Lake ljca GPIO HID to ljca_gpio_hids[]

2024-08-13T08:27:07Z

Add LJCA GPIO support for the Lunar Lake platform. New HID taken from out of tree ivsc-driver git repo. Link: https://github.com/intel/ivsc-driver/commit/47e7c4a446c8ea8c741ff5a32fa7b19f9e6fd47e Cc: stable Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20240812095038.555837-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman

Revert "usb: typec: tcpm: clear pd_event queue in PORT_RESET"

2024-08-13T08:26:51Z

This reverts commit bf20c69cf3cf9c6445c4925dd9a8a6ca1b78bfdf. During tcpm_init() stage, if the VBUS is still present after tcpm_reset_port(), then we assume that VBUS will off and goto safe0v after a specific discharge time. Following a TCPM_VBUS_EVENT event if VBUS reach to off state. TCPM_VBUS_EVENT event may be set during PORT_RESET handling stage. If pd_events reset to 0 after TCPM_VBUS_EVENT set, we will lost this VBUS event. Then the port state machine may stuck at one state. Before: [ 2.570172] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev1 NONE_AMS] [ 2.570179] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 2.570182] pending state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED @ 920 ms [rev1 NONE_AMS] [ 3.490213] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [delayed 920 ms] [ 3.490220] Start toggling [ 3.546050] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected] [ 3.546057] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] After revert this patch, we can see VBUS off event and the port will goto expected state. [ 2.441992] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev1 NONE_AMS] [ 2.441999] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 2.442002] pending state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED @ 920 ms [rev1 NONE_AMS] [ 2.442122] VBUS off [ 2.442125] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev1 NONE_AMS] [ 2.442127] VBUS VSAFE0V [ 2.442351] CC1: 0 -> 0, CC2: 0 -> 0 [state SNK_UNATTACHED, polarity 0, disconnected] [ 2.442357] Start toggling [ 2.491850] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected] [ 2.491858] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] [ 2.491863] pending state change SRC_ATTACH_WAIT -> SNK_TRY @ 200 ms [rev1 NONE_AMS] [ 2.691905] state change SRC_ATTACH_WAIT -> SNK_TRY [delayed 200 ms] Fixes: bf20c69cf3cf ("usb: typec: tcpm: clear pd_event queue in PORT_RESET") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240809112901.535072-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Fix the return value of ucsi_run_command()

2024-08-13T08:26:45Z

The command execution routines need to return the amount of data that was transferred when succesful. This fixes an issue where the alternate modes and the power delivery capabilities are not getting registered. Fixes: 5e9c1662a89b ("usb: typec: ucsi: rework command execution functions") Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240809150343.286942-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix duplicate stall handling in handle_tx_event()

2024-08-13T08:26:28Z

Stall handling is managed in the 'process_*' functions, which are called right before the 'goto' stall handling code snippet. Thus, there should be a return after the 'process_*' functions. Otherwise, the stall code may run twice. Fixes: 1b349f214ac7 ("usb: xhci: add 'goto' for halted endpoint check in handle_tx_event()") Reported-by: Michal Pecio Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240809124408.505786-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()

2024-08-13T08:26:27Z

If xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop up the damage. If it fails early enough, before xhci->interrupters is allocated but after xhci->max_interrupters has been set, which happens in most (all?) cases, things get uglier, as xhci_mem_cleanup() unconditionally derefences xhci->interrupters. With prejudice. Gate the interrupt freeing loop with a check on xhci->interrupters being non-NULL. Found while debugging a DMA allocation issue that led the XHCI driver on this exact path. Fixes: c99b38c41234 ("xhci: add support to allocate several interrupters") Cc: Mathias Nyman Cc: Wesley Cheng Cc: Greg Kroah-Hartman Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org # 6.8+ Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240809124408.505786-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Fix a deadlock in ucsi_send_command_common()

2024-08-07T10:48:30Z

The function returns with the ppm_lock held if the PPM is busy or there's an error. Reported-and-tested-by: Luciano Coelho Fixes: 5e9c1662a89b ("usb: typec: ucsi: rework command execution functions") Signed-off-by: Heikki Krogerus Reported-by: Luciano Coelho Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/20240806112029.2984319-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: avoid sink goto SNK_UNATTACHED state if not received source capability message

2024-08-07T10:48:04Z

Since commit (122968f8dda8 usb: typec: tcpm: avoid resets for missing source capability messages), state will change from SNK_WAIT_CAPABILITIES to SNK_WAIT_CAPABILITIES_TIMEOUT. We need to change SNK_WAIT_CAPABILITIES -> SNK_READY path to SNK_WAIT_CAPABILITIES_TIMEOUT -> SNK_READY accordingly. Otherwise, the sink port will never change to SNK_READY state if the source does't have PD capability. [ 503.547183] pending state change SNK_WAIT_CAPABILITIES -> SNK_WAIT_CAPABILITIES_TIMEOUT @ 310 ms [rev3 NONE_AMS] [ 503.857239] state change SNK_WAIT_CAPABILITIES -> SNK_WAIT_CAPABILITIES_TIMEOUT [delayed 310 ms] [ 503.857254] PD TX, header: 0x87 [ 503.862440] PD TX complete, status: 2 [ 503.862484] state change SNK_WAIT_CAPABILITIES_TIMEOUT -> SNK_UNATTACHED [rev3 NONE_AMS] Fixes: 122968f8dda8 ("usb: typec: tcpm: avoid resets for missing source capability messages") Cc: stable@vger.kernel.org Signed-off-by: Xu Yang Reviewed-by: Sebastian Reichel Reviewed-by: Heikki Krogerus Reviewed-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20240802064156.1846768-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: pull out f->disable() from ffs_func_set_alt()

2024-08-07T10:40:59Z

The ``alt`` parameter was used as a way to differentiate between f->disable() and f->set_alt(). As the code paths diverge quite a bit, pull out the f->disable() code from ffs_func_set_alt(), everything will become clearer and less error prone. No change in functionality intended. Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240802140428.2000312-3-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: restore ffs_func_disable() functionality

2024-08-07T10:40:37Z

The blamed commit made ffs_func_disable() always return -EINVAL as the method calls ffs_func_set_alt() with the ``alt`` argument being ``(unsigned)-1``, which is always greater than MAX_ALT_SETTINGS. Use the MAX_ALT_SETTINGS check just in the f->set_alt() code path, f->disable() doesn't care about the ``alt`` parameter. Make a surgical fix, but really the f->disable() code shall be pulled out from ffs_func_set_alt(), the code will become clearer. A patch will follow. Note that ffs_func_disable() always returning -EINVAL made pixel6 crash on USB disconnect. Fixes: 2f550553e23c ("usb: gadget: f_fs: Add the missing get_alt callback") Cc: stable Reported-by: William McVicker Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240802140428.2000312-2-tudor.ambarus@linaro.org Signed-off-by: Greg Kroah-Hartman