linux.git/drivers/phy/tegra/xusb.h, branch v5.13.1 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git phy: tegra: Don't use device-managed API to allocate ports 2020-03-19T13:00:05+00:00 Thierry Reding treding@nvidia.com 2020-03-19T10:52:13+00:00 e78fdbad1e902f422a7a0452cce8378d2652f219 The device-managed allocation API doesn't work well with the life-cycle of device objects. Since ports have device objects allocated within, it can lead to situations where these devices need to stay around until after their parent pad controller has been unbound from its driver. The device-managed memory allocated for the port objects will, however, get freed when the pad controller unbinds from the driver. This can cause use-after-free errors down the road. Note that the device is deleted as part of the driver unbind operation, so there isn't much that can be done with it after that point, but the memory still needs to stay around to ensure none of the references are invalidated. One situation where this arises is when a VBUS supply is associated with a USB 2 or 3 port. When that supply is released using regulator_put() an SRCU call will queue the release of the device link connecting the port and the regulator after a grace period. This means that the regulator is going to keep on to the last reference of the port device even after the pad controller driver was unbound (which is when the memory backing the port device is freed). Fix this by allocating port objects using non-device-managed memory. Add release callbacks for these objects so that their memory gets freed when the last reference goes away. This decouples the port devices' lifetime from the "active" lifetime of the pad controller (i.e. the time during which the pad controller driver owns the device). Signed-off-by: Thierry Reding <treding@nvidia.com> 
The device-managed allocation API doesn't work well with the life-cycle
of device objects. Since ports have device objects allocated within, it
can lead to situations where these devices need to stay around until
after their parent pad controller has been unbound from its driver. The
device-managed memory allocated for the port objects will, however, get
freed when the pad controller unbinds from the driver. This can cause
use-after-free errors down the road.

Note that the device is deleted as part of the driver unbind operation,
so there isn't much that can be done with it after that point, but the
memory still needs to stay around to ensure none of the references are
invalidated.

One situation where this arises is when a VBUS supply is associated with
a USB 2 or 3 port. When that supply is released using regulator_put() an
SRCU call will queue the release of the device link connecting the port
and the regulator after a grace period. This means that the regulator is
going to keep on to the last reference of the port device even after the
pad controller driver was unbound (which is when the memory backing the
port device is freed).

Fix this by allocating port objects using non-device-managed memory. Add
release callbacks for these objects so that their memory gets freed when
the last reference goes away. This decouples the port devices' lifetime
from the "active" lifetime of the pad controller (i.e. the time during
which the pad controller driver owns the device).

Signed-off-by: Thierry Reding <treding@nvidia.com>
phy: tegra: Fix regulator leak 2020-03-19T13:00:04+00:00 Thierry Reding treding@nvidia.com 2020-03-18T22:25:54+00:00 2f8da84def73e1dd89385146e1dbb2ae2c8e0a6a Devices are created for each port of the XUSB pad controller. Each USB 2 and USB 3 port can potentially have an associated VBUS power supply that needs to be removed when the device is removed. Since port devices never bind to a driver, the driver core will not get to perform the cleanup of device-managed resources that usually happens on driver unbind. Now, the driver core will also perform device-managed resource cleanup for driver-less devices when they are released. However, when a device link is created between the regulator and the port device, as part of regulator_get(), the regulator takes a reference to the port device and prevents it from being released unless regulator_put() is called, which will never happen. Avoid this by using the non-device-managed API and manually releasing the regulator reference when the port is unregistered. Signed-off-by: Thierry Reding <treding@nvidia.com> 
Devices are created for each port of the XUSB pad controller. Each USB 2
and USB 3 port can potentially have an associated VBUS power supply that
needs to be removed when the device is removed.

Since port devices never bind to a driver, the driver core will not get
to perform the cleanup of device-managed resources that usually happens
on driver unbind.

Now, the driver core will also perform device-managed resource cleanup
for driver-less devices when they are released. However, when a device
link is created between the regulator and the port device, as part of
regulator_get(), the regulator takes a reference to the port device and
prevents it from being released unless regulator_put() is called, which
will never happen.

Avoid this by using the non-device-managed API and manually releasing
the regulator reference when the port is unregistered.

Signed-off-by: Thierry Reding <treding@nvidia.com>
phy: tegra: xusb: Add Tegra194 support 2020-03-19T12:59:46+00:00 JC Kuo jckuo@nvidia.com 2020-02-12T06:11:30+00:00 1ef535c6ba8ebcad1ced47a9d382b162c34fba3a Add support for the XUSB pad controller found on Tegra194 SoCs. It is mostly similar to the same IP found on Tegra186, but the number of pads exposed differs, as do the programming sequences. Because most of the Tegra194 XUSB PADCTL registers definition and programming sequence are the same as Tegra186, Tegra194 XUSB PADCTL can share the same driver, xusb-tegra186.c, with Tegra186 XUSB PADCTL. Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. This patch adds a "maximum-speed" property to usb3 ports which can be used to specify the maximum supported speed for any particular USB 3.1 port. For a port that is not capable of SuperSpeedPlus, "maximum-speed" property should carry "super-speed". Signed-off-by: JC Kuo <jckuo@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
Add support for the XUSB pad controller found on Tegra194 SoCs. It is
mostly similar to the same IP found on Tegra186, but the number of
pads exposed differs, as do the programming sequences. Because most of
the Tegra194 XUSB PADCTL registers definition and programming sequence
are the same as Tegra186, Tegra194 XUSB PADCTL can share the same
driver, xusb-tegra186.c, with Tegra186 XUSB PADCTL.

Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it
is possible for some platforms have long signal trace that could not
provide sufficient electrical environment for Gen 2 speed. This patch
adds a "maximum-speed" property to usb3 ports which can be used to
specify the maximum supported speed for any particular USB 3.1 port.
For a port that is not capable of SuperSpeedPlus, "maximum-speed"
property should carry "super-speed".

Signed-off-by: JC Kuo <jckuo@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
phy: tegra: xusb: Add usb-phy support 2020-03-19T12:59:45+00:00 Nagarjuna Kristam nkristam@nvidia.com 2020-02-10T08:11:30+00:00 e8f7d2f409a15c519d5a6085777d85c1c4bab73a For USB 2 ports that has usb-role-switch enabled, add usb-phy for corresponding USB 2 phy. USB role changes from role switch are then updated to corresponding host and device mode drivers via usb-phy notifier block. Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> [treding@nvidia.com: rebase onto Greg's usb-next branch] Signed-off-by: Thierry Reding <treding@nvidia.com> 
For USB 2 ports that has usb-role-switch enabled, add usb-phy for
corresponding USB 2 phy. USB role changes from role switch are then
updated to corresponding host and device mode drivers via usb-phy notifier
block.

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
[treding@nvidia.com: rebase onto Greg's usb-next branch]
Signed-off-by: Thierry Reding <treding@nvidia.com>
phy: tegra: xusb: Add usb-role-switch support 2020-03-19T12:54:35+00:00 Nagarjuna Kristam nkristam@nvidia.com 2020-02-10T08:11:29+00:00 f67213cee2b35fe169a723746b7f37debf20fa29 If usb-role-switch property is present in USB 2 port, register usb-role-switch to receive usb role changes. Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> [treding@nvidia.com: rebase onto Greg's usb-next branch] Signed-off-by: Thierry Reding <treding@nvidia.com> 
If usb-role-switch property is present in USB 2 port, register
usb-role-switch to receive usb role changes.

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
[treding@nvidia.com: rebase onto Greg's usb-next branch]
Signed-off-by: Thierry Reding <treding@nvidia.com>
phy: tegra: xusb: Add vbus override support on Tegra210 2019-10-23T07:50:36+00:00 Nagarjuna Kristam nkristam@nvidia.com 2019-10-18T09:38:08+00:00 90767cdfea89c3ac7012035d66633b9ba839091a Tegra XUSB device control driver needs to control vbus override during its operations, add API for the support. Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> 
Tegra XUSB device control driver needs to control vbus override
during its operations, add API for the support.

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
phy: tegra: xusb: Add usb3 port fake support on Tegra210 2019-10-23T07:50:34+00:00 Nagarjuna Kristam nkristam@nvidia.com 2019-10-18T09:38:07+00:00 a5be28c3656af71f1c9d75381f7b86d5056da9f3 On Tegra210, usb2 only otg/peripheral ports dont work in device mode. They need an assosciated usb3 port to work in device mode. Identify an unused usb3 port and assign it as a fake USB3 port to USB2 only port whose mode is otg/peripheral. Based on work by BH Hsieh <bhsieh@nvidia.com>. Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> 
On Tegra210, usb2 only otg/peripheral ports dont work in device mode.
They need an assosciated usb3 port to work in device mode. Identify
an unused usb3 port and assign it as a fake USB3 port to USB2 only
port whose mode is otg/peripheral.

Based on work by BH Hsieh <bhsieh@nvidia.com>.

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288 2019-06-05T15:36:37+00:00 Thomas Gleixner tglx@linutronix.de 2019-05-29T14:18:02+00:00 2025cf9e193de05b0654570dd639acb49ebd3adf Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 263 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms and conditions of the gnu general public license
  version 2 as published by the free software foundation this program
  is distributed in the hope it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 263 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
phy: tegra: xusb: Add Tegra186 support 2019-04-17T08:42:47+00:00 JC Kuo jckuo@nvidia.com 2019-02-21T15:46:34+00:00 bbf711682cd570697086e88388a2c718da918894 Add support for the XUSB pad controller found on Tegra186 SoCs. It is mostly similar to the same IP found on earlier chips, but the number of pads exposed differs, as do the programming sequences. Note that the DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL power supplies of the XUSB pad controller require strict power sequencing and are therefore controlled by the PMIC on Tegra186. Signed-off-by: JC Kuo <jckuo@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> [dan.carpenter@oracle.com: Fix testing the wrong variable in probe()] Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> [yuehaibing@huawei.com: Make two functions static to fix sparse warning] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> 
Add support for the XUSB pad controller found on Tegra186 SoCs. It is
mostly similar to the same IP found on earlier chips, but the number of
pads exposed differs, as do the programming sequences.

Note that the DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL power
supplies of the XUSB pad controller require strict power sequencing and
are therefore controlled by the PMIC on Tegra186.

Signed-off-by: JC Kuo <jckuo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
[dan.carpenter@oracle.com: Fix testing the wrong variable in probe()]
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
[yuehaibing@huawei.com: Make two functions static to fix sparse warning]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
phy: tegra: xusb: Add support for power supplies 2019-04-17T08:42:45+00:00 Thierry Reding treding@nvidia.com 2019-02-21T15:46:33+00:00 a630d54dfa937a937e3faf172ca41b9bd2647c72 Support enabling various supplies needed to provide power to the PLLs and logic used to drive the USB, PCI and SATA pads. Reviewed-by: JC Kuo <jckuo@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> 
Support enabling various supplies needed to provide power to the PLLs
and logic used to drive the USB, PCI and SATA pads.

Reviewed-by: JC Kuo <jckuo@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>