| Age | Commit message (Collapse) | Author |
|---|
|
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: b2be2b05cf3b ("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>
|
