- 20 Sep, 2020 7 commits
-
-
Peter Chen authored
If the xhci-plat.c is the platform driver, after the runtime pm is enabled, the xhci_suspend is called if nothing is connected on the port. When the system goes to suspend, it will call xhci_suspend again if USB wakeup is enabled. Since the runtime suspend wakeup setting is not always the same as system suspend wakeup setting, eg, at runtime suspend we always need wakeup if the controller is in low power mode; but at system suspend, we may not need wakeup. So, we move the judgement after changing wakeup setting. [commit message rewording -Mathias] 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-8-mathias.nyman@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Peter Chen authored
To reflect the current code status. Signed-off-by:
-
Peter Chen authored
With this change, there will be a wakeup entry at /sys/../power/wakeup, and the user could use this entry to choose whether enable xhci wakeup features (wake up system from suspend) or not. Tested-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
-
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:
-
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 1 commit
-
-
Linus Torvalds authored
-
