The parent field in struct acpi_device is, in fact, redundant,
because the dev.parent field in it effectively points to the same
object and it is used by the driver core.
Accordingly, the parent field can be dropped from struct acpi_device
and for this purpose define acpi_dev_parent() to retrieve a parent
struct acpi_device pointer from the dev.parent field in struct
acpi_device. Next, update all of the users of the parent field
in struct acpi_device to use acpi_dev_parent() instead of it and
drop it.
While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only used
in one place in a confusing way.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
Use acpi_find_child_by_adr() to find the child matching a given bus
address instead of tb_acpi_find_port() that walks the list of children
of an ACPI device directly for this purpose and drop the latter.
Apart from simplifying the code, this will help to eliminate the
children list head from struct acpi_device as it is redundant and it
is used in questionable ways in some places (in particular, locking is
needed for walking the list pointed to it safely, but it is often
missing).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
In order to make the underneath API easier to change in the future,
prevent users from dereferencing fwnode from struct device.
Instead, use the specific dev_fwnode() API for that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
If protocol tunnels are already up when the driver is loaded, for
instance if the boot firmware implements connection manager of its own,
runtime PM reference count of the consumer devices behind the tunnel
might have been increased already before the device link is created but
the supplier device runtime PM reference count is not. This leads to a
situation where the supplier (the Thunderbolt driver) can runtime
suspend even if it should not because the corresponding protocol tunnel
needs to be up causing the devices to be removed from the corresponding
native bus.
Prevent this from happening by making both sides of the link runtime PM
active briefly. The pm_runtime_put() for the consumer (PCIe
root/downstream port, xHCI) then allows it to runtime suspend again but
keeps the supplier runtime resumed the whole time it is runtime active.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Typically retimers can be accessed only when the USB4 link is up (e.g
there is a cable connected). However, sometimes it is useful to be able
to access retimers even if there is nothing connected to the USB4 port.
For instance we may still want to be able to upgrade the retimer NVM
firmware even if the user does not have any USB4 devices. This is
something that USB4 spec leaves to implementers.
In case of ACPI based systems, we can support this by providing a
special _DSM method under each USB4 port. This _DSM can be used to turn
on power to on-board retimers (and cycle it through different modes so
that the sideband becomes usable).
This patch adds support for this _DSM and makes the functionality
available to the rest of the driver through tb_acpi_power_[on|off]_retimers().
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This includes following Thunderbolt/USB4 changes for v5.12 merge
window:
* Start lane initialization after sleep for Thunderbolt 3 compatible
devices
* Add support for de-authorizing PCIe tunnels (software based
connection manager only)
* Add support for new ACPI 6.4 USB4 _OSC
* Allow disabling XDomain protocol
* Add support for new SL5 security level
* Clean up kernel-docs to pass W=1 builds
* A couple of cleanups and minor fixes
All these have been in linux-next without reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmAib9IgHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKAykw/+JfXClHYVlqRh
IH7kFkD4nA7g7359PpmSLxRBzvkivz7w66BqNtp6GhIF1oGRtDJ5t5ufgwdYX3Ld
tqH2Glhw9gV5EmeqDzq3TbLzAU+zm9a5bVE3vwQbxpgPGtDigKpDjqUobGFooDaB
F8EX3H3rwI3i+1/S1vBAZbuJqND0cuDM2yQNYJ//Dch2wnZ/Vy6darzY+GpJYSWi
ZlzWsvhfbo1V3n1PphzRkvzcMbVcJriVfwJihtY1h3H6RnnD4pqQJ7e1ec+4Pgdv
fql3lJg0M02rzTSYLyLwuMOojZA+gPqLWb3Fj5pkfjcKoneq1BNTsl4xRzDpqwP3
/DeOPE+TO6SAsAkRksyH5W9nvaYGmLy0r9JREkkzdhH41RML4ueEjstaJyfWn1N+
bX2Ba+5A9pIWKYbwfbNTZPyHk9r94IdDDXzjXFLSeOTcCwMf97XX4sgrbPHedxh6
VAjIrYxuSCTRRN1G6xtPI9aer5wh7e01W71WK3SJhvpqs092E0m0p4gN/nm6yW1Z
SSJg36uqp0egjU/NxsyNvB1ePQFiUkO7WIow9pVBU+US7vSuW9IXbC59lAx0XUE5
tonIF7zAiz1hLp6DZRYfTX7R9xbyshep0uhESceCcIsF5winsgUXL76QEMN0fEjf
wmUG/HWrOd2O/IH8704rfnu7ajxATGM=
=pzr4
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v5.12 merge window
This includes following Thunderbolt/USB4 changes for v5.12 merge
window:
* Start lane initialization after sleep for Thunderbolt 3 compatible
devices
* Add support for de-authorizing PCIe tunnels (software based
connection manager only)
* Add support for new ACPI 6.4 USB4 _OSC
* Allow disabling XDomain protocol
* Add support for new SL5 security level
* Clean up kernel-docs to pass W=1 builds
* A couple of cleanups and minor fixes
All these have been in linux-next without reported issues.
* tag 'thunderbolt-for-v5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (27 commits)
thunderbolt: Add support for native USB4 _OSC
ACPI: Add support for native USB4 control _OSC
ACPI: Execute platform _OSC also with query bit clear
thunderbolt: Allow disabling XDomain protocol
thunderbolt: Add support for PCIe tunneling disabled (SL5)
thunderbolt: dma_test: Drop unnecessary include
thunderbolt: Add clarifying comments about USB4 terms router and adapter
thunderbolt: switch: Fix kernel-doc descriptions of non-static functions
thunderbolt: nhi: Fix kernel-doc descriptions of non-static functions
thunderbolt: path: Fix kernel-doc descriptions of non-static functions
thunderbolt: eeprom: Fix kernel-doc descriptions of non-static functions
thunderbolt: ctl: Fix kernel-doc descriptions of non-static functions
thunderbolt: switch: Fix function name in the header
thunderbolt: tunnel: Fix misspelling of 'receive_path'
thunderbolt: icm: Fix a couple of formatting issues
thunderbolt: switch: Demote a bunch of non-conformant kernel-doc headers
thunderbolt: tb: Kernel-doc function headers should document their parameters
thunderbolt: nhi: Demote some non-conformant kernel-doc headers
thunderbolt: xdomain: Fix 'tb_unregister_service_driver()'s 'drv' param
thunderbolt: eeprom: Demote non-conformant kernel-doc headers to standard comment blocks
...
ACPI 6.4 introduced a new _OSC capability used to negotiate whether the
OS is supposed to use Software (native) or Firmware based Connection
Manager. If the native support is granted then there are set of bits
that enable/disable different tunnel types that the Software Connection
Manager is allowed to tunnel.
This adds support for this new USB4 _OSC accordingly. When PCIe
tunneling is disabled then the driver switches security level to be
"nopcie" following the security level 5 used in Firmware based
Connection Manager.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
When we walk up the device hierarchy in tb_acpi_add_link() make sure we
break the loop if the device has no parent. Otherwise we may crash the
kernel by dereferencing a NULL pointer.
Fixes: b2be2b05cf ("thunderbolt: Create device links from ACPI description")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The new way to describe relationship between tunneled ports and USB4 NHI
(Native Host Interface) is with ACPI _DSD looking like below for a PCIe
downstream port:
Scope (\_SB.PCI0)
{
Device (NHI0) { } // Thunderbolt NHI
Device (DSB0) // Hotplug downstream port
{
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"usb4-host-interface", \_SB.PCI0.NHI0},
...
}
})
}
}
This is "documented" in these [1] USB-IF slides and being used on
systems that ship with Windows.
The _DSD can be added to tunneled USB3 and PCIe ports, and is needed to
make sure the USB4 NHI is resumed before any of the tunneled ports so
the protocol tunnels get established properly before the actual port
itself is resumed. Othwerwise the USB/PCI core find the link may not be
established and starts tearing down the device stack.
This parses the ACPI description each time NHI is probed and tries to
find devices that has the property and it references the NHI in
question. For each matching device a device link from that device to the
NHI is created.
Since USB3 ports themselves do not get runtime suspended with the parent
device (hub) we do not add the link from the USB3 port to USB4 NHI but
instead we add the link from the xHCI device. This makes the device link
usable for runtime PM as well.
[1] https://www.usb.org/sites/default/files/D1T2-2%20-%20USB4%20on%20Windows.pdf
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Rafael J. Wysocki