aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2020-12-09USB: serial: ftdi_sio: drop GPIO line checking dead codeMarc Zyngier1-3/+0
Now that gpiolib can track the validity of GPIO pins, there is no need to check whether the line is valid in request(). Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andy Shevchenko <[email protected]> [johan: amend commit message] Signed-off-by: Johan Hovold <[email protected]>
2020-12-09USB: serial: ftdi_sio: report the valid GPIO lines to gpiolibMarc Zyngier1-0/+14
Since it is pretty common for only some of the CBUS lines to be valid as GPIO lines, let's report such validity to the rest of the kernel. Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2020-12-09usb: oxu210hp-hcd: Fix memory leak in oxu_createZhang Qilong1-1/+3
usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when adding fails to prevent memory leak. Fixes: b92a78e582b1a ("usb host: Oxford OXU210HP HCD driver") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhang Qilong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: fotg210-hcd: remove casting dma_alloc_coherentXu Wang1-1/+1
Remove casting the values returned by dma_alloc_coherent. Signed-off-by: Xu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09USB: host: u123-hcd: remove trailing semicolon in macro definitionTom Rix1-3/+3
The macro use will already have a semicolon. Signed-off-by: Tom Rix <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: phy: Fix spelling mistake in Kconfig help textColin Ian King1-1/+1
There is a spelling mistake in the Kconfig help text. Fix it. Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09drivers: usb: atm: use pr_err() and pr_warn() instead of raw printk()Enrico Weigelt, metux IT consult2-2/+2
Since we have the nice helpers pr_err() and pr_warn(), use them instead of raw printk(). Acked-by: Duncan Sands <[email protected]> Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09drivers: usb: atm: use atm_info() instead of atm_printk(KERN_INFO ...Enrico Weigelt, metux IT consult1-3/+3
Since we already have the useful atm_info() macro, use it instead of raw atm_printk() Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09drivers: usb: atm: reduce noiseEnrico Weigelt, metux IT consult1-3/+0
If drivers work correctly, they should remain silent. Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09USB: serial: option: add interface-number sanity check to flag handlingJohan Hovold1-2/+21
Add an interface-number sanity check before testing the device flags to avoid relying on undefined behaviour when left shifting in case a device uses an interface number greater than or equal to BITS_PER_LONG (i.e. 64 or 32). Reported-by: [email protected] Fixes: c3a65808f04a ("USB: serial: option: reimplement interface masking") Cc: [email protected] Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]>
2020-12-09usb: typec: tcpci_maxim: Enable VSAFE0V signallingBadhri Jagan Sridharan1-1/+15
Unmask EXTENDED_STATUS_MASK.vSafe0V, ALERT.Extended_Status and set vbus_vsafe0v to enable VSAFE0V signalling. Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: typec: tcpci: Add support to report vSafe0VBadhri Jagan Sridharan2-5/+40
This change adds vbus_vsafe0v which when set, makes TCPM query for VSAFE0V by assigning the tcpc.is_vbus_vsafe0v callback. Also enables ALERT.ExtendedStatus which is triggered when status of EXTENDED_STATUS.vSafe0V changes. EXTENDED_STATUS.vSafe0V is set when vbus is at vSafe0V and cleared otherwise. Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: typec: tcpm: Introduce vsafe0v for vbusBadhri Jagan Sridharan1-11/+52
TCPM at present lacks the notion of VSAFE0V. There are three vbus threshold levels that are critical to track: a. vSafe5V - VBUS “5 volts” as defined by the USB PD specification. b. vSinkDisconnect - Threshold used for transition from Attached.SNK to Unattached.SNK. c. vSafe0V - VBUS “0 volts” as defined by the USB PD specification. Tracking vSafe0V is crucial for entry into Try.SNK and Attached.SRC and turning vbus back on by the source in response to hard reset. >From "4.5.2.2.8.2 Exiting from AttachWait.SRC State" section in the Type-C spec: "The port shall transition to Attached.SRC when VBUS is at vSafe0V and the SRC.Rd state is detected on exactly one of the CC1 or CC2 pins for at least tCCDebounce." "A DRP that strongly prefers the Sink role may optionally transition to Try.SNK instead of Attached.SRC when VBUS is at vSafe0V and the SRC.Rd state is detected on exactly one of the CC1 or CC2 pins for at least tCCDebounce." >From "7.1.5 Response to Hard Resets" section in the PD spec: "After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V." vbus_present in the TCPM code tracks vSafe5V(vbus_present is true) and vSinkDisconnect(vbus_present is false). This change adds is_vbus_vsafe0v callback which when set makes TCPM query for vSafe0V voltage level when needed. Since not all TCPC controllers might have the capability to report vSafe0V, TCPM assumes that vSafe0V is same as vSinkDisconnect when is_vbus_vsafe0v callback is not set. This allows TCPM to continue to support controllers which don't have the support for reporting vSafe0V. Introducing vSafe0V helps fix the failure reported at "Step 15. CVS verifies PUT remains in AttachWait.SRC for 500ms" of "TD 4.7.2 Try. SNK DRP Connect DRP Test" of "Universal Serial Bus Type-C (USB Type-C) Functional Test Specification Chapters 4 and 5". Here the compliance tester intentionally maintains vbus at greater than vSafe0V and expects the Product under test to stay in AttachWait.SRC till vbus drops to vSafe0V. Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: typec: tcpm: Clear send_discover in tcpm_check_send_discoverBadhri Jagan Sridharan1-3/+2
tcpm_check_send_discover does not clear the send_discover flag when any of the following conditions are not met. 1. data_role is TYPEC_HOST 2. link is pd_capable Discovery indentity would anyways not be attempted during the current session anymore when the above conditions are not met. Hence clear the send_discover flag here to prevent tcpm_enable_frs_work from rescheduling indefinetly. Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: typec: tcpm: Pass down negotiated rev to update retry countBadhri Jagan Sridharan4-12/+21
nRetryCount was updated from 3 to 2 between PD2.0 and PD3.0 spec. nRetryCount in "Table 6-34 Counter parameters" of the PD 2.0 spec is set to 3, whereas, nRetryCount in "Table 6-59 Counter parameters" is set to 2. Pass down negotiated rev in pd_transmit so that low level chip drivers can update the retry count accordingly before attempting packet transmission. This helps in passing "TEST.PD.PORT.ALL.02" of the "Power Delivery Merged" test suite which was initially failing with "The UUT did not retransmit the message nReryCount times" In fusb302 & tcpci drivers, by default the driver sets the retry count to 3 (Default for PD 2.0). Update this to 2, if the negotiated rev is PD 3.0. In wcove, since the retry count is intentionally set to max, leaving it as is. Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: typec: intel_pmc_mux: Use correct response message bitsUtkarsh Patel1-2/+7
When Intel PMC Mux agent driver receives the response message from PMC, it checks for the same response bits for all the mux states. Corrected it by checking correct response message bits, Bit 8 & 9 for the SAFE Mode and Alternate Modes and Bit 16 & 17 for the Connect and Disconnect Modes. Reviewed-by: Heikki Krogerus <[email protected]> Signed-off-by: Utkarsh Patel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: ehci-omap: Fix PM disable depth umbalance in ehci_hcd_omap_probeZhang Qilong1-0/+1
The pm_runtime_enable will decrement the power disable depth. Imbalance depth will resulted in enabling runtime PM of device fails later. Thus a pairing decrement must be needed on the error handling path to keep it balanced. Fixes: 6c984b066d84b ("ARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs") Acked-by: Alan Stern <[email protected]> Signed-off-by: Zhang Qilong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09xhci: Give USB2 ports time to enter U3 in bus suspendLi Jun1-0/+4
If a USB2 device wakeup is not enabled/supported the link state may still be in U0 in xhci_bus_suspend(), where it's then manually put to suspended U3 state. Just as with selective suspend the device needs time to enter U3 suspend before continuing with further suspend operations (e.g. system suspend), otherwise we may enter system suspend with link state in U0. [commit message rewording -Mathias] Cc: <[email protected]> Signed-off-by: Li Jun <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09xhci-pci: Allow host runtime PM as default for Intel Maple Ridge xHCIMika Westerberg1-1/+3
Intel Maple Ridge is successor of Titan Ridge Thunderbolt controller. As Titan Ridge this one also includes xHCI host controller. In order to safe energy we should put it to low power state by default when idle. For this reason allow host runtime PM for Maple Ridge. Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09xhci-pci: Allow host runtime PM as default for Intel Alpine Ridge LPHans de Goede1-0/+2
The xHCI controller on Alpine Ridge LP keeps the whole Thunderbolt controller awake if the host controller is not allowed to sleep. This is the case even if no USB devices are connected to the host. Add the Intel Alpine Ridge LP product-id to the list of product-ids for which we allow runtime PM by default. Fixes: 2815ef7fe4d4 ("xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge") Cc: <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: xhci: Use temporary buffer to consolidate SGTejas Joglekar3-2/+133
The Synopsys xHC has an internal TRB cache of size TRB_CACHE_SIZE for each endpoint. The default value for TRB_CACHE_SIZE is 16 for SS and 8 for HS. The controller loads and updates the TRB cache from the transfer ring in system memory whenever the driver issues a start transfer or update transfer command. For chained TRBs, the Synopsys xHC requires that the total amount of bytes for all TRBs loaded in the TRB cache be greater than or equal to 1 MPS. Or the chain ends within the TRB cache (with a last TRB). If this requirement is not met, the controller will not be able to send or receive a packet and it will hang causing a driver timeout and error. This can be a problem if a class driver queues SG requests with many small-buffer entries. The XHCI driver will create a chained TRB for each entry which may trigger this issue. This patch adds logic to the XHCI driver to detect and prevent this from happening. For every (TRB_CACHE_SIZE - 2), we check the total buffer size of the SG list and if the last window of (TRB_CACHE_SIZE - 2) SG list length and we don't make up at least 1 MPS, we create a temporary buffer to consolidate full SG list into the buffer. We check at (TRB_CACHE_SIZE - 2) window because it is possible that there would be a link and/or event data TRB that take up to 2 of the cache entries. We discovered this issue with devices on other platforms but have not yet come across any device that triggers this on Linux. But it could be a real problem now or in the future. All it takes is N number of small chained TRBs. And other instances of the Synopsys IP may have smaller values for the TRB_CACHE_SIZE which would exacerbate the problem. Signed-off-by: Tejas Joglekar <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRKTejas Joglekar2-0/+4
This commit uses the private data passed by parent device to set the quirk for Synopsys xHC. This patch fixes the SNPS xHC hang issue when the data is scattered across small buffers which does not make atleast MPS size for given TRB cache size of SNPS xHC. Signed-off-by: Tejas Joglekar <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-09Merge tag 'phy-for-5.11' of ↵Greg Kroah-Hartman1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next Vinod writes: phy-for-5.11 - New phy drivers: - Mediatek MT7621 PCIe PHY (promoted from staging) - Ingenic USB phy driver supporting JZ4775 and X2000 - Intel Keem Bay USB PHY driver - Marvell USB HSIC PHY driver supporting MMP3 SoC - AXG MIPI D-PHY driver - Updates: - Conversion to YAML binding for: - Broadcom SATA PHY - Cadence Sierra PHY bindings - STM32 USBC Phy - Support for Exynos5433 PCIe PHY - Support for Qualcomm SM8250 PCIe QMP PHY - Support for Exynos5420 USB2 phy - devm_platform_ioremap_resource conversion for bunch of drivers * tag 'phy-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (72 commits) drm/mediatek: avoid dereferencing a null hdmi_phy on an error message phy: ingenic: depend on HAS_IOMEM phy: mediatek: statify mtk_hdmi_phy_driver dt-bindings: phy: Convert Broadcom SATA PHY to YAML devicetree: phy: rockchip-emmc add output-tapdelay-select phy: rockchip-emmc: output tap delay dt property PHY: Ingenic: Add USB PHY driver using generic PHY framework. dt-bindings: USB: Add bindings for Ingenic JZ4775 and X2000. USB: PHY: JZ4770: Remove unnecessary function calls. devicetree: phy: rockchip-emmc: pulldown property phy: rockchip: set pulldown for strobe line in dts phy: renesas: rcar-gen3-usb2: disable runtime pm in case of failure phy: mediatek: allow compile-testing the hdmi phy phy/rockchip: Make PHY_ROCKCHIP_INNO_HDMI depend on HAS_IOMEM to fix build error phy: samsung: Merge Kconfig for Exynos5420 and Exynos5250 phy: ralink: phy-mt7621-pci: set correct name in MODULE_DEVICE_TABLE macro phy: ralink: phy-mt7621-pci: drop 'COMPILE_TEST' from Kconfig phy: mediatek: Make PHY_MTK_{XSPHY, TPHY} depend on HAS_IOMEM and OF_ADDRESS to fix build errors phy: tegra: xusb: Fix usb_phy device driver field phy: amlogic: replace devm_reset_control_array_get() ...
2020-12-08USB: legotower: fix logical error in recent commitAlan Stern1-1/+1
Commit d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()") contained an elementary logical error. The check of the return code from the new usb_control_msg_recv() function was inverted. Reported-and-tested-by: [email protected] Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()") Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07USB: add RESET_RESUME quirk for Snapscan 1212Oliver Neukum1-0/+3
I got reports that some models of this old scanner need this when using runtime PM. Signed-off-by: Oliver Neukum <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07usb: typec: tps6598x: Export some power supply propertiesGuido Günther2-0/+104
This allows downstream supplies and userspace to detect whether external power is supplied. Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Guido Günther <[email protected]> Link: https://lore.kernel.org/r/2c8e81d9da9ff05b065f66edba915edd11f74065.1607166657.git.agx@sigxcpu.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07usb: typec: tps6598x: Select USB_ROLE_SWITCH and REGMAP_I2CGuido Günther1-2/+2
This is more in line with what tcpm does and will be needed to avoid recursive dependency like > drivers/power/supply/Kconfig:2:error: recursive dependency detected! drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by TYPEC_TPS6598X drivers/usb/typec/Kconfig:64: symbol TYPEC_TPS6598X depends on REGMAP_I2C drivers/base/regmap/Kconfig:19: symbol REGMAP_I2C is selected by CHARGER_ADP5061 drivers/power/supply/Kconfig:93: symbol CHARGER_ADP5061 depends on POWER_SUPPLY For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" when selecting POWER_SUPPLY. Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Guido Günther <[email protected]> Link: https://lore.kernel.org/r/6d11417c42d82caf66e08af160397959eb7d0d60.1607166657.git.agx@sigxcpu.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07usb: mtu3: fix memory corruption in mtu3_debugfs_regset()Dan Carpenter1-1/+1
This code is using the wrong sizeof() so it does not allocate enough memory. It allocates 32 bytes but 72 are required. That will lead to memory corruption. Fixes: ae07809255d3 ("usb: mtu3: add debugfs interface files") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/X8ikqc4Mo2/0G72j@mwanda Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07USB: dummy-hcd: Fix uninitialized array use in init()Bui Quang Minh1-1/+1
This error path err_add_pdata: for (i = 0; i < mod_data.num; i++) kfree(dum[i]); can be triggered when not all dum's elements are initialized. Fix this by initializing all dum's elements to NULL. Acked-by: Alan Stern <[email protected]> Cc: stable <[email protected]> Signed-off-by: Bui Quang Minh <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07usb: chipidea: ci_hdrc_imx: Pass DISABLE_DEVICE_STREAMING flag to imx6ulFabio Estevam1-1/+2
According to the i.MX6UL Errata document: https://www.nxp.com/docs/en/errata/IMX6ULCE.pdf ERR007881 also affects i.MX6UL, so pass the CI_HDRC_DISABLE_DEVICE_STREAMING flag to workaround the issue. Fixes: 52fe568e5d71 ("usb: chipidea: imx: add imx6ul usb support") Cc: <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Peter Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07USB: core: drop pipe-type check from new control-message helpersJohan Hovold1-4/+1
The new control-message helpers include a pipe-type check which is almost completely redundant. Control messages are generally sent to the default pipe which always exists and is of the correct type since its endpoint representation is created by USB core as part of enumeration for all devices. There is currently only one instance of a driver in the tree which use a control endpoint other than endpoint 0 (and it does not use the new helpers). Drivers should be testing for the existence of their resources at probe rather than at runtime, but to catch drivers failing to do so USB core already does a sanity check on URB submission and triggers a WARN(). Having the same sanity check done in the helper only suppresses the warning without allowing us to find and fix the drivers. Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-07Merge 5.10-rc7 into usb-nextGreg Kroah-Hartman10-46/+45
We want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-05USB: PHY: JZ4770: Remove unnecessary function calls.周琰杰 (Zhou Yanjie)1-1/+1
Remove unnecessary "of_match_ptr()", because Ingenic SoCs all depend on Device Tree. Suggested-by: Paul Cercueil <[email protected]> Signed-off-by: 周琰杰 (Zhou Yanjie) <[email protected]> Reviewed-by: Paul Cercueil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-04usb: mtu3: mtu3_debug: remove an unused struct memberDan Carpenter1-1/+0
The "nregs" member is not used. The code uses the "regset.nregs" struct member instead. Acked-by: Chunfeng Yun <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/X8ikv1QA3Do50D+R@mwanda Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04USB: core: return -EREMOTEIO on short usb_control_msg_recv()Johan Hovold1-1/+1
Return -EREMOTEIO instead of -EINVAL on short control transfers when using the new usb_control_msg_recv() helper. EINVAL is used to report invalid arguments (e.g. to the helper) and should not be used for unrelated errors. Many driver currently return -EIO on short control transfers but since host-controller drivers already use -EREMOTEIO for short transfers whenever the URB_SHORT_NOT_OK flag is set, let's use that here as well. This also allows usb_control_msg_recv() to eventually use URB_SHORT_NOT_OK without changing the return value again. Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04USB: core: drop short-transfer check from usb_control_msg_send()Johan Hovold1-3/+2
A failure to send a complete control message is always an error so there's no need to check for short transfers in usb_control_msg_send(). Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04USB: apple-mfi-fastcharge: Fix use after free in probeDan Carpenter1-1/+3
This code frees "mfi" and then derefences it on the next line to get the error code. Fixes: b0eec52fbe63 ("USB: apple-mfi-fastcharge: Fix kfree after failed kzalloc") Reviewed-by: Bastien Nocera <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/X8ik4j8yJitVUyfU@mwanda Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04usb: gadget: f_fs: Use local copy of descriptors for userspace copyVamsi Krishna Samavedam1-2/+4
The function may be unbound causing the ffs_ep and its descriptors to be freed while userspace is in the middle of an ioctl requesting the same descriptors. Avoid dangling pointer reference by first making a local copy of desctiptors before releasing the spinlock. Fixes: c559a3534109 ("usb: gadget: f_fs: add ioctl returning ep descriptor") Reviewed-by: Peter Chen <[email protected]> Signed-off-by: Vamsi Krishna Samavedam <[email protected]> Signed-off-by: Jack Pham <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04usb: ohci-omap: Fix descriptor conversionLinus Walleij1-2/+2
There were a bunch of issues with the patch converting the OMAP1 OSK board to use descriptors for controlling the USB host: - The chip label was incorrect - The GPIO offset was off-by-one - The code should use sleeping accessors This patch tries to fix all issues at the same time. Cc: Aaro Koskinen <[email protected]> Reported-by: Aaro Koskinen <[email protected]> Fixes: 15d157e87443 ("usb: ohci-omap: Convert to use GPIO descriptors") Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04Revert "usb-storage: fix sdev->host->dma_dev"Greg Kroah-Hartman2-4/+3
This reverts commit 0154012f8018bba4d9971d1007c12ffd48539ddb as Hans reports it causes problems on some systems. Until a "real" fix for this can be found, revert this change to get normal functionality back. Link: https://lore.kernel.org/r/[email protected] Cc: Tom Yan <[email protected]> Cc: Alan Stern <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04Revert "uas: fix sdev->host->dma_dev"Greg Kroah-Hartman1-11/+6
This reverts commit 558033c2828f832ab3b68c6f8b8710e0de6faef0 as Hans reports it causes problems on some systems. Until a "real" fix for this can be found, revert this change to get normal functionality back. Link: https://lore.kernel.org/r/[email protected] Cc: Tom Yan <[email protected]> Cc: Alan Stern <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04Revert "uas: bump hw_max_sectors to 2048 blocks for SS or faster drives"Greg Kroah-Hartman1-2/+0
This reverts commit 5df7ef7d32fec1d6d1c34dbec019b461a12ce870 as Hans reports it causes problems on some systems. Until a "real" fix for this can be found, revert this change to get normal functionality back. Link: https://lore.kernel.org/r/[email protected] Cc: Tom Yan <[email protected]> Cc: Alan Stern <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-04USB: serial: cp210x: clean up dtr_rts()Johan Hovold1-4/+4
Clean up dtr_rts() by renaming the port parameter and adding missing whitespace. Signed-off-by: Johan Hovold <[email protected]>
2020-12-04USB: serial: cp210x: refactor flow-control handlingJohan Hovold1-50/+47
Add a helper function to be used to configure flow control. The flow-control code was the last caller that relied on the memset-on-failure behaviour of cp210x_read_reg_block(), which we can now drop in favour of bailing out on errors when retrieving the flow-control settings. This should also simplify adding support for software flow control. Signed-off-by: Johan Hovold <[email protected]>
2020-12-04USB: serial: cp210x: drop flow-control debuggingJohan Hovold1-5/+1
Drop some unnecessary flow-control debugging. Signed-off-by: Johan Hovold <[email protected]>
2020-12-04USB: serial: cp210x: set terminal settings on openJohan Hovold1-283/+6
Unlike other drivers cp210x have been retrieving the current terminal settings from the device on open and reflecting those in termios. Due to how set_termios() used to be implemented, this saved a few control requests on open but has instead caused problems like broken flow control and has required adding workarounds for swapped line-control in cp2108 and line-speed initialisation on cp2104. This unusual implementation also complicates adding new features for no good reason. Rip out the corresponding code and the above mentioned workarounds and instead initialise the terminal settings unconditionally on open. Signed-off-by: Johan Hovold <[email protected]>
2020-12-04USB: serial: cp210x: clean up line-control handlingJohan Hovold1-60/+41
Update the line-control settings in one request unconditionally instead of setting the word-length, parity and stop-bit settings separately. This avoids multiple requests when several settings are changed even if this scheme could potentially also be used to detect unsupported device settings. Since all device types but CP2101 appears to support all settings, let's handle that one specifically and also report back the unsupported settings properly through termios by clearing the corresponding bits. Also drop the related unnecessary debug printks. Signed-off-by: Johan Hovold <[email protected]>
2020-12-04USB: serial: cp210x: return early on unchanged termiosJohan Hovold1-0/+12
Return early from set_termios() in case no relevant terminal settings have changed. This avoids testing each parameter in turn and specifically allows the line-control handling to be cleaned up further. Signed-off-by: Johan Hovold <[email protected]>
2020-12-04Merge tag 'usb-serial-5.10-rc7' of ↵Greg Kroah-Hartman3-12/+13
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for 5.10-rc7 Here's a fix for a regression in the option driver which has been backported to the stable trees and fix for a small memory leak on open in the kl5kusb105 driver. Included are also various new device ids. All but the memleak fix has been in linux-next and with no reported issues. * tag 'usb-serial-5.10-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: kl5kusb105: fix memleak on open USB: serial: ch341: sort device-id entries USB: serial: ch341: add new Product ID for CH341A USB: serial: option: fix Quectel BG96 matching USB: serial: option: add support for Thales Cinterion EXS82 USB: serial: option: add Fibocom NL668 variants
2020-12-04USB: serial: kl5kusb105: fix memleak on openJohan Hovold1-6/+4
Fix memory leak of control-message transfer buffer on successful open(). Fixes: 6774d5f53271 ("USB: serial: kl5kusb105: fix open error path") Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.