summaryrefslogtreecommitdiffstats
path: root/Documentation/admin-guide/thunderbolt.rst
diff options
context:
space:
mode:
authorMika Westerberg <mika.westerberg@linux.intel.com>2020-11-10 09:47:14 +0100
committerMika Westerberg <mika.westerberg@linux.intel.com>2021-01-15 08:53:06 +0100
commit3da88be249973f7b74e7b24ed559e6abc2fc5af4 (patch)
treeb6c607a9375ca1303f7502e329d4ea478ca017df /Documentation/admin-guide/thunderbolt.rst
parentthunderbolt: Start lane initialization after sleep (diff)
downloadlinux-3da88be249973f7b74e7b24ed559e6abc2fc5af4.tar.xz
linux-3da88be249973f7b74e7b24ed559e6abc2fc5af4.zip
thunderbolt: Add support for de-authorizing devices
In some cases it is useful to be able de-authorize devices. For example if user logs out the userspace can have a policy that disconnects PCIe devices until logged in again. This is only possible for software based connection manager as it directly controls the tunnels. For this reason make the authorized attribute accept writing 0 which makes the software connection manager to tear down the corresponding PCIe tunnel. Userspace can check if this is supported by reading a new domain attribute deauthorization, that holds 1 in that case. While there correct tb_domain_approve_switch() kernel-doc and description of authorized attribute to mention that it is only about PCIe tunnels. Cc: Christian Kellner <christian@kellner.me> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Diffstat (limited to 'Documentation/admin-guide/thunderbolt.rst')
-rw-r--r--Documentation/admin-guide/thunderbolt.rst16
1 files changed, 16 insertions, 0 deletions
diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst
index 613cb24c76c7..0d4348445f91 100644
--- a/Documentation/admin-guide/thunderbolt.rst
+++ b/Documentation/admin-guide/thunderbolt.rst
@@ -153,6 +153,22 @@ If the user still wants to connect the device they can either approve
the device without a key or write a new key and write 1 to the
``authorized`` file to get the new key stored on the device NVM.
+De-authorizing devices
+----------------------
+It is possible to de-authorize devices by writing ``0`` to their
+``authorized`` attribute. This requires support from the connection
+manager implementation and can be checked by reading domain
+``deauthorization`` attribute. If it reads ``1`` then the feature is
+supported.
+
+When a device is de-authorized the PCIe tunnel from the parent device
+PCIe downstream (or root) port to the device PCIe upstream port is torn
+down. This is essentially the same thing as PCIe hot-remove and the PCIe
+toplogy in question will not be accessible anymore until the device is
+authorized again. If there is storage such as NVMe or similar involved,
+there is a risk for data loss if the filesystem on that storage is not
+properly shut down. You have been warned!
+
DMA protection utilizing IOMMU
------------------------------
Recent systems from 2018 and forward with Thunderbolt ports may natively