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
  ...

1 files changed, 18 insertions, 4 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index a91b4b24496e..d7f09d011b6d 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -49,6 +49,15 @@ Description:	Holds a comma separated list of device unique_ids that
 		If a device is authorized automatically during boot its
 		boot attribute is set to 1.
 
+What: /sys/bus/thunderbolt/devices/.../domainX/deauthorization
+Date:		May 2021
+KernelVersion:	5.12
+Contact:	Mika Westerberg <mika.westerberg@linux.intel.com>
+Description:	This attribute tells whether the system supports
+		de-authorization of devices. Value of 1 means user can
+		de-authorize PCIe tunnel by writing 0 to authorized
+		attribute under each device.
+
 What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
 Date:		Mar 2019
 KernelVersion:	4.21
@@ -76,6 +85,8 @@ Description:	This attribute holds current Thunderbolt security level
 		usbonly  Automatically tunnel USB controller of the
 			 connected Thunderbolt dock (and Display Port). All
 			 PCIe links downstream of the dock are removed.
+		nopcie   USB4 system where PCIe tunneling is disabled from
+			 the BIOS.
 		=======  ==================================================
 
 What: /sys/bus/thunderbolt/devices/.../authorized
@@ -84,22 +95,25 @@ KernelVersion:	4.13
 Contact:	thunderbolt-software@lists.01.org
 Description:	This attribute is used to authorize Thunderbolt devices
 		after they have been connected. If the device is not
-		authorized, no devices such as PCIe and Display port are
-		available to the system.
+		authorized, no PCIe devices are available to the system.
 
 		Contents of this attribute will be 0 when the device is not
 		yet authorized.
 
 		Possible values are supported:
 
-		==  ===========================================
+		==  ===================================================
+		0   The device will be de-authorized (only supported if
+		    deauthorization attribute under domain contains 1)
 		1   The device will be authorized and connected
-		==  ===========================================
+		==  ===================================================
 
 		When key attribute contains 32 byte hex string the possible
 		values are:
 
 		==  ========================================================
+		0   The device will be de-authorized (only supported if
+		    deauthorization attribute under domain contains 1)
 		1   The 32 byte hex string is added to the device NVM and
 		    the device is authorized.
 		2   Send a challenge based on the 32 byte hex string. If the