aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2023-01-20ARM: pxa: remove unused board filesArnd Bergmann1-62/+0
The majority of all pxa board files has not been touched in a long time, and no users have spoken up in favor of keeping them around. This leaves only support for the platforms that were already converted to DT, as well as the gumstix and spitz/akita/borzoi machines that work in qemu and can still be converted to DT later. Cc: Ales Bardorfer <[email protected]> Cc: Ales Snuparek <[email protected]> Cc: Alex Osborne <[email protected]> Cc: Alex Osborne <[email protected]> Cc: Dirk Opfer <[email protected]> Cc: Ian Molton <[email protected]> Cc: Lennert Buytenhek <[email protected]> Cc: Marek Vasut <[email protected]> Cc: Michael Petchkovsky <[email protected]> Cc: Nick Bane <[email protected]> Cc: Paul Parsons <[email protected]> Cc: Philipp Zabel <[email protected]> Cc: Richard Purdie <[email protected]> Cc: Sergey Lapin <[email protected]> Cc: Tomas Cech <[email protected]> Acked-by: Dmitry Baryshkov <[email protected]> Acked-by: Robert Jarzmik <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2023-01-19Merge tag 'usb-serial-6.2-rc5' of ↵Greg Kroah-Hartman2-0/+18
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: "USB-serial fixes for 6.2-rc5 Here are some new device ids, mostly for Quectel modems. All have been in linux-next with no reported issues." * tag 'usb-serial-6.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Quectel EM05CN modem USB: serial: option: add Quectel EM05CN (SG) modem USB: serial: cp210x: add SCALANCE LPE-9000 device id USB: serial: option: add Quectel EC200U modem USB: serial: option: add Quectel EM05-G (RS) modem USB: serial: option: add Quectel EM05-G (GR) modem USB: serial: option: add Quectel EM05-G (CS) modem
2023-01-19tty: Call ->dtr_rts() parameter active consistentlyIlpo Järvinen1-2/+2
Convert various parameter names for ->dtr_rts() and related functions from onoff, on, and raise to active. Reviewed-by: Jiri Slaby <[email protected]> Acked-by: Ulf Hansson <[email protected]> # For MMC Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19tty: Convert ->dtr_rts() to take bool argumentIlpo Järvinen2-2/+2
Convert the raise/on parameter in ->dtr_rts() to bool through the callchain. The parameter is used like bool. In USB serial, there remains a few implicit bool -> larger type conversions because some devices use u8 in their control messages. In moxa_tiocmget(), dtr variable was reused for line status which requires int so use a separate variable for status. Reviewed-by: Jiri Slaby <[email protected]> Acked-by: Ulf Hansson <[email protected]> # For MMC Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19tty: Convert ->carrier_raised() and callchains to boolIlpo Järvinen1-2/+2
Return boolean from ->carrier_raised() instead of 0 and 1. Make the return type change also to tty_port_carrier_raised() that makes the ->carrier_raised() call (+ cd variable in moxa into which its return value is stored). Also cleans up a few unnecessary constructs related to this change: return xx ? 1 : 0; -> return xx; if (xx) return 1; return 0; -> return xx; Reviewed-by: Jiri Slaby <[email protected]> Acked-by: Ulf Hansson <[email protected]> # For MMC Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19tty: Cleanup tty_port_set_initialized() bool parameterIlpo Järvinen1-1/+1
Make callers pass true/false consistently for bool val. Reviewed-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: dwc3: fix extcon dependencyArnd Bergmann1-1/+1
The dwc3 core support now links against the extcon subsystem, so it cannot be built-in when extcon is a loadable module: arm-linux-gnueabi-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_extcon': core.c:(.text+0x572): undefined reference to `extcon_get_edev_by_phandle' arm-linux-gnueabi-ld: core.c:(.text+0x596): undefined reference to `extcon_get_extcon_dev' arm-linux-gnueabi-ld: core.c:(.text+0x5ea): undefined reference to `extcon_find_edev_by_node' There was already a Kconfig dependency in the dual-role support, but this is now needed for the entire dwc3 driver. It is still possible to build dwc3 without extcon, but this prevents it from being set to built-in when extcon is a loadable module. Fixes: d182c2e1bc92 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: gadget: add WebUSB landing page supportJó Ágila Bitsch2-10/+258
There is a custom (non-USB IF) extension to the USB standard: https://wicg.github.io/webusb/ This specification is published under the W3C Community Contributor Agreement, which in particular allows to implement the specification without any royalties. The specification allows USB gadgets to announce an URL to landing page and describes a Javascript interface for websites to interact with the USB gadget, if the user allows it. It is currently supported by Chromium-based browsers, such as Chrome, Edge and Opera on all major operating systems including Linux. This patch adds optional support for Linux-based USB gadgets wishing to expose such a landing page. During device enumeration, a host recognizes that the announced USB version is at least 2.01, which means, that there are BOS descriptors available. The device than announces WebUSB support using a platform device capability. This includes a vendor code under which the landing page URL can be retrieved using a vendor-specific request. Previously, the BOS descriptors would unconditionally include an LPM related descriptor, as BOS descriptors were only ever sent when the device was LPM capable. As this is no longer the case, this patch puts this descriptor behind a lpm_capable condition. Usage is modeled after os_desc descriptors: echo 1 > webusb/use echo "https://www.kernel.org" > webusb/landingPage lsusb will report the device with the following lines: Platform Device Capability: bLength 24 bDescriptorType 16 bDevCapabilityType 5 bReserved 0 PlatformCapabilityUUID {3408b638-09a9-47a0-8bfd-a0768815b665} WebUSB: bcdVersion 1.00 bVendorCode 0 iLandingPage 1 https://www.kernel.org Signed-off-by: Jó Ágila Bitsch <[email protected]> Link: https://lore.kernel.org/r/Y8Crf8P2qAWuuk/F@jo-einhundert Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: misc: onboard_usb_hub: add VIA LAB VL817 hub supportAnand Moon2-0/+9
VIA LAB VL817 is a 4-port USB 3.1 hub and USB 2.0 root hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Add USB device id's for USB 2.0 and USB 3.0 root hub. Signed-off-by: Anand Moon <[email protected]> Acked-by: Matthias Kaehlcke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: misc: onboard_usb_hub: add Genesys Logic GL852G hub supportAnand Moon2-0/+6
Genesys Logic GL852G is a 4-port USB 2.0 STT hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Signed-off-by: Anand Moon <[email protected]> Acked-by: Matthias Kaehlcke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: mtu3: fix the failure of qmu stopChunfeng Yun3-2/+9
This happens when do stress test of uvc stream on/off which will enable/disable endpoints. uvc has four tx requests, and may disable endpoint between queue tx requests as following: enable ep --> start qmu queue tx request0 queue tx request1 queue tx request2 --> resume qmu disable ep --> stop qmu may fail [1] queue tx request3 --> will resume qmu, may cause qmu can't work when enable ep next time [2] [1]: when the tx fifo has some data to transmit, and try to stop qmu (stop ep) meanwhile resume qmu (queue tx request), it may cause stop qmu timeout, then can be fixed by flushing fifo when stop qmu. [2]: it resumes qmu again, shall stop qmu again. Signed-off-by: Chunfeng Yun <[email protected]> Reported-by: Min Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: fotg210-udc: Implement VBUS sessionLinus Walleij3-0/+48
Implement VBUS session handling for FOTG210. This is mainly used by the UDC driver which needs to call down to the FOTG210 core and enable/disable VBUS, as this needs to be handled outside of the HCD and UDC drivers, by platform specific glue code. The Gemini has a special bit in a system register to turn VBUS on and off so we implement this in the FOTG210 core. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: fotg210-udc: Assign of_node and speed on startLinus Walleij1-0/+5
Follow the example set by other drivers to assign of_node and speed to the driver when binding, also print bound info akin to other UDC drivers. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: fotg210: Check role register in coreLinus Walleij1-2/+14
Read the role register and check that we are in host/peripheral mode and issue warnings if we're not in the right role when probing respective driver. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: fotg210: Move clock handling to coreLinus Walleij5-59/+11
Grab the optional silicon block clock, prepare and enable it in the core before proceeding to prepare the host or peripheral driver. This saves duplicate code and also uses the simple devm_clk_get_optional_enabled() to do everything we really want to do. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: fotg210: Acquire memory resource in coreLinus Walleij6-34/+52
The subdrivers are obtaining and mapping the memory resource separately. Create a common state container for the shared resources and start populating this by acquiring the IO memory resource and remap it and pass this to the subdrivers for host and peripheral. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-19usb: fotg210: List different variantsLinus Walleij1-0/+2
There are at least two variants of the FOTG: FOTG200 and FOTG210. Handle them in this driver and let's add more quirks as we go along. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: core: hub: disable autosuspend for TI TUSB8041Flavio Suligoi1-0/+13
The Texas Instruments TUSB8041 has an autosuspend problem at high temperature. If there is not USB traffic, after a couple of ms, the device enters in autosuspend mode. In this condition the external clock stops working, to save energy. When the USB activity turns on, ther hub exits the autosuspend state, the clock starts running again and all works fine. At ambient temperature all works correctly, but at high temperature, when the USB activity turns on, the external clock doesn't restart and the hub disappears from the USB bus. Disabling the autosuspend mode for this hub solves the issue. Signed-off-by: Flavio Suligoi <[email protected]> Cc: stable <[email protected]> Acked-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: cdnsp: : add scatter gather support for ISOC endpointPawel Laszczak3-53/+63
Patch implements scatter gather support for isochronous endpoint. This fix is forced by 'commit e81e7f9a0eb9 ("usb: gadget: uvc: add scatter gather support")'. After this fix CDNSP driver stop working with UVC class. Signed-off-by: Pawel Laszczak <[email protected]> Reviewed-by: Peter Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: maxim_contaminant: Implement check_contaminant callbackBadhri Jagan Sridharan4-32/+498
Maxim TCPC has additional ADCs and low current(1ua) current source to measure the impedance of CC and SBU pins. When tcpm invokes the check_contaminant callback, Maxim TCPC measures the impedance of the CC & SBU pins and when the impedance measured is less than 1MOhm, it is assumed that USB-C port is contaminated. CC comparators are also checked to differentiate between presence of sink and contaminant. Once USB-C is deemed to be contaminated, MAXIM TCPC has additional hardware to disable normal DRP toggling cycle and enable 1ua on CC pins once every 2.4secs/4.8secs. Maxim TCPC interrupts AP once the impedance on the CC pin is above the 1MOhm threshold. The Maxim tcpc driver then signals TCPM_PORT_CLEAN to restart toggling. Renaming tcpci_maxim.c to tcpci_maxim_core.c and moving reg read/write helper functions to the tcpci_maxim.h header file. Signed-off-by: Badhri Jagan Sridharan <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: tcpci: Add callback for evaluating contaminant presenceBadhri Jagan Sridharan1-0/+11
This change adds callback to evaluate presence of contaminant in the TCPCI layer. Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: tcpm: Add callbacks to mitigate wakeups due to contaminantBadhri Jagan Sridharan1-1/+54
On some of the TCPC implementations, when the Type-C port is exposed to contaminants, such as water, TCPC stops toggling while reporting OPEN either by the time TCPM reads CC pin status or during CC debounce window. This causes TCPM to be stuck in TOGGLING state. If TCPM is made to restart toggling, the behavior recurs causing redundant CPU wakeups till the USB-C port is free of contaminant. [206199.287817] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [206199.640337] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [206199.985789] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] (or) [ 7853.867577] Start toggling [ 7853.889921] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 7855.698765] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 7855.698790] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [ 7855.698826] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [ 7855.703559] CC1: 0 -> 0, CC2: 5 -> 5 [state SNK_ATTACH_WAIT, polarity 0, connected] [ 7855.856555] CC1: 0 -> 0, CC2: 5 -> 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected] [ 7855.856581] state change SNK_ATTACH_WAIT -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [ 7855.856613] pending state change SNK_ATTACH_WAIT -> SNK_UNATTACHED @ 170 ms [rev3 NONE_AMS] [ 7856.027744] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [delayed 170 ms] [ 7856.181949] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 7856.187896] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 7857.645630] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 7857.647291] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 7857.647298] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [ 7857.647310] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [ 7857.808106] CC1: 0 -> 0, CC2: 5 -> 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected] [ 7857.808123] state change SNK_ATTACH_WAIT -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [ 7857.808150] pending state change SNK_ATTACH_WAIT -> SNK_UNATTACHED @ 170 ms [rev3 NONE_AMS] [ 7857.978727] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [delayed 170 ms] To mitigate redundant TCPM wakeups, TCPCs which do have the needed hardware can implement the check_contaminant callback which is invoked by TCPM to evaluate for presence of contaminant. Lower level TCPC driver can restart toggling through TCPM_PORT_CLEAN event when the driver detects that USB-C port is free of contaminant. check_contaminant callback also passes the disconnect_while_debounce flag which when true denotes that the CC pins transitioned to OPEN state during the CC debounce window. Signed-off-by: Badhri Jagan Sridharan <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: Make bus switch code retimer-awarePrashant Malani2-1/+23
Since ports can have retimers associated with them, update the Type-C alternate mode bus code to also set retimer state when the switch state is updated. While we are here, make the typec_retimer_dev_type declaration in the retimer.h file as extern, so that the header file can be successfully included in the bus code without redeclaration compilation errors. Signed-off-by: Prashant Malani <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: Add wrapper for bus switch set codePrashant Malani1-2/+9
Add a wrapper that calls the set() function for various switches associated with a port altmode. Right now, it just wraps the existing typec_mux_set() command, but it can be expanded to include other switches in future patches. No functional changes introduced by this patch. Signed-off-by: Prashant Malani <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: Add retimer handle to port altmodePrashant Malani2-2/+15
Just like it does with muxes, the Type-C bus code can update the state of connected retimers (especially when altmode-related transitions occur). Add a retimer handle to the port altmode struct to enable this. Signed-off-by: Prashant Malani <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17xhci: tegra: USB2 pad power controlsPetlozu Pravareshwar1-0/+125
Program USB2 pad PD controls during port connect/disconnect, port suspend/resume, and test mode, to reduce power consumption on disconnect or suspend. Signed-off-by: Petlozu Pravareshwar <[email protected]> Co-developed-by: Jim Lin <[email protected]> Signed-off-by: Jim Lin <[email protected]> Acked-by: Thierry Reding <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Acked-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17xhci: hub: export symbol on xhci_hub_controlJim Lin1-0/+1
XHCI host drivers may override the default xhci_hub_control() with their own device specific function. To allow these host drivers to call the xhci_hub_control() function from within their own hub_control() callback and be built as a module, export the symbol for xhci_hub_control. Signed-off-by: Jim Lin <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17xhci: Add hub_control to xhci_driver_overridesJim Lin2-0/+4
Add a hub_control() callback to the xhci_driver_overrides structure to allow host drivers to override the default hub_control function. This is required for Tegra which requires device specific actions for power management to be executed during USB state transitions. Signed-off-by: Jim Lin <[email protected]> Reviewed-by: Jon Hunter <[email protected]> Tested-by: Jon Hunter <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: host: xhci-tegra: Add Tegra234 XHCI supportSing-Han Chen1-39/+228
This change adds Tegra234 XUSB host mode controller support. In Tegra234, some of the registers have moved to bar2 space. The new soc variable has_bar2 indicates the chip with bar2 area. This patch adds new reg helper to let the driver reuse the same code for those chips with bar2 support. Signed-off-by: Sing-Han Chen <[email protected]> Co-developed-by: Wayne Chang <[email protected]> Signed-off-by: Wayne Chang <[email protected]> Signed-off-by: Jon Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: usb: Remove "default" from color matching attributesDaniel Scally1-15/+14
Color matching attributes in the configfs for UVC are named with the phrase "default". The implication of that is that they will only be used _with_ the default color matching descriptor, and that will shortly no longer be the case. Remove the "default" from the color matching descriptor attribute variables. Signed-off-by: Daniel Scally <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: tipd: Support wakeupJun Nie1-0/+38
Enable wakeup when pluging or unpluging USB cable. It is up to other components to hold system in active mode, such as display, so that user can receive the notification. Signed-off-by: Jun Nie <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17USB: fix memory leak with using debugfs_lookup()Greg Kroah-Hartman1-1/+1
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. Cc: Alan Stern <[email protected]> Cc: Jilin Yuan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: udc: add Renesas RZ/N1 USBF controller supportHerve Codina3-0/+3418
Add support for the Renesas USBF controller. This controller is an USB2.0 UDC controller available in the Renesas r9a06g032 SoC (RZ/N1 family). Signed-off-by: Herve Codina <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: intel_pmc_mux: Deduplicate ACPI matching in probeAndy Shevchenko1-5/+4
There is no need to call acpi_dev_present() followed by acpi_dev_get_first_match_dev() as they both do the same with only difference in the returning value. Instead, call the latter and check its result. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: intel_pmc_mux: Don't leak the ACPI device reference countAndy Shevchenko1-1/+3
When acpi_dev_get_memory_resources() fails, the reference count is left bumped. Drop it as it's done in the other error paths. Fixes: 43d596e32276 ("usb: typec: intel_pmc_mux: Check the port status before connect") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: tcpci: Request IRQ with IRQF_SHAREDXu Yang1-2/+6
Under resource constraints, this interrupt may use other interrupt line or this interrupt line may be shared with other devices as long as they meet the sharing requirements. Besides, This irq flag will not cause other side effect if tcpci driver is the only user. Signed-off-by: Xu Yang <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: xudc: Refactor update data role workWayne Chang1-9/+24
The notification call chain should be registered after the device gets ready. Otherwise, we might get errors when setting data roles in an incomplete system. This patch refactors update data role work and register the notifier call chain after the system gets ready. Signed-off-by: Wayne Chang <[email protected]> Signed-off-by: Haotien Hsu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: hd3ss3220: Add polling supportBiju Das1-0/+29
Some platforms(for eg: RZ/V2M EVK) does not have interrupt pin connected to HD3SS3220. Add polling support for role detection. Signed-off-by: Biju Das <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()Maciej Żenczykowski1-1/+3
In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing... Cc: Felipe Balbi <[email protected]> Cc: Lorenzo Colitti <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: [email protected] Signed-off-by: Maciej Żenczykowski <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17USB: gadget: Add ID numbers to configfs-gadget driver namesChanh Nguyen1-2/+10
It is unable to use configfs to attach more than one gadget. When attaching the second gadget, it always fails and the kernel message prints out: Error: Driver 'configfs-gadget' is already registered, aborting... UDC core: g1: driver registration failed: -16 This commit fixes the problem by using the gadget name as a suffix to each configfs_gadget's driver name, thus making the names distinct. Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") Cc: stable <[email protected]> Signed-off-by: Chanh Nguyen <[email protected]> Reviewed-by: Andrzej Pietrasiewicz <[email protected]> Tested-by: Heikki Krogerus <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: tcpm: Fix altmode re-registration causes sysfs create failChiYuan Huang1-4/+3
There's the altmode re-registeration issue after data role swap (DR_SWAP). Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP can initiate the VDM command to get partner identity information. For a USBPD 3.0 UFP device, it may already get the identity information from its port partner before DR_SWAP. If DR_SWAP send or receive at the mean time, 'send_discover' flag will be raised again. It causes discover identify action restart while entering ready state. And after all discover actions are done, the 'tcpm_register_altmodes' will be called. If old altmode is not unregistered, this sysfs create fail can be found. In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes. For UFP, the original altmodes keep registered. This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes' must be called whatever the current data role is. Reviewed-by: Macpaul Lin <[email protected]> Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together") Reported-by: TommyYl Chen <[email protected]> Cc: [email protected] Signed-off-by: ChiYuan Huang <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: g_webcam: Send color matching descriptor per frameDaniel Scally1-0/+3
Currently the color matching descriptor is only sent across the wire a single time, following the descriptors for each format and frame. According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching Descriptors"): "Only one instance is allowed for a given format and if present, the Color Matching descriptor shall be placed following the Video and Still Image Frame descriptors for that format". Add another reference to the color matching descriptor after the yuyv frames so that it's correctly transmitted for that format too. Fixes: a9914127e834 ("USB gadget: Webcam device") Cc: stable <[email protected]> Signed-off-by: Daniel Scally <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: altmodes/displayport: Use proper macro for pin assignment checkPrashant Malani1-1/+1
While looking at the DP configuration VDO to determine the peripheral configuration, the spec (Table 8-5: DisplayPort Configurations, VESA DisplayPort Alt Mode Standard v2.0) lists the options as "UFP_U as a DP Source/Sink Device". So, use the correct macro while performing this check. Effectively it's the same as the existing code, but the proposed macro describes the state a little better. No functional changes introduced. Cc: Heikki Krogerus <[email protected]> Signed-off-by: Prashant Malani <[email protected]> Reviewed-by: Benson Leung <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: altmodes/displayport: Fix pin assignment calculationPrashant Malani1-2/+2
Commit c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") fixed the pin assignment calculation to take into account whether the peripheral was a plug or a receptacle. But the "pin_assignments" sysfs logic was not updated. Address this by using the macros introduced in the aforementioned commit in the sysfs logic too. Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") Cc: [email protected] Cc: Heikki Krogerus <[email protected]> Signed-off-by: Prashant Malani <[email protected]> Reviewed-by: Benson Leung <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: typec: altmodes/displayport: Add pin assignment helperPrashant Malani1-8/+14
The code to extract a peripheral's currently supported Pin Assignments is repeated in a couple of locations. Factor it out into a separate function. This will also make it easier to add fixes (we only need to update 1 location instead of 2). Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") Cc: [email protected] Cc: Heikki Krogerus <[email protected]> Signed-off-by: Prashant Malani <[email protected]> Reviewed-by: Benson Leung <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: f_fs: Ensure ep0req is dequeued before free_requestUdipto Goswami1-0/+2
As per the documentation, function usb_ep_free_request guarantees the request will not be queued or no longer be re-queued (or otherwise used). However, with the current implementation it doesn't make sure that the request in ep0 isn't reused. Fix this by dequeuing the ep0req on functionfs_unbind before freeing the request to align with the definition. Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver") Signed-off-by: Udipto Goswami <[email protected]> Tested-by: Krishna Kurapati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: gadget: f_fs: Prevent race during ffs_ep0_queue_waitUdipto Goswami1-0/+5
While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind. Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free. Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex). Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver") Signed-off-by: Udipto Goswami <[email protected]> Tested-by: Krishna Kurapati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: misc: onboard_hub: Move 'attach' work to the driverMatthias Kaehlcke1-6/+6
Currently each onboard_hub platform device owns an 'attach' work, which is scheduled when the device probes. With this deadlocks have been reported on a Raspberry Pi 3 B+ [1], which has nested onboard hubs. The flow of the deadlock is something like this (with the onboard_hub driver built as a module) [2]: - USB root hub is instantiated - core hub driver calls onboard_hub_create_pdevs(), which creates the 'raw' platform device for the 1st level hub - 1st level hub is probed by the core hub driver - core hub driver calls onboard_hub_create_pdevs(), which creates the 'raw' platform device for the 2nd level hub - onboard_hub platform driver is registered - platform device for 1st level hub is probed - schedules 'attach' work - platform device for 2nd level hub is probed - schedules 'attach' work - onboard_hub USB driver is registered - device (and parent) lock of hub is held while the device is re-probed with the onboard_hub driver - 'attach' work (running in another thread) calls driver_attach(), which blocks on one of the hub device locks - onboard_hub_destroy_pdevs() is called by the core hub driver when one of the hubs is detached - destroying the pdevs invokes onboard_hub_remove(), which waits for the 'attach' work to complete - waits forever, since the 'attach' work can't acquire the device lock Use a single work struct for the driver instead of having a work struct per onboard hub platform driver instance. With that it isn't necessary to cancel the work in onboard_hub_remove(), which fixes the deadlock. The work is only cancelled when the driver is unloaded. [1] https://lore.kernel.org/r/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") Link: https://lore.kernel.org/r/[email protected]/ Link: https://lore.kernel.org/all/[email protected]/ Reported-by: Stefan Wahren <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Link: https://lore.kernel.org/r/20230110172954.v2.2.I16b51f32db0c32f8a8532900bfe1c70c8572881a@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: misc: onboard_hub: Invert driver registration orderMatthias Kaehlcke1-3/+3
The onboard_hub 'driver' consists of two drivers, a platform driver and a USB driver. Currently when the onboard hub driver is initialized it first registers the platform driver, then the USB driver. This results in a race condition when the 'attach' work is executed, which is scheduled when the platform device is probed. The purpose of fhe 'attach' work is to bind elegible USB hub devices to the onboard_hub USB driver. This fails if the work runs before the USB driver has been registered. Register the USB driver first, then the platform driver. This increases the chances that the onboard_hub USB devices are probed before their corresponding platform device, which the USB driver tries to locate in _probe(). The driver already handles this situation and defers probing if the onboard hub platform device doesn't exist yet. Cc: [email protected] Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") Link: https://lore.kernel.org/lkml/[email protected]/T/#m0d64295f017942fd988f7c53425db302d61952b4 Reported-by: Alexander Stein <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Tested-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/20230110172954.v2.1.I75494ebee7027a50235ce4b1e930fa73a578fbe2@changeid Signed-off-by: Greg Kroah-Hartman <[email protected]>
2023-01-17usb: ucsi: Ensure connector delayed work items are flushedJack Pham2-3/+22
During ucsi_unregister() when destroying a connector's workqueue, there may still be pending delayed work items that haven't been scheduled yet. Because queue_delayed_work() uses a separate timer to schedule a work item, the destroy_workqueue() call is not aware of any pending items. Hence when a pending item's timer expires it would then try to queue on a dangling workqueue pointer. Fix this by keeping track of all work items in a list, so that prior to destroying the workqueue any pending items can be flushed. Do this by calling mod_delayed_work() as that will cause pending items to get queued immediately, which then allows the ensuing destroy_workqueue() to implicitly drain all currently queued items to completion and free themselves. Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Suggested-by: Heikki Krogerus <[email protected]> Co-developed-by: Linyu Yuan <[email protected]> Signed-off-by: Linyu Yuan <[email protected]> Signed-off-by: Jack Pham <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.