- 20 Sep, 2020 4 commits
-
-
Peter Chen authored
Some DRD controllers (eg, dwc3 & cdns3) have PHY management at their own driver to cover both device and host mode, so add one priv quirk for such users to skip PHY management from HCD core. Reviewed-by:
Jun Li <jun.li@nxp.com> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200918131752.16488-5-mathias.nyman@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
The if {} condition is duplicated with outer if {} condition. Reviewed-by: -
Peter Chen authored
Some platforms (eg cdns3) may have special sequences between xhci_bus_suspend and xhci_suspend, add .suspend_quick for it. Reviewed-by:
-
Peter Chen authored
Some xhci hosts (eg dwc3 and cdns3) do not use OF to create platform device, they create xhci-plat platform device runtime. And these platforms may also have quirks, and the quirks could be supplied by their parent device through platform data. Reviewed-by:
-
- 17 Sep, 2020 2 commits
-
-
Oliver Neukum authored
Buffers should be u8*, not unsigned char* Buffers have an unsigned length and using an int as a boolean is a bit outdated. No functional change intended. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20200917110235.11854-1-oneukum@suse.comSigned-off-by:
-
Oliver Neukum authored
Handling for removal of the controller was missing at one place. Add it. Signed-off-by:
-
- 16 Sep, 2020 23 commits
-
-
Marc Zyngier authored
If the dwc2 driver fails to probe after having enabled the regulators, it ends up being unregistered with regulators enabled, something the core regulator code is legitimately upset about: dwc2 ff400000.usb: supply vusb_d not found, using dummy regulator dwc2 ff400000.usb: supply vusb_a not found, using dummy regulator dwc2 ff400000.usb: dwc2_core_reset: HANG! AHB Idle timeout GRSTCTL GRSTCTL_AHBIDLE WARNING: CPU: 2 PID: 112 at drivers/regulator/core.c:2074 _regulator_put.part.0+0x16c/0x174 Modules linked in: dwc2(E+) dwc3(E) udc_core(E) rtc_hym8563(E) dwmac_generic(E) ulpi(E) usbcore(E) dwc3_meson_g12a(E) roles(E) meson_gx_mmc(E+) i2c_meson(E) mdio_mux_meson_g12a(E) mdio_mux(E) dwmac_meson8b(E) stmmac_platform(E) stmmac(E) mdio_xpcs(E) phylink(E) of_mdio(E) fixed_phy(E) libphy(E) pwm_regulator(E) fixed(E) CPU: 2 PID: 112 Comm: systemd-udevd Tainted: G E 5.9.0-rc4-00102-g423583bc8cf9 #1840 Hardware name: amlogic w400/w400, BIOS 2020.04 05/22/2020 pstate: 80400009 (Nzcv daif +PAN -UAO BTYPE=--) pc : _regulator_put.part.0+0x16c/0x174 lr : regulator_bulk_free+0x6c/0x9c sp : ffffffc012353820 x29: ffffffc012353820 x28: ffffff805a4b7000 x27: ffffff8059c2eac0 x26: ffffff8059c2e810 x25: ffffff805a4b7d00 x24: ffffffc008cf3028 x23: ffffffc011729ef8 x22: ffffff807e2761d8 x21: ffffffc01171df78 x20: ffffff805a4b7700 x19: ffffff805a4b7700 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: ffffff807ea8d178 x14: 3935312820435455 x13: 2038323a36313a37 x12: ffffffffffffffff x11: 0000000000000040 x10: 0000000000000007 x9 : ffffffc0106f77d0 x8 : ffffffffffffffe0 x7 : ffffffffffffffff x6 : 0000000000017702 x5 : ffffff805a4b7400 x4 : 0000000000000000 x3 : ffffffc01171df78 x2 : ffffff807ea8cc40 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: _regulator_put.part.0+0x16c/0x174 regulator_bulk_free+0x6c/0x9c devm_regulator_bulk_release+0x28/0x3c release_nodes+0x1c8/0x2c0 devres_release_all+0x44/0x6c really_probe+0x1ec/0x504 driver_probe_device+0x100/0x170 device_driver_attach+0xcc/0xd4 __driver_attach+0xb0/0x17c bus_for_each_dev+0x7c/0xd4 driver_attach+0x30/0x3c bus_add_driver+0x154/0x250 driver_register+0x84/0x140 __platform_driver_register+0x54/0x60 dwc2_platform_driver_init+0x2c/0x1000 [dwc2] do_one_initcall+0x54/0x2d0 do_init_module+0x68/0x29c In order to fix this, tie the regulator disabling to the teardown process by registering a devm action callback. This makes sure that the regulators are disabled at the right time (just before they are released). Cc: Minas Harutyunyan <hminas@synopsys.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200914130634.2424496-1-maz@kernel.orgSigned-off-by:
-
Badhri Jagan Sridharan authored
ROLE_CONTROL register would not have the actual CC terminations unless the port does not set ROLE_CONTROL.DRP. For DRP ports, CC_STATUS.cc1/cc2 indicates the final terminations applied when TCPC enters potential_connect_as_source/_sink. For DRP ports, infer port role from CC_STATUS and set corresponding CC terminations before setting the orientation. Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20200901025927.3596190-4-badhri@google.comSigned-off-by:
-
Badhri Jagan Sridharan authored
TCPCI spec forbids direct access of TX_BUF_BYTE_x register. The existing version of tcpci driver assumes that those registers are directly addressible. Add support for tcpci chips which do not support direct access to TX_BUF_BYTE_x registers. TX_BUF_BYTE_x can only be accessed by I2C_WRITE_BYTE_COUNT. Reviewed-by:
-
Badhri Jagan Sridharan authored
Add register definitions to trap extended alerts. Reviewed-by:
-
Oliver Neukum authored
The SCSI layer has introduced a new macro for recording the result of a command. Use it. Signed-off-by:
-
Oliver Neukum authored
The SCSI layer can go into an ugly loop if you ignore that a device is gone. You need to report an error in the command rather than in the return value of the queue method. We need to specifically check for ENODEV. The issue goes back to the introduction of the driver. Fixes: 115bb1ff ("USB: Add UAS driver") Signed-off-by:
-
Azhar Shaikh authored
The SoC expects the USB Type-C ports numbers to be starting with 0. If the port number is passed as it is, the IOM status will not be updated. The IOM port status check fails which will eventually lead to PMC IPC communication failure. Fixes: 43d596e3 ("usb: typec: intel_pmc_mux: Check the port status before connect") Suggested-by:
Utkarsh Patel <utkarsh.h.patel@intel.com> Signed-off-by:
Azhar Shaikh <azhar.shaikh@intel.com> Signed-off-by:
-
Heikki Krogerus authored
Since the driver now needs to find the IOM ACPI node, the driver depends on ACPI. Without the dependency set, the driver will only fail to compile when ACPI is not enabled. Fixes: 43d596e3 ("usb: typec: intel_pmc_mux: Check the port status before connect") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Oliver Neukum authored
The SCSI layer is providing a new macro. Let's use it. Signed-off-by:
-
Greg Kroah-Hartman authored
A USB device will always haev a bi-directional endpoint 0, that's just how the devices work, so no need to check for that in a few quirk tests as it will always pass. Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Alexander Tsoy <alexander@tsoy.me> Reported-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200914153756.3412156-12-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The usb_control_msg_send() and usb_control_msg_recv() calls can return an error if a "short" write/read happens, and they can handle data off of the stack, so move the driver over to using those calls instead, saving some logic when dynamically allocating memory. Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Link: https://lore.kernel.org/r/20200914153756.3412156-11-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The usb_control_msg_send() call can return an error if a "short" write happens, so move the driver over to using that call instead. Cc: Jaroslav Kysela <perex@perex.cz> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200914153756.3412156-10-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The usb_control_msg_send() and usb_control_msg_recv() calls can return an error if a "short" write/read happens, and they can handle data off of the stack, so move the driver over to using those calls instead, saving some logic when dynamically allocating memory. Cc: Jaroslav Kysela <perex@perex.cz> Cc: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by:
-
Greg Kroah-Hartman authored
The usb_control_msg_send() and usb_control_msg_recv() calls can return an error if a "short" write/read happens, so move the driver over to using those calls instead, saving some logic in the wrapper functions that were being used in this driver. This also resolves a long-staging bug where data on the stack was being sent in a USB control message, which was not allowed. Cc: Jaroslav Kysela <perex@perex.cz> Reviewed-by:
-
Greg Kroah-Hartman authored
The usb_control_msg_send() call can handle data on the stack, as well as returning an error if a "short" write happens, so move the driver over to using that call instead. This ends up removing a helper function that is no longer needed. Cc: Jaroslav Kysela <perex@perex.cz> Reviewed-by:
-
Greg Kroah-Hartman authored
The usb_control_msg_recv() function can handle data on the stack, as well as properly detecting short reads, so move to use that function instead of the older usb_control_msg() call. This ends up removing a lot of extra lines in the driver. Cc: Juergen Stuber <starblue@users.sourceforge.net> Link: https://lore.kernel.org/r/20200914153756.3412156-6-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
There are a few calls to usb_control_msg() that can be converted to use usb_control_msg_send() instead, so do that in order to make the error checking a bit simpler and the code smaller. Reviewed-by:
-
Greg Kroah-Hartman authored
There are a few calls to usb_control_msg() that can be converted to use usb_control_msg_send() instead, so do that in order to make the error checking a bit simpler. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200914153756.3412156-4-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
New core functions to make sending/receiving USB control messages easier and saner. In discussions, it turns out that the large majority of users of usb_control_msg() do so in potentially incorrect ways. The most common issue is where a "short" message is received, yet never detected properly due to "incorrect" error handling. Handle all of this in the USB core with two new functions to try to make working with USB control messages simpler. No more need for dynamic data, messages can be on the stack, and only "complete" send/receive will work without causing an error. Link: https://lore.kernel.org/r/20200914153756.3412156-3-gregkh@linuxfoundation.orgSigned-off-by:
-
Greg Kroah-Hartman authored
snd_usb_pipe_sanity_check() is a great function, so let's move it into the USB core so that other parts of the kernel, including the USB core, can call it. Name it usb_pipe_type_check() to match the existing usb_urb_ep_type_check() call, which now uses this function. Cc: Jaroslav Kysela <perex@perex.cz> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Eli Billauer <eli.billauer@gmail.com> Cc: Emiliano Ingrassia <ingrassia@epigenesys.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Tsoy <alexander@tsoy.me> Cc: "Geoffrey D. Bennett" <g@b4.vu> Cc: Jussi Laako <jussi@sonarnerd.net> Cc: Nick Kossifidis <mickflemm@gmail.com> Cc: Dmitry Panchenko <dmitry@d-systems.ee> Cc: Chris Wulff <crwulff@gmail.com> Cc: Jesus Ramos <jesus-ramos@live.com> Reviewed-by:
-
Liu Shixin authored
Simplify the return expression. Acked-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Link: https://lore.kernel.org/r/20200915032631.1772673-1-liushixin2@huawei.comSigned-off-by:
-
ChiYuan Huang authored
Add a devicetree binding documentation for the MT6360 Type-C driver. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1598928042-22115-2-git-send-email-u0084500@gmail.comSigned-off-by:
-
ChiYuan Huang authored
Mediatek MT6360 is a multi-functional IC that includes USB Type-C. It works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Reviewed-by:
-
- 14 Sep, 2020 7 commits
-
-
Randy Dunlap authored
Fix typo/spello of "function". Cc: Felipe Balbi <balbi@kernel.org> Cc: Jiri Kosina <trivial@kernel.org> Signed-off-by:
-
YueHaibing authored
commit b35c5009 ("USB: EHCI: create per-TT bandwidth tables") left behind this, remove it. Acked-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200909134405.34036-1-yuehaibing@huawei.comSigned-off-by:
-
Hamish Martin authored
The 'distrust_firmware' module parameter dates from 2004 and the USB subsystem is a lot more mature and reliable now than it was then. Alter the default to false now. Suggested-by:
Hamish Martin <hamish.martin@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200910212512.16670-2-hamish.martin@alliedtelesis.co.nzSigned-off-by:
-
Hamish Martin authored
Some integrated OHCI controller hubs do not expose all ports of the hub to pins on the SoC. In some cases the unconnected ports generate spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC contains a nominally 3 port hub but only the first port is wired. Default behaviour for ohci-platform driver is to use global over-current protection mode (AKA "ganged"). This leads to the spurious over-current events affecting all ports in the hub. We now alter the default to use per-port over-current protection. This patch results in the following configuration changes depending on quirks: - For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up for ganged power switching and no over-current protection. - For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching remains at none, while over-current protection is now guaranteed to be set to per-port rather than the previous behaviour where it was either none or global over-current protection depending on the value at function entry. Suggested-by:
-
Lukas Bulwahn authored
Commit f24f27b8 ("MAINTAINERS: add entry for mediatek usb3 DRD IP driver") claims linux-usb@vger.kernel.org is moderated for non-subscribers, but all other 46 entries for linux-usb@vger.kernel.org do not mention that. Adjust this entry to be consistent with all others. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20200912121346.2796-1-lukas.bulwahn@gmail.comSigned-off-by:
-
Chris Packham authored
The ehci controller found in some Broadcom switches with integrated SoCs has an issue which causes a soft lockup with large transfers like you see when running ext4 on USB3 flash drive. Port the fix from the Broadcom XLDK to increase the OUT_THRESHOLD to avoid the problem. Acked-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200913215926.29880-1-chris.packham@alliedtelesis.co.nzSigned-off-by:
-
Greg Kroah-Hartman authored
We need the USB fixes in here as well. Signed-off-by:
-
- 13 Sep, 2020 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "A collection of fixes I've been accruing over the last few weeks, none of them have been severe enough to warrant flushing the queue but it's been long enough now that it's a good idea to send them in. A handful of them are fixups for QSPI DT/bindings/compatibles, some smaller fixes for system DMA clock control and TMU interrupts on i.MX, a handful of fixes for OMAP, including a fix for DSI (display) on omap5" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (27 commits) arm64: dts: ns2: Fixed QSPI compatible string ARM: dts: BCM5301X: Fixed QSPI compatible string ARM: dts: NSP: Fixed QSPI compatible string ARM: dts: bcm: HR2: Fixed QSPI compatible string dt-bindings: spi: Fix spi-bcm-qspi compatible ordering ARM: dts: imx6sx: fix the pad QSPI1B_SCLK mux mode for uart3 arm64: dts: imx8mp: correct sdma1 clk setting arm64: dts: imx8mq: Fix TMU interrupt property ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy ARM: dts: vfxxx: Add syscon compatible with OCOTP ARM: dts: imx6q-logicpd: Fix broken PWM arm64: dts: imx: Add missing imx8mm-beacon-kit.dtb to build ARM: dts: imx6q-prtwd2: Remove unneeded i2c unit name ARM: dts: imx6qdl-gw51xx: Remove unneeded #address-cells/#size-cells ARM: dts: imx7ulp: Correct gpio ranges ARM: dts: ls1021a: fix QuadSPI-memory reg range arm64: defconfig: Enable ptn5150 extcon driver arm64: defconfig: Enable USB gadget with configfs ARM: configs: Update Integrator defconfig ARM: dts: omap5: Fix DSI base address and clocks ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB/Thunderbolt fixes from Greg KH: "Here are some small USB and Thunderbolt driver fixes for 5.9-rc5. Nothing huge, just a number of bugfixes and new device ids for problems reported: - new USB serial driver ids - bug fixes for syzbot reported problems - typec driver fixes - thunderbolt driver fixes - revert of reported broken commit All of these have been in linux-next with no reported issues" * tag 'usb-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: typec: intel_pmc_mux: Do not configure SBU and HSL Orientation in Alternate modes usb: typec: intel_pmc_mux: Do not configure Altmode HPD High usb: core: fix slab-out-of-bounds Read in read_descriptors Revert "usb: dwc3: meson-g12a: fix shared reset control use" usb: typec: ucsi: acpi: Check the _DEP dependencies usb: typec: intel_pmc_mux: Un-register the USB role switch usb: Fix out of sync data toggle if a configured device is reconfigured USB: serial: option: support dynamic Quectel USB compositions USB: serial: option: add support for SIM7070/SIM7080/SIM7090 modules thunderbolt: Use maximum USB3 link rate when reclaiming if link is not up thunderbolt: Disable ports that are not implemented USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging/IIO driver fixes from Greg KH: "Here are a number of staging and IIO driver fixes for 5.9-rc5. The majority of these are IIO driver fixes, to resolve a timestamp issue that was recently found to affect a bunch of IIO drivers. The other fixes in here are: - small IIO driver fixes - greybus driver fix - counter driver fix (came in through the IIO fixes tree) All of these have been in linux-next for a while with no reported issues" * tag 'staging-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (23 commits) iio: adc: mcp3422: fix locking on error path iio: adc: mcp3422: fix locking scope iio: adc: meson-saradc: Use the parent device to look up the calib data iio:adc:max1118 Fix alignment of timestamp and data leak issues iio:adc:ina2xx Fix timestamp alignment issue. iio:adc:ti-adc084s021 Fix alignment and data leak issues. iio:adc:ti-adc081c Fix alignment and data leak issues iio:magnetometer:ak8975 Fix alignment and data leak issues. iio:light:ltr501 Fix timestamp alignment issue. iio:light:max44000 Fix timestamp alignment and prevent data leak. iio:chemical:ccs811: Fix timestamp alignment and prevent data leak. iio:proximity:mb1232: Fix timestamp alignment and prevent data leak. iio:accel:mma7455: Fix timestamp alignment and prevent data leak. iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak. iio:accel:mma8452: Fix timestamp alignment and prevent data leak. iio: accel: kxsd9: Fix alignment of local buffer. iio: adc: rockchip_saradc: select IIO_TRIGGERED_BUFFER iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set counter: microchip-tcb-capture: check the correct variable iio: cros_ec: Set Gyroscope default frequency to 25Hz ...
-
