- 09 Jan, 2020 29 commits
-
-
Dmitry Osipenko authored
There is no need to use usb_phy_set_suspend during of driver's probe because now PHY driver enables hardware during of PHY's initialization. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200106013416.9604-20-digetx@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dmitry Osipenko authored
Add build dependency on USB_TEGRA_PHY since UDC driver isn't usable without the PHY. Signed-off-by:
-
Dmitry Osipenko authored
Tegra's USB PHY driver now provides generic PHY init/shutdown callbacks and thus the custom PHY management could be removed from Tegra-specific part of the ChipIdea driver. Signed-off-by:
-
Dmitry Osipenko authored
There is no good reason for disabling of CPU interrupts in order to protect the utmip_pad_count modification. Signed-off-by:
-
Dmitry Osipenko authored
It's unlikely that two drivers could manage PHY's state simultaneously in practice, nevertheless the utmip_pad_count checking should be under lock, for consistency. Signed-off-by:
-
Dmitry Osipenko authored
VBUS regulator should be turned off in a case of error. Signed-off-by:
-
Dmitry Osipenko authored
It is much more intuitive if reset is treated as asserted when GPIO value is set to 1. All NVIDIA Tegra device-trees are properly specifying active state of the reset-GPIO since 2013, let's clean up that part of the code. Signed-off-by:
-
Dmitry Osipenko authored
There is a mix of u32/ULONG usage in the driver's code. Let's switch to u32 uniformly, for consistency. Suggested-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
The resource-managed variant removes the necessity for the driver to care about freeing ULPI resources. Suggested-by:
-
Dmitry Osipenko authored
Now drivers (like NVIDIA Tegra USB PHY for example) will be able to benefit from the resource-managed variant, making driver's code a bit cleaner. Suggested-by:
-
Dmitry Osipenko authored
Regulator core provides dummy regulator if device-tree doesn't define VBUS regulator. Signed-off-by:
-
Dmitry Osipenko authored
There is nothing to synchronize in regards to memory stores, thus all readl/writel occurrences in the code could be replaced with a relaxed versions, for consistency. Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Dmitry Osipenko authored
Add "spinlock.h", which was included indirectly, and sort includes in alphabet order. Signed-off-by:
-
Dmitry Osipenko authored
This patch fixes few dozens of legit checkpatch warnings, adds missed handling of potential error-cases and prettifies code where makes sense. All these clean-up changes are quite minor and do not fix any real problems. Acked-by:
-
Dmitry Osipenko authored
Generic PHY provides init/shutdown callbacks which allow USB-host drivers to abstract PHY's hardware management in a common way. This change allows to remove Tegra-specific PHY handling from the ChipIdea driver. Note that ChipIdea's driver shall be changed at the same time because it turns PHY ON without the PHY's initialization and this doesn't work now, resulting in a NULL dereference of phy->freq because it's set during of the PHY's initialization. Acked-by:
Peter Chen <peter.chen@nxp.com> Acked-by:
-
Dmitry Osipenko authored
The PHY driver should keep track of the enable state, otherwise enable refcount is screwed if USB driver tries to enable PHY when it is already enabled. This will be the case for ChipIdea and Tegra EHCI drivers once PHY driver will gain support for the init/shutdown callbacks. Signed-off-by:
-
Dmitry Osipenko authored
Firstly, the PHY's clock needs to unprepared to keep prepare count balanced. Secondly, downstream code suggests that reset is synchronous and thus it should be asserted before disabling clock. Signed-off-by:
-
Dmitry Osipenko authored
I found that PHY's enable refcounting was broken and after fixing it I also found that machine started to hang after EHCI driver module removal. Turned out that the teardown order is incorrect because HCD must be unregistered *before* PHY's disabling. Note that it is also not correct to assert the shared reset during of driver's removal because PHY takes care of resetting shared pads and thus it's better to remove that part from the EHCI driver. Signed-off-by:
-
Dmitry Osipenko authored
NVIDIA Tegra SoCs use ChipIdea silicon IP for the USB controllers. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Fix up inconsistent usage of upper and lowercase letters in "Samsung" and "Exynos" names. "SAMSUNG" and "EXYNOS" are not abbreviations but regular trademarked names. Therefore they should be written with lowercase letters starting with capital letter. The lowercase "Exynos" name is promoted by its manufacturer Samsung Electronics Co., Ltd., in advertisement materials and on website. Although advertisement materials usually use uppercase "SAMSUNG", the lowercase version is used in all legal aspects (e.g. on Wikipedia and in privacy/legal statements on https://www.samsung.com/semiconductor/privacy-global/). Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200104152107.11407-9-krzk@kernel.orgSigned-off-by:
-
Heikki Krogerus authored
Defining the USB modes from the latest USB Power Delivery Specification - USB 2.0, USB 3.2 and USB4 - as special modal states just like the Accessory Modes. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191230142611.24921-14-heikki.krogerus@linux.intel.comSigned-off-by:
-
Heikki Krogerus authored
Passing all the details that the alternate mode drivers provide to the mux drivers during mode changes. The mux drivers will in practice need to be able to make decisions on their own. It is not enough that they get only the requested port state. With the Thunderbolt 3 alternate mode for example the mux driver will need to consider also the capabilities of the cable before configuring the mux. Signed-off-by:
-
Heikki Krogerus authored
Adding definitions for USB Type-C Specification Release 1.3, 1.4 and 2.0. Signed-off-by:
-
Heikki Krogerus authored
Discover Identity command response has also 3 product type specific VDOs on top of ID Header VDO, Cert Stat VDO and Product VDO. Signed-off-by:
-
Heikki Krogerus authored
The latest version of the USB Power Delivery Specification R3.0 added UFP and DFP product types for the Discover Identity message. Both types can be used for example for checking the USB capability of the partner, which means the USB modes (USB 2.0, USB 3.0 and USB4) that the partner device supports. Signed-off-by:
-
Heikki Krogerus authored
Version 2.0 of the USB Power Delivery Specification R3.0 defines a new message called Enter_USB, which is made with USB4 in mind. Enter_USB message is in practice the same as the Enter Mode command (used when entering alternate modes) that just needs to be used when entering USB4 mode. The message does also support entering USB 2.0 or USB 3.2 mode instead of USB4 mode, but it is only required with USB4. I.e. with USB2 and USB3 Enter_USB message is optional. Signed-off-by:
-
Heikki Krogerus authored
Thunderbolt 3, and probable USB4 too, will need to be able to get details about the cables. Adding typec_cable_get() function that the alternate mode drivers can use to gain access to gain access to the cable. Signed-off-by:
-
Heikki Krogerus authored
Enter Mode Command may contain one VDO. Signed-off-by:
-
Heikki Krogerus authored
Originally the port drivers were expected to check does the connector have the mode enabled or disabled when the alt mode drivers attempted to enter the mode, but since typec_altmode_enter() puts the connector into USB Safe State before calling the port driver, it really has to do the check on its own, and before changing the state. Otherwise the connector may be left in USB Safe State if the port driver does not move it back to normal USB operation when the mode is disabled. Signed-off-by:
-
- 08 Jan, 2020 9 commits
-
-
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200106111124.28100-1-colin.king@canonical.comSigned-off-by:
-
Krzysztof Kozlowski authored
Fix missing __iomem in cast to struct ehci_caps. This fixes the Sparse warning visible on x86_64 compile test: drivers/usb/host/ehci-mv.c:167:23: warning: cast removes address space '<asn:2>' of expression drivers/usb/host/ehci-mv.c:167:20: warning: incorrect type in assignment (different address spaces) drivers/usb/host/ehci-mv.c:167:20: expected struct ehci_caps [noderef] <asn:2> *caps drivers/usb/host/ehci-mv.c:167:20: got struct ehci_caps * Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Julia Lawall authored
Use resource_size rather than a verbose computation on the end and start fields. The semantic patch that makes these changes is as follows: (http://coccinelle.lip6.fr/) <smpl> @@ struct resource ptr; @@ - (ptr.end - ptr.start + 1) + resource_size(&ptr) </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/1577900990-8588-2-git-send-email-Julia.Lawall@inria.frSigned-off-by:
-
Julia Lawall authored
The usba_gadget_template structure is only copied into another structure, so make it const. The opportunity for this change was found using Coccinelle. Signed-off-by:
Cristian Birsan <cristian.birsan@microchip.com> Link: https://lore.kernel.org/r/1577864614-5543-5-git-send-email-Julia.Lawall@inria.frSigned-off-by:
-
Arnd Bergmann authored
gcc -O3 warns about correct code: inlined from 'oxu_hub_control.constprop' at drivers/usb/host/oxu210hp-hcd.c:3652:3: include/linux/string.h:411:9: error: argument 1 null where non-null expected [-Werror=nonnull] return __builtin_memset(p, c, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/host/oxu210hp-hcd.c: In function 'oxu_hub_control.constprop': include/linux/string.h:411:9: note: in a call to built-in function '__builtin_memset' Expand the code slightly to let gcc better understand it and not warn any more. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200107214354.1008937-1-arnd@arndb.deSigned-off-by:
-
Heikki Krogerus authored
The notification mask was not updated properly before all the notifications were enabled in ucsi_init(). Fixes: 71a1fa0d ("usb: typec: ucsi: Store the notification mask") Signed-off-by:
-
Randy Dunlap authored
Use "/*" for non-kernel-doc comments instead of "/**", which is intended to be used only for kernel-doc notation. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
-
Mika Westerberg authored
Now that Thunderbolt public specification is called USB4 and is coming from USB IF it makes sense to use linux-usb as mailing list for patches touching this driver. Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20200108125317.36444-3-mika.westerberg@linux.intel.comSigned-off-by:
-
Mika Westerberg authored
The code tried to check whether xhci variable has ROUTER_CS_6_HCI bit set but since xhci type is bool and it already holds true or false based on that very bit, fix the check to use the variable directly. Reported-by:
-
- 06 Jan, 2020 2 commits
-
-
Magnus Damm authored
Driver name is no longer printed out so update the README examples to avoid confusion. Signed-off-by:
Magnus Damm <damm+renesas@opensource.se> Acked-by:
Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/157677692518.684.15385402529285904844.sendpatchset@octoSigned-off-by:
-
Krzysztof Kozlowski authored
Some of the phy drivers can be compile tested to increase build coverage. Signed-off-by:
-
