- 05 Mar, 2024 23 commits
-
-
Stephen Boyd authored
When a USB hub is described in DT, such as any device that matches the onboard-hub driver, the connect_type is set to "unknown" or USB_PORT_CONNECT_TYPE_UNKNOWN. This makes any device plugged into that USB port report their 'removable' device attribute as "unknown". ChromeOS userspace would like to know if the USB device is actually removable or not so that security policies can be applied. Improve the connect_type attribute for ports, and in turn the removable attribute for USB devices, by looking for child devices with a reg property or an OF graph when the device is described in DT. If the graph exists, endpoints that are connected to a remote node must be something like a usb-{a,b,c}-connector compatible node, or an intermediate node like a redriver, and not a hardwired USB device on the board. Set the connect_type to USB_PORT_CONNECT_TYPE_HOT_PLUG in this case because the device is going to be plugged in. Set the connect_type to USB_PORT_CONNECT_TYPE_HARD_WIRED if there's a child node for the port like 'device@2' for port2. Set the connect_type to USB_PORT_NOT_USED if there isn't an endpoint or child node corresponding to the port number. To make sure things don't change, only set the port to not used if there are child nodes. This way an onboard hub connect_type doesn't change until ports are added or child nodes are added to describe hardwired devices. It's assumed that all ports or no ports will be described for a device. Cc: Matthias Kaehlcke <mka@chromium.org> Cc: linux-usb@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: Pin-yen Lin <treapking@chromium.org> Cc: maciek swiech <drmasquatch@google.com> Signed-off-by:Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20240223005823.3074029-3-swboyd@chromium.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
Add a graph with 4 output endpoints to this hub binding to support the scenario where a downstream facing port is connected to a device that isn't a connector or a USB device with a VID:PID. This will be used to connect downstream facing ports to USB type-c switches so the USB superspeed and high speed lanes can be put onto USB connectors. Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Conor Dooley <conor+dt@kernel.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: linux-usb@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: Pin-yen Lin <treapking@chromium.org> Cc: maciek swiech <drmasquatch@google.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240223005823.3074029-2-swboyd@chromium.orgSigned-off-by:
-
Macpaul Lin authored
The TI TUSB8020B is a 2-port USB 3.0 hub. Add support for this hub in the driver in order to bring up reset, and supply dependencies. Power-up: Issue a GPIO reset (GRSTz) 3ms after VDD and VDD33 stabilize. Signed-off-by:
Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240227090228.22156-2-macpaul.lin@mediatek.comSigned-off-by:
-
Macpaul Lin authored
The TI USB8020B is a USB 3.0 hub controller with 2 ports. This initial version of the binding only describes USB related aspects of the USB8020B, it does not cover the option of connecting the controller as an i2c slave. Signed-off-by:
-
Colin Ian King authored
The variable count is being initialized and incremented but it is never actually referenced in any other way. The variable is redundant and can be removed. Cleans up clang scan build warning: drivers/usb/musb/musb_gadget.c:1747:12: warning: variable 'count' set but not used [-Wunused-but-set-variable] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20240229115548.218713-1-colin.i.king@gmail.comSigned-off-by:
-
Krzysztof Kozlowski authored
The binding references usb-connector.yaml schema, which lists all allowed properties and ends with unevaluatedProperties:false, so we can simplify analogix,anx7411 binding by dropping everything covered by usb-connector.yaml. Suggested-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Wesley Cheng authored
Add revision value for identifying DWC31 version 2.00a based controllers. Signed-off-by:
Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20240301213554.7850-1-quic_wcheng@quicinc.comSigned-off-by:
-
Roger Quadros authored
All AM62 devices have Errata i2409 [1] due to which USB2 PHY may lock up due to short suspend. Workaround involves setting bit 5 and 4 PLL_REG12 in PHY2 register space after USB controller is brought out of LPSC reset but before controller initialization. Handle this workaround. [1] - https://www.ti.com/lit/er/sprz487d/sprz487d.pdfSigned-off-by:
Roger Quadros <rogerq@kernel.org> Acked-by:
Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240227-for-v6-9-am62-usb-errata-3-0-v4-4-0ada8ddb0767@kernel.orgSigned-off-by:
-
Roger Quadros authored
TRM information is outdated and design team has confirmed that PHY_CORE_VOLTAGE should be 0 irrespective of VDD_CORE voltage. Signed-off-by:
-
Roger Quadros authored
Disable wakeup at remove. Fixes the below warnings on module unload and reload. > dwc3-am62 f900000.dwc3-usb: couldn't enable device as a wakeup source: -17 > dwc3-am62 f910000.dwc3-usb: couldn't enable device as a wakeup source: -17 Fixes: 4e3972b5 ("usb: dwc3-am62: Enable as a wakeup source by default") Cc: stable@vger.kernel.org # v6.4+ Signed-off-by:
-
Roger Quadros authored
As runtime PM is enabled, the module can be runtime suspended when .remove() is called. Do a pm_runtime_get_sync() to make sure module is active before doing any register operations. Doing a pm_runtime_put_sync() should disable the refclk so no need to disable it again. Fixes the below warning at module removel. [ 39.705310] ------------[ cut here ]------------ [ 39.710004] clk:162:3 already disabled [ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 We called of_platform_populate() in .probe() so call the cleanup function of_platform_depopulate() in .remove(). Get rid of the now unnnecessary dwc3_ti_remove_core(). Without this, module re-load doesn't work properly. Fixes: e8784c0a ("drivers: usb: dwc3: Add AM62 USB wrapper driver") Cc: stable@vger.kernel.org # v5.19+ Signed-off-by:
-
Yang Xiwen authored
Hi3798MV200 uses dwc3 controller with a few more clocks and a dedicated resets. Use of_simple driver for it. Signed-off-by:
Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240225-dwc3-v4-2-8c1fd6c6f615@outlook.comSigned-off-by:
-
Yang Xiwen authored
Document the DWC3 controller used by Hi3798MV200. Reviewed-by:
-
Jameson Thies authored
Register SOP' alternate modes with a Type-C Connector Class cable plug. Alternate modes are queried from the PPM using the GET_ALTERNATE_MODES command with recipient set to SOP'. Reviewed-by:
Benson Leung <bleung@chromium.org> Reviewed-by:
Prashant Malani <pmalani@chromium.org> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Jameson Thies <jthies@google.com> Link: https://lore.kernel.org/r/20240305025804.1290919-5-jthies@google.comSigned-off-by:
-
Jameson Thies authored
Register SOP and SOP' Discover Identity responses with the USB Type-C Connector Class as partner and cable identities, respectively. Discover Identity responses are requested from the PPM using the GET_PD_MESSAGE UCSI command. Signed-off-by:
-
Jameson Thies authored
Register cables with the Type-C Connector Class in the UCSI driver based on the PPM response to GET_CABLE_PROPERTY. Registered cable properties include plug type, cable type and major revision. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
-
Jameson Thies authored
Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and updating the modal support macro for consistent naming. Fixes: 3cf657f0 ("usb: typec: ucsi: Remove all bit-fields") Cc: stable@vger.kernel.org Reviewed-by:
-
Oliver Neukum authored
If we have a neat macro, at least new code should use it. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20240229131851.16148-2-oneukum@suse.comSigned-off-by:
-
RD Babiera authored
When the port is setting the pin configuration when no configuration is chosen, the DisplayPort driver will not send Configure to the cable plug if it's available. Add transition to DP_STATE_CONFIGURE_PRIME. Fixes: 71ba4fe5 ("usb: typec: altmodes/displayport: add SOP' support") Signed-off-by:
RD Babiera <rdbabiera@google.com> Acked-by:
-
RD Babiera authored
The Smatch checker flags svdm_version being uninitialized for Discover Identity Messages within tcpm_pd_svdm for the CMDT_INIT case. Cable plugs cannot initialize SVDM commands, however a port partner that isn't allowed to communicate over SOP' could, which would result in the CMDT_INIT block running for a received SOP' message. First, initialize svdm_version for the TCPC_TX_SOP_PRIME case. If the svdm_version returns as an error, we expect the received svdm to be the result of Discover Identity that updates the value accordingly. Next, drop all SOP' messages of type CMDT_INIT within tcpm_pd_svdm. Finally, remove redundant call that assigns modep and pdev. Smatch will raise an uninitialized symbol error over modep_prime and pdev_prime, but both the assignment and use of these variables are guarded behind a check for rx_sop_type == TCPC_TX_SOP_PRIME. Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/a432603b-b801-4001-b309-247dded707d3@moroto.mountain/ Fixes: fb7ff25a ("usb: typec: tcpm: add discover identity support for SOP'") Signed-off-by:
-
Mathias Nyman authored
Ports with _UPC (USB Port Capability) ACPI objects stating they are "not connectable" are not wired to any connector or internal device. They only exist inside the host controller. These ports may not have an ACPI _PLD (Physical Location of Device) object. Rework the code so that _UPC is read even if _PLD does not exist, and make sure the port->connect_type is set to "USB_PORT_NOT_USED" instead of "USB_PORT_CONNECT_TYPE_UNKNOWN". No bugs or known issues are reported due to possibly not parsing _UPC, and thus leaving the port connect type as "unknown" instead of "not used". Nice to have this fixed but no need to add it to stable kernels, or urgency to get it upstream. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240223140305.185182-1-mathias.nyman@linux.intel.comSigned-off-by:
-
Krishna Kurapati authored
Minimal ACPI support was added to the Qualcomm DWC3 glue driver in order to enable USB on SDM850 and SC8180X compute platforms. The support is still functional, but unnoticed regressions in other drivers indicates that no one actually booting any of platforms dependent on this implementation. The functionality provides is the bare minimum and is not expected to aid in the effort of bringing full ACPI support to the driver in the future. Remove the ACPI code from the Qualcomm DWC3 glue driver to aid in the implementation of improvements that are actually used like multiport and flattening device tree. Commit message by Bjorn Andersson. Signed-off-by:
Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240305093216.3814787-1-quic_kriskura@quicinc.comSigned-off-by:
-
Elbert Mai authored
Motivation ---------- The binary device object store (BOS) of a USB device consists of the BOS descriptor followed by a set of device capability descriptors. One that is of interest to users is the platform descriptor. This contains a 128-bit UUID and arbitrary data, and it allows parties outside of USB-IF to add additional metadata about a USB device in a standards-compliant manner. Notable examples include the WebUSB and Microsoft OS 2.0 descriptors. The kernel already retrieves and caches the BOS from USB devices if its bcdUSB is >= 0x0201. Because the BOS is flexible and extensible, we export the entire BOS to sysfs so users can retrieve whatever device capabilities they desire, without requiring USB I/O or elevated permissions. Implementation -------------- Add bos_descriptors attribute to sysfs. This is a binary file and it works the same way as the existing descriptors attribute. The file exists only if the BOS is present in the USB device. Also create a binary attribute group, so the driver core can handle the creation of both the descriptors and bos_descriptors attributes in sysfs. Signed-off-by:
Elbert Mai <code@elbertmai.com> Link: https://lore.kernel.org/r/20240305002301.95323-1-code@elbertmai.comSigned-off-by:
-
- 04 Mar, 2024 1 commit
-
-
Dmitry Baryshkov authored
The PM4125 PMIC has the same Type-C register block as the PMI632. Likewise it doesn't support USB Power Delivery. Define the compatible for the TypeC block found on PM4125, using PMI632 as a compatible. Reviewed-by:
-
- 02 Mar, 2024 16 commits
-
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20240222174456.25903-2-Sergey.Semin@baikalelectronics.ruSigned-off-by:
-
Gabor Juhos authored
The correct interrupt name is 'hs_phy_irq' not 'hs_phY_irq'. Signed-off-by:
Gabor Juhos <j4g8y7@gmail.com> Acked-by:
-
Danila Tikhonov authored
Define VBUS regulator and the Type-C handling block as present on the Qualcomm PM6150 PMIC. Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Reviewed-by:
-
Danila Tikhonov authored
The PM6150 PMIC has the same Type-C register block as the PM8150B. Define corresponding compatible string, having the qcom,pm8150b-vbus-reg as a fallback. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by:
-
Michal Pecio authored
A call to usb_set_interface() crashes if the device is deallocated concurrently, such as due to physical removal or a serious IO error. It could also interfere with other drivers using the device if the current driver is unbound before the call is finished. Document the need to delay driver unbinding until this call returns, which solves both issues. Document the same regarding usb_clear_halt(), which is equally known to be routinely called by drivers. Explicitly mention finishing pending operations in the documentation of the driver disconnect callback. Signed-off-by:
Michal Pecio <michal.pecio@gmail.com> Link: https://lore.kernel.org/r/20240218092515.7635ff8c@foxbookSigned-off-by:
-
Prashanth K authored
Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer. Cc: stable@vger.kernel.org # 5.11 Fixes: 2017a1e5 ("usb: xhci: Use temporary buffer to consolidate SG") Signed-off-by:
Prashanth K <quic_prashk@quicinc.com> Signed-off-by:
-
Mathias Nyman authored
DbC driver starts polling for events immediately when DbC is enabled. The current polling interval is 1ms, which keeps the CPU busy, impacting power management even when there are no active data transfers. Solve this by polling at a slower rate, with a 64ms interval as default until a transfer request is queued, or if there are still are pending unhandled transfers at event completion. Tested-by:
Uday M Bhat <uday.m.bhat@intel.com> Signed-off-by:
-
Michal Pecio authored
Two NEC uPD720200 adapters have been observed to randomly misbehave: a Stop Endpoint command fails with Context Error, the Output Context indicates Stopped state, and the endpoint keeps running. Very often, Set TR Dequeue Pointer is seen to fail next with Context Error too, in addition to problems from unexpectedly completed cancelled work. The pathology is common on fast running isoc endpoints like uvcvideo, but has also been reproduced on a full-speed bulk endpoint of pl2303. It seems all EPs are affected, with risk proportional to their load. Reproduction involves receiving any kind of stream and closing it to make the device driver cancel URBs already queued in advance. Deal with it by retrying the command like in the Running state. Signed-off-by:
-
Michal Pecio authored
A trb_in_td() call is used to determine if a completion event matches any TRB of the currently executing TD. This function is told to start searching right after the last finished TD, which is not at all where the currently expected TD is guaranteed to begin, because some TDs in between may have been cancelled. Not only is a pointless work performed, but a bug resulting in the HC executing cancelled TDs was seen to trick the driver into associating events from a TD just cancelled with an unrelated future TD. Since the ring is being traversed for the specific purpose of finding a match with the current TD, always start from its first TRB. This is the most reliable bit of information that we posses. Tracking of HC's work progress is not affected, except for cases when a misattributed event would have moved dequeue past a pending TD. Signed-off-by:
-
Niklas Neronin authored
Refactor the code to improve readability by using 'xhci_free_segments_for_ring()' function for freeing ring segments. This replaces the custom while loop previously used within 'xhci_ring_expansion()' and 'xhci_alloc_segments_for_ring()'. Slightly modify 'xhci_free_segments_for_ring()' to handle lists which do not loop. This makes it possible to use it in error paths of 'xhci_alloc_segments_for_ring()'. This change also prepares for switching the custom xhci linked segment list into to more standard list.h lists. [minor commit message rewording -Mathias] Signed-off-by:
Niklas Neronin <niklas.neronin@linux.intel.com> Signed-off-by:
-
Niklas Neronin authored
Replace a segment of code within 'xhci_clear_command_ring()' with a function call to 'xhci_initialize_ring_info()'. This change eliminates code duplication, as 'xhci_initialize_ring_info()' performs the same operations as the replaced code. Signed-off-by:
-
Niklas Neronin authored
Slot ID is a index of a virtual device in struct 'xhci_hcd->devs[]'. Previously, to get the slot ID associated with a port, we had to loop through all devices and compare ports, which is very inefficient. Instead, the slot ID (of the device which is directly connected to the port), is added to the its corresponding 'xhci_port' struct. As a result, finding the port's device is quick and easy. Function 'xhci_find_slot_id_by_port()' is removed, as it is no longer needed. Signed-off-by:
Niklas Neronin <niklas.neronin@intel.com> Signed-off-by:
-
Niklas Neronin authored
Variables real & fake port do not convey their purpose, thus they are replaced with a pointer to the root hub port 'struct xhci_port *rhub_port'. 'rhub_port' contains real & fake ports in zero-based format, which happens to be more widely used inside the xHCI driver: - 'real_port' is ('rhub_port->hw_portnum' + 1) - 'fake_port' is ('rhub_port->hcd_portnum' + 1) One reason for real port being one-based, is to signal other functions in case struct 'xhci_virt_device' initialization failed, in this case the value will remain 0. This is no longer needed, instead we check whether or not 'rhub_port' is 'NULL'. Signed-off-by: -
Niklas Neronin authored
xHC hardware needs to know which roothub port a USB device is attached to when controlling the device, so the xHCI driver stores in each device the roothub port which it's connected behind. This is done with two different port index values, the 'real_port' which is an index to the xHC hardware port register array, and the 'fake_port' which is the per hub port index used by the hub driver. Instead of finding real & fake port separately, find the root hub port 'xhci_port' structure which contains both real & fake port values: - 'real_port' is ('hw_portnum' + 1) - 'fake_port' is ('hcd_portnum' + 1) i.e. real & fake port are 'hw_portnum' & 'hcd_portnum' in one-based format. The 'xhci_port' structure is a better way to refer to roothub ports than the 'real_port' & 'fake_port'. As a result, these port indexes are slated to be replaced with a direct pointer to the root hub port. This patch setups the ground work for the future changes. Signed-off-by: -
Ricardo B. Marliere authored
Since commit 43a7206b ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the structures typec_mux_class, retimer_class and typec_class to be declared at build time placing them into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Ricardo B. Marliere <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240301-class_cleanup-usb-v1-1-50309e325095@marliere.netSigned-off-by:
-
