summaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)Author
2024-04-11usb: misc: onboard_usb_hub: Disable the USB hub clock on failureFabio Estevam
In case regulator_bulk_enable() fails, the previously enabled USB hub clock should be disabled. Fix it accordingly. Fixes: 65e62b8a955a ("usb: misc: onboard_usb_hub: Add support for clock input") Cc: stable <stable@kernel.org> Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20240409162910.2061640-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-11usb: typec: mux: gpio-sbu: Allow GPIO operations to sleepFrancesco Dolcini
Use gpiod_set_value_cansleep() to support gpiochips which can sleep like, e.g. I2C GPIO expanders. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240409190910.4707-1-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: typec: ucsi_glink: drop special handling for CCI_BUSYDmitry Baryshkov
Newer Qualcomm platforms (sm8450+) successfully handle busy state and send the Command Completion after sending the Busy state. Older devices have firmware bug and can not continue after sending the CCI_BUSY state, but the command that leads to CCI_BUSY is already forbidden by the NO_PARTNER_PDOS quirk. Follow other UCSI glue drivers and drop special handling for CCI_BUSY event. Let the UCSI core properly handle this state. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240408-qcom-ucsi-fixes-bis-v1-3-716c145ca4b1@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: typec: ucsi_glink: drop NO_PARTNER_PDOS quirk for sm8550 / sm8650Dmitry Baryshkov
The Qualcomm SM8550 (and via a fallback compat SM8650) firmware properly handles the GET_PDOS command, it sends the CCI_BUSY notification, and then follows with the CCI_COMMAND_COMPLETE event. Stop using the quirk for those two platforms. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240408-qcom-ucsi-fixes-bis-v1-2-716c145ca4b1@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS quirk on qcm6490Dmitry Baryshkov
Enable the UCSI_DELAY_DEVICE_PDOS quirk on Qualcomm QCM6490. This platform also doesn't correctly handle reading PD capabilities until PD partner is connected. Fixes: 5da727f75823 ("usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS quirk") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240408-qcom-ucsi-fixes-bis-v1-1-716c145ca4b1@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: typec: ucsi: Wait 20ms before reading CCI after a resetPavan Holla
The PPM might take time to process a reset. Allow 20ms for the reset to be processed before reading the CCI. This should not slow down existing implementations because they would not set any bits in the CCI after a reset, and would take a 20ms delay to read the CCI anyway. This change makes the delay explicit, and reduces a CCI read. Based on the spec, the PPM has 10ms to set busy, so, 20ms seems like a reasonable delay before we read the CCI. Signed-off-by: Pavan Holla <pholla@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240409-ucsi-reset-delay-v3-1-8440710b012b@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: dwc3: pci: Don't set "linux,phy_charger_detect" property on Lenovo Yoga ↵Hans de Goede
Tab2 1380 The Lenovo Yoga Tablet 2 Pro 1380 model is the exception to the rule that devices which use the Crystal Cove PMIC without using ACPI for battery and AC power_supply class support use the USB-phy for charger detection. Unlike the Lenovo Yoga Tablet 2 830 / 1050 models this model has an extra LC824206XA Micro USB switch which does the charger detection. Add a DMI quirk to not set the "linux,phy_charger_detect" property on the 1380 model. This quirk matches on the BIOS version to differentiate the 1380 model from the 830 and 1050 models which otherwise have the same DMI strings. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240406140127.17885-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: chipidea: move ci_ulpi_init after the phy initializationMichael Grzeschik
The function ci_usb_phy_init is already handling the hw_phymode_configure path which is also only possible after we have a valid phy. So we move the ci_ulpi_init after the phy initialization to be really sure to be able to communicate with the ulpi phy. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20240328-chipidea-phy-misc-v1-1-907d9de5d4df@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: phy-generic: add short delay after pulling the reset pinMichael Grzeschik
After pulling the reset pin some phys are not immediately ready. We add a short delay of at least 10 ms to ensure that the phy can be properly used. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Link: https://lore.kernel.org/r/20240402-phy-misc-v1-1-de5c17f93f17@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: dwc2: host: Fix dereference issue in DDMA completion flow.Minas Harutyunyan
Fixed variable dereference issue in DDMA completion flow. Fixes: b258e4268850 ("usb: dwc2: host: Fix ISOC flow in DDMA mode") CC: stable@vger.kernel.org Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-usb/2024040834-ethically-rumble-701f@gregkh/T/#m4c4b83bef0ebb4b67fe2e0a7d6466cbb6f416e39 Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Link: https://lore.kernel.org/r/cc826d3ef53c934d8e6d98870f17f3cdc3d2755d.1712665387.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-09usb: typec: mux: it5205: Fix ChipID value typoAngeloGioacchino Del Regno
The ChipID bytes are read in inverse order: invert the ChipID value defined as IT5205FN_CHIP_ID and used for validating the same. Fixes: 41fe9ea1696c ("usb: typec: mux: Add ITE IT5205 Alternate Mode Passive MUX driver") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240409113646.305105-1-angelogioacchino.delregno@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-05usb: gadget: fsl: Initialize udc before using itUwe Kleine-König
fsl_ep_queue() is only called by usb_ep_queue() (as ep->ops->queue()). So _ep isn't NULL. As ep->ops->queue = fsl_ep_queue, the ep was initialized by struct_ep_setup() and so ep->udc isn't NULL either. Drop the check for _ep being NULL and assign udc earlier to prevent following an uninitialized pointer in the two dev_vdbg()s in lines 878 and 882. This fixes a compiler warning when using clang and CONFIG_USB_GADGET_VERBOSE=y. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404050227.TTvcCPBu-lkp@intel.com/ Fixes: 6025f20f16c2 ("usb: gadget: fsl-udc: Replace custom log wrappers by dev_{err,warn,dbg,vdbg}") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240405055812.694123-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: misc: uss720: check for incompatible versions of the Belkin F5U002Alex Henrie
The incompatible device in my possession has a sticker that says "F5U002 Rev 2" and "P80453-B", and lsusb identifies it as "050d:0002 Belkin Components IEEE-1284 Controller". There is a bug report from 2007 from Michael Trausch who was seeing the exact same errors that I saw in 2024 trying to use this cable. Link: https://lore.kernel.org/all/46DE5830.9060401@trausch.us/ Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Link: https://lore.kernel.org/r/20240326150723.99939-5-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: misc: uss720: add support for another variant of the Belkin F5U002Alex Henrie
This device is a gray USB parallel port adapter with "F5U002" imprinted on the plastic and a sticker that says both "F5U002" and "P80453-A". It's identified in lsusb as "05ab:1001 In-System Design BAYI Printer Class Support". It's subtly different from the other gray cable I have that has "F5U002 Rev 2" and "P80453-B" on its sticker and device ID 050d:0002. The uss720 driver appears to work flawlessly with this device, although the device evidently does not support ECP. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Link: https://lore.kernel.org/r/20240326150723.99939-4-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: misc: uss720: document the names of the compatible devicesAlex Henrie
Information about 04b8:0002 and 05ab:0002 is from commit e3cb7bde9a6a ("USB: misc: uss720: more vendor/product ID's", 2018-03-20). The rest are from <http://reboots.g-cipher.net/lcd/>. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Link: https://lore.kernel.org/r/20240326150723.99939-3-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: misc: uss720: point pp->dev to usbdev->devAlex Henrie
This avoids a "fix this legacy no-device port driver" warning from parport_announce_port in drivers/parport/share.c. The parport driver now requires a pointer to the device struct. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/20240326150723.99939-2-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi_acpi: Remove Dell quirkChristian A. Ehrhardt
The Dell quirk from ucsi_acpi.c. The quirk is no longer necessary as we no longer send lone connector change acks. Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240327224554.1772525-4-lk@c--e.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: Never send a lone connector change ackChristian A. Ehrhardt
Some PPM implementation do not like UCSI_ACK_CONNECTOR_CHANGE without UCSI_ACK_COMMAND_COMPLETE. Moreover, doing this is racy as it requires sending two UCSI_ACK_CC_CI commands in a row and the second one will be started with UCSI_CCI_ACK_COMPLETE already set in CCI. Bundle the UCSI_ACK_CONNECTOR_CHANGE with the UCSI_ACK_COMMAND_COMPLETE for the UCSI_GET_CONNECTOR_STATUS command that is sent while handling a connector change event. Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240327224554.1772525-3-lk@c--e.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: Stop abuse of bit definitions from ucsi.hChristian A. Ehrhardt
In ucsi.h there are flag definitions for the ->flags field in struct ucsi. Some implementations abuse these bits for their private ->flags fields e.g. in struct ucsi_acpi. Move the definitions into the backend implementations that still need them. While there fix one instance where the flag name was not converted in a previous change. No semantic change intended. Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240327224554.1772525-2-lk@c--e.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS quirkDmitry Baryshkov
Enable the UCSI_DELAY_DEVICE_PDOS quirk on anything past sc8180x / sm8350. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-9-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi_glink: rework quirks implementationDmitry Baryshkov
In preparation to adding more quirks, extract quirks to the static variables and reference them through match->data. Otherwise adding more quirks will add the table really cumbersome. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-8-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: support delaying GET_PDOS for deviceDmitry Baryshkov
Qualcomm firmware doesn't return sane information for device's PDOs unless the partner is also using a PD mode. On SC8280XP this even results in the Error bit being set in the UCSI response (with 0 error status). Add a quirk to delay reading USB PD capabilities for a device until we detect a partner in PD mode. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-7-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: extract code to read PD capsDmitry Baryshkov
Extract function to read PDOs from the port and set PD capabilities accordingly. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-6-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: simplify partner's PD caps registrationDmitry Baryshkov
In a way similar to the previous commit, move typec_partner_set_usb_power_delivery() to be called after reading the PD caps. This also removes calls to usb_power_delivery_unregister_capabilities() from the error path. Keep all capabilities registered until they are cleared by ucsi_unregister_partner_pdos(). Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-5-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: always register a link to USB PD deviceDmitry Baryshkov
UCSI driver will attempt to set a USB PD device only if it was able to read PDOs from the firmware. This results in suboptimal behaviour, since the PD device will be created anyway. Move calls to typec_port_set_usb_power_delivery() out of conditional code and call it after reading capabilities. Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-4-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: properly register partner's PD deviceDmitry Baryshkov
Use typec_partner_usb_power_delivery_register() to register PD device for Type-C partner so that the PD device is nested under the partner's device in sysfs. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-3-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: limit the UCSI_NO_PARTNER_PDOS even furtherDmitry Baryshkov
Reading Partner Source PDOs for the consumer Connectors appears to be working. Permit getting PDOs in this case in order to populate capabilities of the connected power supply in the sysfs. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-2-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: allow non-partner GET_PDOS for Qualcomm devicesDmitry Baryshkov
The name and description of the USB_NO_PARTNER_PDOS quirk specifies that only retrieving PDOS of the attached device is crashing. Retrieving PDOS of the UCSI device works. Fix the condition to limit the workaround only to is_partner cases. Fixes: 1d103d6af241 ("usb: typec: ucsi: fix UCSI on buggy Qualcomm devices") Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-1-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: displayport: drop driver owner assignmentKrzysztof Kozlowski
Core in typec_altmode_register_driver() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240331091737.19836-3-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: nvidia: drop driver owner assignmentKrzysztof Kozlowski
Core in typec_altmode_register_driver() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240331091737.19836-2-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: phy: fsl-usb: drop driver owner assignmentKrzysztof Kozlowski
Core in platform_driver_register() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240331091737.19836-1-krzk@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: Only enable supported notificationsDiogo Ivo
The UCSI specification defines some notifications to be optional for the PPM to support. From these only enable the ones the PPM informs us are actually supported. Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/yhz7nq622mbg3rqsyvqz632pc756niagpfbnzayfswhzo7esho@vrdtx5c3hjgx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: gadget: omap_udc: remove unused variableArnd Bergmann
The driver_desc variable is only used in some configurations: drivers/usb/gadget/udc/omap_udc.c:113:19: error: unused variable 'driver_desc' [-Werror,-Wunused-const-variable] Since there is only ever one user of it, just open-code the string in place and remove the global variable and the macro behind it. This also helps grep for the MODULE_DESCRIPTION string. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240403080702.3509288-26-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ptn36502: Only select DRM_AUX_BRIDGE with OFNathan Chancellor
CONFIG_DRM_AUX_BRIDGE depends on CONFIG_OF but that dependency is not included when CONFIG_TYPEC_MUX_PTN36502 selects it, resulting in a Kconfig warning when CONFIG_OF is disabled: WARNING: unmet direct dependencies detected for DRM_AUX_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n] Selected by [m]: - TYPEC_MUX_PTN36502 [=m] && USB_SUPPORT [=y] && TYPEC [=m] && I2C [=y] && (DRM [=y] || DRM [=y]=n) && DRM_BRIDGE [=y] Only select CONFIG_DRM_AUX_BRIDGE when CONFIG_DRM_BRIDGE and CONFIG_OF are enabled to clear up the warning. This results in no functional change because prior to the refactoring that introduces this warning, ptn36502_register_bridge() returned 0 when CONFIG_OF was disabled, which continues to occur with drm_aux_bridge_register() when CONFIG_DRM_AUX_BRIDGE is not enabled. Fixes: 9dc28ea21eb4 ("usb: typec: ptn36502: switch to DRM_AUX_BRIDGE") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240328-fix-ptn36502-drm_aux_bridge-select-v1-1-85552117e26e@kernel.org Link: https://lore.kernel.org/r/20240404123534.2708591-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: Disable USB3 LPM at shutdownKai-Heng Feng
SanDisks USB3 storage may disapper after system reboot: usb usb2-port3: link state change xhci_hcd 0000:00:14.0: clear port3 link state change, portsc: 0x2c0 usb usb2-port3: do warm reset, port only xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping usb2 port polling xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2b0, return 0x2b0 usb usb2-port3: not warm reset yet, waiting 50ms xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2f0, return 0x2f0 usb usb2-port3: not warm reset yet, waiting 200ms ... xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x6802c0, return 0x7002c0 usb usb2-port3: not warm reset yet, waiting 200ms xhci_hcd 0000:00:14.0: clear port3 reset change, portsc: 0x4802c0 xhci_hcd 0000:00:14.0: clear port3 warm(BH) reset change, portsc: 0x4002c0 xhci_hcd 0000:00:14.0: clear port3 link state change, portsc: 0x2c0 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x2c0, return 0x2c0 usb usb2-port3: not enabled, trying warm reset again... This is due to the USB device still cause port change event after xHCI is shuted down: xhci_hcd 0000:38:00.0: // Setting command ring address to 0xffffe001 xhci_hcd 0000:38:00.0: xhci_resume: starting usb3 port polling. xhci_hcd 0000:38:00.0: xhci_hub_status_data: stopping usb4 port polling xhci_hcd 0000:38:00.0: xhci_hub_status_data: stopping usb3 port polling xhci_hcd 0000:38:00.0: hcd_pci_runtime_resume: 0 xhci_hcd 0000:38:00.0: xhci_shutdown: stopping usb3 port polling. xhci_hcd 0000:38:00.0: // Halt the HC xhci_hcd 0000:38:00.0: xhci_shutdown completed - status = 1 xhci_hcd 0000:00:14.0: xhci_shutdown: stopping usb1 port polling. xhci_hcd 0000:00:14.0: // Halt the HC xhci_hcd 0000:00:14.0: xhci_shutdown completed - status = 1 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x1203, return 0x203 xhci_hcd 0000:00:14.0: set port reset, actual port 2-3 status = 0x1311 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x201203, return 0x100203 xhci_hcd 0000:00:14.0: clear port3 reset change, portsc: 0x1203 xhci_hcd 0000:00:14.0: clear port3 warm(BH) reset change, portsc: 0x1203 xhci_hcd 0000:00:14.0: clear port3 link state change, portsc: 0x1203 xhci_hcd 0000:00:14.0: clear port3 connect change, portsc: 0x1203 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x1203, return 0x203 usb 2-3: device not accepting address 2, error -108 xhci_hcd 0000:00:14.0: xHCI dying or halted, can't queue_command xhci_hcd 0000:00:14.0: Set port 2-3 link state, portsc: 0x1203, write 0x11261 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x1263, return 0x263 xhci_hcd 0000:00:14.0: set port reset, actual port 2-3 status = 0x1271 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x12b1, return 0x2b1 usb usb2-port3: not reset yet, waiting 60ms ACPI: PM: Preparing to enter system sleep state S5 xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0x12f1, return 0x2f1 usb usb2-port3: not reset yet, waiting 200ms reboot: Restarting system The port change event is caused by LPM transition, so disabling LPM at shutdown to make sure the device is in U0 for warmboot. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20240305065140.66801-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport errorNorihiko Hama
When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established. Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20240327023550.51214-1-Norihiko.Hama@alpsalpine.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: tcpm: Correct the PDO counting in pd_setKyle Tso
Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one. When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected). "nr_src_pdo" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets. Fixes: cd099cde4ed2 ("usb: typec: tcpm: Support multiple capabilities") Cc: stable@vger.kernel.org Signed-off-by: Kyle Tso <kyletso@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240404133517.2707955-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: gadget: functionfs: Wait for fences before enqueueing DMABUFPaul Cercueil
Instead of bailing when fences have already been installed on the DMABUF, wait for them (with a timeout) when doing a blocking operation. This fixes the issue where userspace would submit a DMABUF with fences already installed, with the (correct) expectation that it would just work. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20240402110951.16376-3-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: gadget: functionfs: Fix inverted DMA fence directionPaul Cercueil
A "read" fence was installed when the DMABUF was to be written to, and a "write" fence was installed when the DMABUF was to be read from. Besides, dma_resv_usage_rw() should only be used when waiting for fences. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20240402110951.16376-2-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: typec: ucsi: Fix connector check on initChristian A. Ehrhardt
Fix issues when initially checking for a connector change: - Use the correct connector number not the entire CCI. - Call ->read under the PPM lock. - Remove a bogus READ_ONCE. Fixes: 808a8b9e0b87 ("usb: typec: ucsi: Check for notifications after init") Cc: stable@kernel.org Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20240401210515.1902048-1-lk@c--e.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04xhci: Fix root hub port null pointer dereference in xhci tracepointsMathias Nyman
The pointer from a xhci usb virt device to its root hub port (vdev->rhub_port) is set later when device is addressed, not while vdev is allocated. Tracepoints dereferenced this rhub_port pointer when freeing the virt device, which causes null pointer dereference if tracing is enabled and device is freed before addressed. This can happen if tracing is enabled and xhci driver is unloaded before a device is fully enumerated, or initial enumeration fails and device is reset and freed before retry. Don't dereference the rhub_port or show port numbers when tracing xhci_free_virt_device(). This info is not very useful anyway. Print the more useful slot id instead Fixes: 06790c19086f ("xhci: replace real & fake port with pointer to root hub port") Reported-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Closes: https://lore.kernel.org/linux-usb/20240402005007.klv2ij727fkz7rpd@synopsys.com/ Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240404121106.2842417-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-04usb: xhci: correct return value in case of STS_HCEOliver Neukum
If we get STS_HCE we give up on the interrupt, but for the purpose of IRQ handling that still counts as ours. We may return IRQ_NONE only if we are positive that it wasn't ours. Hence correct the default. Fixes: 2a25e66d676d ("xhci: print warning when HCE was set") Cc: stable@vger.kernel.org # v6.2+ Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240404121106.2842417-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-01Merge 6.9-rc2 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: misc: onboard_dev: add support for XMOS XVF3500Javier Carrasco
The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit multicore controller for voice processing. This device requires a specific power sequence, which consists of enabling the regulators that control the 3V3 and 1V0 device supplies, and a reset de-assertion after a delay of at least 100ns. Once in normal operation, the XVF3500 registers itself as a USB device, and it does not require any device-specific operations in the driver. [1] https://www.xmos.com/xvf3500/ Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-8-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: misc: onboard_dev: add support for non-hub devicesJavier Carrasco
Most of the functionality this driver provides can be used by non-hub devices as well. To account for the hub-specific code, add a flag to the device data structure and check its value for hub-specific code. The 'always_powered_in_supend' attribute is only available for hub devices, keeping the driver's default behavior for non-hub devices (keep on in suspend). Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-6-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: misc: onboard_hub: rename to onboard_devJavier Carrasco
This patch prepares onboad_hub to support non-hub devices by renaming the driver files and their content, the headers and their references. The comments and descriptions have been slightly modified to keep coherence and account for the specific cases that only affect onboard hubs (e.g. peer-hub). The "hub" variables in functions where "dev" (and similar names) variables already exist have been renamed to onboard_dev for clarity, which adds a few lines in cases where more than 80 characters are used. No new functionality has been added. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-2-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: misc: onboard_hub: use device supply namesJavier Carrasco
The current implementation uses generic names for the power supplies, which conflicts with proper name definitions in the device bindings. Add a per-device property to include real supply names and keep generic names for existing devices to keep backward compatibility. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-1-29e3f9222922@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: chipidea: ci_hdrc_imx: align usb wakeup clock name with dt-bindingsXu Yang
The dt-bindings is going to use "usb_wakeup" as wakup clock name. This will align the change with dt-bindings. Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20240321081439.541799-11-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: renesas_usbhs: Remove trailing comma in the terminator entry for OF tableBiju Das
Remove the trailing comma in the terminator entry for the OF table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240319105356.87287-6-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-27usb: renesas_usbhs: Update usbhs pipe configuration for RZ/G2L familyBiju Das
The RZ/G2L family SoCs has 10 pipe buffers compared to 16 pipe buffers on RZ/A2M. Update the pipe configuration for RZ/G2L family SoCs and use family SoC specific compatible to handle this difference. The pipe configuration of RZ/G2L is same as usbhsc_rzg2l_default_pipe[], so select the default pipe configuration for RZ/G2L SoCs by setting .has_new_pipe_configs to zero. Add SoC specific compatible to OF table to avoid ABI breakage with old DTB. To optimize memory usage the SoC specific compatible will be removed later. Based on the patch in BSP by Huy Nguyen <huy.nguyen.wh@renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240319105356.87287-5-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>