thunderbolt: Expose details about tunneling
Subsystems (2)
cover thunderbolt: Expose details about tunneling
Hi all,
There has been ask if we can expose more details about the connected devices and the tunneling to userspace, so it can then provide more detailed information to the user.
This series is not meant to be merged just yet but more like start of a discussion if the information here is enough or we perhaps want to do something differently.
First we add uevent details for each device (USB4 router) that adds USB4_TYPE=host|device|hub and USB4_VERSION=1.0 (if the device actually is USB4). The host|device|hub definitions follow the USB4 spec.
Then for each device router we expose two new attributes: "usb3" and "dp" that if present mean that the device has corresponding adapter (USB 3.x upstream adapter and DP OUT adapter). The contents of the attributes then hold number of tunnels ending to this router. So if USB 3.x is tunneled "usb3" reads 1. Since there can be multiple DP OUT adaptes the "dp" attribute holds number of DP tunnels ending to this router. For PCIe tunneling the "authorized" attribute works the same way.
I'm including the folks who have been working on the userspace side of Thunderbolt in hope to get some feedback whether this is useful approach or perhaps there are better ideas.
Thanks!
Mika Westerberg (3):
thunderbolt: Add details to router uevent
thunderbolt: Hide authorized attribute if router does not support PCIe tunnels
thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
.../ABI/testing/sysfs-bus-thunderbolt | 26 ++++++ drivers/thunderbolt/domain.c | 10 +++ drivers/thunderbolt/switch.c | 90 ++++++++++++++++++- drivers/thunderbolt/tb.c | 49 +++++++--- drivers/thunderbolt/tb.h | 4 + include/linux/thunderbolt.h | 6 ++ 6 files changed, 173 insertions(+), 12 deletions(-)
Signature · 1 line
2.30.1
PATCH 1/3 thunderbolt: Add details to router uevent
Expose two environment variables for routers as part of the initial uevent:
USB4_VERSION=1.0
USB4_TYPE=host|device|hub
Userspace can use this information to expose more details about each connected device. Only USB4 devices have USB4_VERSION but all devices have USB4_TYPE.
--- drivers/thunderbolt/switch.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
drivers/thunderbolt/switch.c +34 -0
@@ -1827,6 +1827,39 @@ static void tb_switch_release(struct device *dev)kfree (sw); } +static int tb_switch_uevent (struct device *dev,struct kobj_uevent_env *env) +{ +struct tb_switch *sw =tb_to_switch (dev); +const char *type; + +if (sw->config.thunderbolt_version ==USB4_VERSION_1_0 ) { +if (add_uevent_var (env,"USB4_VERSION=1.0" )) +return -ENOMEM ; + } + +if (!tb_route (sw)) { + type ="host" ; + }else { +const struct tb_port *port; +bool hub = false; + +/* Device is hub if it has any downstream ports */ +tb_switch_for_each_port (sw, port) { +if (!port->disabled && !tb_is_upstream_port (port) && +tb_port_is_null (port)) { + hub = true; +break ; + } + } + + type = hub ?"hub" :"device" ; + } + +if (add_uevent_var (env,"USB4_TYPE=%s" , type)) +return -ENOMEM ; +return 0 ; +} +/* * Currently only need to provide the callbacks. Everything else is handled * in the connection manager.
@@ -1860,6 +1893,7 @@ static const struct dev_pm_ops tb_switch_pm_ops = {struct device_type tb_switch_type = { .name ="thunderbolt_device" , .release = tb_switch_release, + .uevent = tb_switch_uevent, .pm = &tb_switch_pm_ops, };
Signature · 1 line
2.30.1
Re: [PATCH 1/3] thunderbolt: Add details to router uevent
Quoted 11 lines · Mika Westerberg
Expose two environment variables for routers as part of the initial uevent:
USB4_VERSION=1.0
USB4_TYPE=host|device|hubUserspace can use this information to expose more details about each connected device. Only USB4 devices have
USB4_VERSIONbut all devices haveUSB4_TYPE.Signed-off-by Mika Westerberg <[email protected]>
RE: [PATCH 1/3] thunderbolt: Add details to router uevent
In reply to Mika WesterbergQuoted 12 lines
-----Original Message-----
From: Mika Westerberg <[email protected]>
Sent: Tuesday, March 9, 2021 7:48
To: [email protected]
Cc: Michael Jamet; Yehezkel Bernat; Andreas Noever; Lukas Wunner; Limonciello, Mario; Christian Kellner; Benson Leung; Prashant Malani; Diego Rivas; Greg Kroah-Hartman; Mika Westerberg
Subject: [PATCH 1/3] thunderbolt: Add details to router uevent
Quoted 7 lines
[EXTERNAL EMAIL]
Expose two environment variables for routers as part of the initial uevent:
USB4_VERSION=1.0
USB4_TYPE=host|device|hub
Presumably this will then show up in the uevent like this for a host controller:
DEVTYPE=thunderbolt_device
USB4_VERSION=1.0
USB4_TYPE=host
Since it's specifically for USB4, how about if you instead have new devtypes? TBT3:
DEVTYPE=thunderbolt_device
USB4:
DEVTYPE=usb4_host|usb4_device|usb4_hub
That would at least make it clearer to userspace to make a delineation if it's
legacy device or not. I don't know if that's actually valuable information however.
Quoted 64 lines
Userspace can use this information to expose more details about each connected device. Only USB4 devices have
USB4_VERSIONbut all devices haveUSB4_TYPE.Signed-off-by Mika Westerberg <[email protected]>--- drivers/thunderbolt/switch.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)drivers/thunderbolt/switch.c +34
-1@@ -1827,6 +1827,39 @@ static void tb_switch_release(struct device *dev)kfree (sw); } +static int tb_switch_uevent (struct device *dev,struct kobj_uevent_env *env) +{ +struct tb_switch *sw =tb_to_switch (dev); +const char *type; + +if (sw->config.thunderbolt_version ==USB4_VERSION_1_0 ) { +if (add_uevent_var (env,"USB4_VERSION=1.0" )) +return -ENOMEM ; + } + +if (!tb_route (sw)) { + type ="host" ; + }else { +const struct tb_port *port; +bool hub = false; + +/* Device is hub if it has any downstream ports */ +tb_switch_for_each_port (sw, port) { +if (!port->disabled && !tb_is_upstream_port (port) && +tb_port_is_null (port)) { + hub = true; +break ; + } + } + + type = hub ?"hub" :"device" ; + } + +if (add_uevent_var (env,"USB4_TYPE=%s" , type)) +return -ENOMEM ; +return 0 ; +} +/* * Currently only need to provide the callbacks. Everything else is handled * in the connection manager. @@ -1860,6 +1893,7 @@ static const struct dev_pm_ops tb_switch_pm_ops = {struct device_type tb_switch_type = { .name ="thunderbolt_device" , .release = tb_switch_release, + .uevent = tb_switch_uevent, .pm = &tb_switch_pm_ops, }; --2.30.1
Re: [PATCH 1/3] thunderbolt: Add details to router uevent
Hi Mario,
Quoted 29 lines · Mario
Quoted 12 lines
-----Original Message-----
From: Mika Westerberg <[email protected]>
Sent: Tuesday, March 9, 2021 7:48
To: [email protected]
Cc: Michael Jamet; Yehezkel Bernat; Andreas Noever; Lukas Wunner; Limonciello, Mario; Christian Kellner; Benson Leung; Prashant Malani; Diego Rivas; Greg Kroah-Hartman; Mika Westerberg
Subject: [PATCH 1/3] thunderbolt: Add details to router ueventQuoted 7 lines
[EXTERNAL EMAIL]
Expose two environment variables for routers as part of the initial uevent:
USB4_VERSION=1.0
USB4_TYPE=host|device|hubPresumably this will then show up in the uevent like this for a host controller:
DEVTYPE=thunderbolt_device
USB4_VERSION=1.0
USB4_TYPE=hostSince it's specifically for USB4, how about if you instead have new devtypes? TBT3:
DEVTYPE=thunderbolt_device
Quoted 5 lines
USB4:
DEVTYPE=usb4_host|usb4_device|usb4_hubThat would at least make it clearer to userspace to make a delineation if it's
legacy device or not. I don't know if that's actually valuable information however.
Unfortunately we can't do that. DEVTYPE is generated by the driver core based on the struct device_type we register for routers (switches). Also bolt, and I think fwupd too, already use DEVTYPE to distinguish routers from other devices (like XDomains etc).
PATCH 2/3 thunderbolt: Hide authorized attribute if router does not support PCIe tunnels
In reply to Mika WesterbergWith USB4 devices PCIe tunneling is optional so for device routers without PCIe upstream adapter it does not make much sense to expose the authorized attribute. For this reason hide it if PCIe tunneling is not supported by the device router.
--- drivers/thunderbolt/switch.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/thunderbolt/switch.c +14 -1
@@ -1740,6 +1740,18 @@ static struct attribute *switch_attrs[] = { NULL, }; +static bool has_port (const struct tb_switch *sw,enum tb_port_type type) +{ +const struct tb_port *port; + +tb_switch_for_each_port (sw, port) { +if (!port->disabled && port->config.type == type) +return true; + } + +return false; +} +static umode_t switch_attr_is_visible (struct kobject *kobj,struct attribute *attr,int n) {
@@ -1748,7 +1760,8 @@ static umode_t switch_attr_is_visible(struct kobject *kobj,if (attr == &dev_attr_authorized.attr) {if (sw->tb->security_level ==TB_SECURITY_NOPCIE || - sw->tb->security_level ==TB_SECURITY_DPONLY ) + sw->tb->security_level ==TB_SECURITY_DPONLY || + !has_port (sw,TB_TYPE_PCIE_UP ))return 0 ; }else if (attr == &dev_attr_device.attr) {if (!sw->device)
Signature · 1 line
2.30.1
Re: [PATCH 2/3] thunderbolt: Hide authorized attribute if router does not support PCIe tunnels
Quoted 6 lines · Mika Westerberg
With USB4 devices PCIe tunneling is optional so for device routers without PCIe upstream adapter it does not make much sense to expose the authorized attribute. For this reason hide it if PCIe tunneling is not supported by the device router.
Signed-off-by Mika Westerberg <[email protected]>
PATCH 3/3 thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
In reply to Mika WesterbergThis exposes two new attributes under each device router: usb3 and dp that hold number of tunnels ending to this switch. These attributes are only available if the connection manager supports it (tunneling_details attribute reads 1). Currently only the software connection manager supports this.
Based on these userspace can show the user more detailed information what is going on.
--- .../ABI/testing/sysfs-bus-thunderbolt | 26 ++++++++++ drivers/thunderbolt/domain.c | 10 ++++ drivers/thunderbolt/switch.c | 41 ++++++++++++++++ drivers/thunderbolt/tb.c | 49 ++++++++++++++----- drivers/thunderbolt/tb.h | 4 ++ include/linux/thunderbolt.h | 6 +++ 6 files changed, 125 insertions(+), 11 deletions(-)
Documentation/ABI/testing/sysfs-bus-thunderbolt +26 -0
@@ -61,6 +61,14 @@ Description: This attribute holds current Thunderbolt security level the BIOS. ======= ================================================== +What: /sys/bus/thunderbolt/devices/.../domainX/tunneling_details +Date: July 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: The connection manager implementation may expose + additional details about tunneling. If it supports this + the attribute reads 1. + What: /sys/bus/thunderbolt/devices/.../authorized Date: Sep 2017 KernelVersion: 4.13
@@ -102,6 +110,15 @@ Contact: [email protected] Description: This attribute contains 1 if Thunderbolt device was already authorized on boot and 0 otherwise. +What: /sys/bus/thunderbolt/devices/.../dp +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + DisplayPort sink. Contents will be number how many + active DisplayPort tunnels end up to this router. + What: /sys/bus/thunderbolt/devices/.../generation Date: Jan 2020 KernelVersion: 5.5
@@ -169,6 +186,15 @@ Contact: Mika Westerberg <[email protected]> Description: This attribute reports number of TX lanes the device is using simultaneusly through its upstream port. +What: /sys/bus/thunderbolt/devices/.../usb3 +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + USB 3.x upstream adapter. Reads 1 if there is an active + USB 3.x tunnel to this router. + What: /sys/bus/thunderbolt/devices/.../vendor Date: Sep 2017 KernelVersion: 4.13
drivers/thunderbolt/domain.c +10 -0
@@ -282,11 +282,21 @@ static ssize_t security_show(struct device *dev, struct device_attribute *attr, }static DEVICE_ATTR_RO (security); +static ssize_t tunneling_details_show (struct device *dev, +struct device_attribute *attr,char *buf) +{ + const struct tb *tb = container_of(dev, struct tb, dev); + +return sprintf (buf,"%d\n" , !!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS )); +} +static DEVICE_ATTR_RO (tunneling_details); +static struct attribute *domain_attrs[] = { &dev_attr_boot_acl.attr, &dev_attr_deauthorization.attr, &dev_attr_iommu_dma_protection.attr, &dev_attr_security.attr, + &dev_attr_tunneling_details.attr,NULL , };
drivers/thunderbolt/switch.c +41 -0
83 lines not on this page · raw message
drivers/thunderbolt/tb.c +38 -11
124 lines not on this page · raw message
drivers/thunderbolt/tb.h +4 -0
@@ -123,6 +123,8 @@ struct tb_switch_tmu {* @safe_mode: The switch is in safe-mode * @boot: Whether the switch was already authorized on boot or not * @rpm: The switch supports runtime PM +* @usb3: Number of USB 3.x tunnels to this switch (0 or 1) +* @dp: Number of DisplayPort tunnels ending to this switch * @authorized: Whether the switch is authorized by user or policy * @security_level: Switch supported security level * @debugfs_dir: Pointer to the debugfs structure
@@ -167,6 +169,8 @@ struct tb_switch {bool safe_mode;bool boot;bool rpm; +unsigned int usb3; +unsigned int dp;unsigned int authorized;enum tb_security_level security_level;struct dentry *debugfs_dir;
include/linux/thunderbolt.h +6 -0
@@ -57,6 +57,9 @@ enum tb_security_level { TB_SECURITY_NOPCIE, }; +/* Connection manager exposes details about tunneling */ +#define TB_CAP_TUNNEL_DETAILS BIT(0) +/** * struct tb - main thunderbolt bus structure * @dev: Domain device
@@ -67,6 +70,8 @@ enum tb_security_level {* @wq: Ordered workqueue for all domain specific work * @root_switch: Root switch of this domain * @cm_ops: Connection manager specific operations vector +* @cm_caps: Extra capabilities supported by the connection manager +* implementation * @index: Linux assigned domain number * @security_level: Current security level * @nboot_acl: Number of boot ACLs the domain supports
@@ -80,6 +85,7 @@ struct tb {struct workqueue_struct *wq;struct tb_switch *root_switch;const struct tb_cm_ops *cm_ops; +unsigned int cm_caps;int index;enum tb_security_level security_level;size_t nboot_acl;
Signature · 1 line
2.30.1
Greg Kroah-Hartman
maintainerRe: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 75 lines · Mika Westerberg
This exposes two new attributes under each device router: usb3 and dp that hold number of tunnels ending to this switch. These attributes are only available if the connection manager supports it (
tunneling_detailsattribute reads 1). Currently only the software connection manager supports this.Based on these userspace can show the user more detailed information what is going on.
Signed-off-by Mika Westerberg <[email protected]>--- .../ABI/testing/sysfs-bus-thunderbolt | 26 ++++++++++ drivers/thunderbolt/domain.c | 10 ++++ drivers/thunderbolt/switch.c | 41 ++++++++++++++++ drivers/thunderbolt/tb.c | 49 ++++++++++++++----- drivers/thunderbolt/tb.h | 4 ++ include/linux/thunderbolt.h | 6 +++ 6 files changed, 125 insertions(+), 11 deletions(-)Documentation/ABI/testing/sysfs-bus-thunderbolt +26
-0@@ -61,6 +61,14 @@ Description: This attribute holds current Thunderbolt security level the BIOS. ======= ================================================== +What: /sys/bus/thunderbolt/devices/.../domainX/tunneling_details +Date: July 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: The connection manager implementation may expose + additional details about tunneling. If it supports this + the attribute reads 1. + What: /sys/bus/thunderbolt/devices/.../authorized Date: Sep 2017 KernelVersion: 4.13@@ -102,6 +110,15 @@ Contact: [email protected] Description: This attribute contains 1 if Thunderbolt device was already authorized on boot and 0 otherwise. +What: /sys/bus/thunderbolt/devices/.../dp +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + DisplayPort sink. Contents will be number how many + active DisplayPort tunnels end up to this router. + What: /sys/bus/thunderbolt/devices/.../generation Date: Jan 2020 KernelVersion: 5.5@@ -169,6 +186,15 @@ Contact: Mika Westerberg <[email protected]> Description: This attribute reports number of TX lanes the device is using simultaneusly through its upstream port. +What: /sys/bus/thunderbolt/devices/.../usb3 +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + USB 3.x upstream adapter. Reads 1 if there is an active + USB 3.x tunnel to this router. + What: /sys/bus/thunderbolt/devices/.../vendor Date: Sep 2017 KernelVersion: 4.13drivers/thunderbolt/domain.c +0
-0
drivers/thunderbolt/domain.c static ssize_t security_show(struct device *dev, struct device_attribute *attr, · line 290
Quoted 9 lines
drivers/thunderbolt/domain.c +6
-0@@ -282,11 +282,21 @@ static ssize_t security_show(struct device *dev, struct device_attribute *attr, }static DEVICE_ATTR_RO (security); +static ssize_t tunneling_details_show (struct device *dev, +struct device_attribute *attr,char *buf) +{ + const struct tb *tb = container_of(dev, struct tb, dev); + +return sprintf (buf,"%d\n" , !!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS ));
sysfs_emit() please. For all of these attributes.
Quoted 18 lines
drivers/thunderbolt/domain.c +4
-0+} +static DEVICE_ATTR_RO (tunneling_details); +static struct attribute *domain_attrs[] = { &dev_attr_boot_acl.attr, &dev_attr_deauthorization.attr, &dev_attr_iommu_dma_protection.attr, &dev_attr_security.attr, + &dev_attr_tunneling_details.attr,NULL , };drivers/thunderbolt/switch.c +0
-0@@ -1487,6 +1487,21 @@ device_name_show(struct device *dev, struct device_attribute *attr, char *buf) }
drivers/thunderbolt/switch.c device_name_show(struct device *dev, struct device_attribute *attr, char *buf) · line 1497
Quoted 10 lines
drivers/thunderbolt/switch.c +8
-0static DEVICE_ATTR_RO (device_name); +static ssize_t dp_show (struct device *dev,struct device_attribute *attr, +char *buf) +{ +struct tb_switch *sw =tb_to_switch (dev); +int ret; + +if (!mutex_trylock (&sw->tb->lock)) +return restart_syscall ();
Huh? Why?
drivers/thunderbolt/switch.c device_name_show(struct device *dev, struct device_attribute *attr, char *buf) · line 1499
Quoted 2 lines
drivers/thunderbolt/switch.c +2
-0+ ret =sprintf (buf,"%u\n" , sw->dp); +mutex_unlock (&sw->tb->lock);
Why is the lock needed? It's an attribute, can it change quickly? Can it change at all? What happens if it changes _right_ after you read the value? What happens?
I don't think you need locking here, do you?
Quoted 10 lines
drivers/thunderbolt/switch.c +5
-0+ +return ret; +} +static DEVICE_ATTR_RO (dp); +static ssize_t generation_show (struct device *dev,struct device_attribute *attr,char *buf) {@@ -1693,6 +1708,21 @@ static ssize_t nvm_version_show(struct device *dev, }
drivers/thunderbolt/switch.c static ssize_t nvm_version_show(struct device *dev, · line 1718
Quoted 10 lines
drivers/thunderbolt/switch.c +8
-0static DEVICE_ATTR_RO (nvm_version); +static ssize_t usb3_show (struct device *dev,struct device_attribute *attr, +char *buf) +{ +struct tb_switch *sw =tb_to_switch (dev); +int ret; + +if (!mutex_trylock (&sw->tb->lock)) +return restart_syscall ();
Same here for locking comment.
Quoted 65 lines
drivers/thunderbolt/switch.c +18
-0+ ret =sprintf (buf,"%u\n" , sw->usb3); +mutex_unlock (&sw->tb->lock); + +return ret; +} +static DEVICE_ATTR_RO (usb3); +static ssize_t vendor_show (struct device *dev,struct device_attribute *attr,char *buf) {@@ -1725,6 +1755,7 @@ static struct attribute *switch_attrs[] = { &dev_attr_boot.attr, &dev_attr_device.attr, &dev_attr_device_name.attr, + &dev_attr_dp.attr, &dev_attr_generation.attr, &dev_attr_key.attr, &dev_attr_nvm_authenticate.attr,@@ -1734,6 +1765,7 @@ static struct attribute *switch_attrs[] = { &dev_attr_rx_lanes.attr, &dev_attr_tx_speed.attr, &dev_attr_tx_lanes.attr, + &dev_attr_usb3.attr, &dev_attr_vendor.attr, &dev_attr_vendor_name.attr, &dev_attr_unique_id.attr,@@ -1757,6 +1789,7 @@ static umode_t switch_attr_is_visible(struct kobject *kobj, {struct device *dev =kobj_to_dev (kobj);struct tb_switch *sw =tb_to_switch (dev); +const struct tb *tb = sw->tb;if (attr == &dev_attr_authorized.attr) { if (sw->tb->security_level == TB_SECURITY_NOPCIE ||@@ -1769,6 +1802,10 @@ static umode_t switch_attr_is_visible(struct kobject *kobj, }else if (attr == &dev_attr_device_name.attr) {if (!sw->device_name)return 0 ; + }else if (attr == &dev_attr_dp.attr) { +if (!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS ) || + !has_port (sw,TB_TYPE_DP_HDMI_OUT )) +return 0 ; }else if (attr == &dev_attr_vendor.attr) {if (!sw->vendor)return 0 ;@@ -1788,6 +1825,10 @@ static umode_t switch_attr_is_visible(struct kobject *kobj,if (tb_route (sw))return attr->mode;return 0 ; + }else if (attr == &dev_attr_usb3.attr) { +if (!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS ) || + !has_port (sw,TB_TYPE_USB3_UP )) +return 0 ; }else if (attr == &dev_attr_nvm_authenticate.attr) {if (nvm_upgradeable (sw))return attr->mode;drivers/thunderbolt/tb.c +1
-0@@ -104,10 +104,39 @@ static void tb_remove_dp_resources(struct tb_switch *sw) } } +static void tb_add_tunnel (struct tb *tb,struct tb_tunnel *tunnel)
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 117
Quoted 10 lines
drivers/thunderbolt/tb.c +10
-0+{ +struct tb_switch *sw = tunnel->dst_port->sw; +struct tb_cm *tcm =tb_priv (tb); + +if (tb_tunnel_is_usb3 (tunnel)) { + sw->usb3++; + }else if (tb_tunnel_is_dp (tunnel)) { + sw->dp++; +/* Inform userspace about DP tunneling change */ +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );
What really "changed" here about this device that userspace now needs to know about it?
Quoted 4 lines
drivers/thunderbolt/tb.c +4
-0+ } + +list_add_tail (&tunnel->list, &tcm->tunnel_list); +}
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 131
Quoted 10 lines
drivers/thunderbolt/tb.c +10
-0+ +static void tb_remove_tunnel (struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; + +if (tb_tunnel_is_usb3 (tunnel) && sw->usb3) { + sw->usb3--; + }else if (tb_tunnel_is_dp (tunnel) && sw->dp) { + sw->dp--; +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );
Same here, what causes tunnels to be added or removed?
thanks,
greg k-h
Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Hi Greg,
Quoted 79 lines · Greg Kroah-Hartman
Quoted 78 lines · Mika Westerberg
This exposes two new attributes under each device router: usb3 and dp that hold number of tunnels ending to this switch. These attributes are only available if the connection manager supports it (
tunneling_detailsattribute reads 1). Currently only the software connection manager supports this.Based on these userspace can show the user more detailed information what is going on.
Signed-off-by Mika Westerberg <[email protected]>--- .../ABI/testing/sysfs-bus-thunderbolt | 26 ++++++++++ drivers/thunderbolt/domain.c | 10 ++++ drivers/thunderbolt/switch.c | 41 ++++++++++++++++ drivers/thunderbolt/tb.c | 49 ++++++++++++++----- drivers/thunderbolt/tb.h | 4 ++ include/linux/thunderbolt.h | 6 +++ 6 files changed, 125 insertions(+), 11 deletions(-)Documentation/ABI/testing/sysfs-bus-thunderbolt +26
-0@@ -61,6 +61,14 @@ Description: This attribute holds current Thunderbolt security level the BIOS. ======= ================================================== +What: /sys/bus/thunderbolt/devices/.../domainX/tunneling_details +Date: July 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: The connection manager implementation may expose + additional details about tunneling. If it supports this + the attribute reads 1. + What: /sys/bus/thunderbolt/devices/.../authorized Date: Sep 2017 KernelVersion: 4.13@@ -102,6 +110,15 @@ Contact: [email protected] Description: This attribute contains 1 if Thunderbolt device was already authorized on boot and 0 otherwise. +What: /sys/bus/thunderbolt/devices/.../dp +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + DisplayPort sink. Contents will be number how many + active DisplayPort tunnels end up to this router. + What: /sys/bus/thunderbolt/devices/.../generation Date: Jan 2020 KernelVersion: 5.5@@ -169,6 +186,15 @@ Contact: Mika Westerberg <[email protected]> Description: This attribute reports number of TX lanes the device is using simultaneusly through its upstream port. +What: /sys/bus/thunderbolt/devices/.../usb3 +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + USB 3.x upstream adapter. Reads 1 if there is an active + USB 3.x tunnel to this router. + What: /sys/bus/thunderbolt/devices/.../vendor Date: Sep 2017 KernelVersion: 4.13drivers/thunderbolt/domain.c +0
-0@@ -282,11 +282,21 @@ static ssize_t security_show(struct device *dev, struct device_attribute *attr, }static DEVICE_ATTR_RO (security);
Quoted 8 lines
drivers/thunderbolt/domain.c static ssize_t security_show(struct device *dev, struct device_attribute *attr, · line 290
Quoted 6 lines
drivers/thunderbolt/domain.c +6
-0+static ssize_t tunneling_details_show (struct device *dev, +struct device_attribute *attr,char *buf) +{ + const struct tb *tb = container_of(dev, struct tb, dev); + +return sprintf (buf,"%d\n" , !!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS ));
sysfs_emit()please. For all of these attributes.
Sure.
Quoted 20 lines
Quoted 20 lines
drivers/thunderbolt/domain.c +4
-0+} +static DEVICE_ATTR_RO (tunneling_details); +static struct attribute *domain_attrs[] = { &dev_attr_boot_acl.attr, &dev_attr_deauthorization.attr, &dev_attr_iommu_dma_protection.attr, &dev_attr_security.attr, + &dev_attr_tunneling_details.attr,NULL , };drivers/thunderbolt/switch.c +0
-0@@ -1487,6 +1487,21 @@ device_name_show(struct device *dev, struct device_attribute *attr, char *buf) }static DEVICE_ATTR_RO (device_name);
Quoted 10 lines
drivers/thunderbolt/switch.c device_name_show(struct device *dev, struct device_attribute *attr, char *buf) · line 1497
Quoted 8 lines
drivers/thunderbolt/switch.c +8
-0+static ssize_t dp_show (struct device *dev,struct device_attribute *attr, +char *buf) +{ +struct tb_switch *sw =tb_to_switch (dev); +int ret; + +if (!mutex_trylock (&sw->tb->lock)) +return restart_syscall ();Huh? Why?
This was copied from another attribute but not needed here as you point out.
Quoted 6 lines
drivers/thunderbolt/switch.c device_name_show(struct device *dev, struct device_attribute *attr, char *buf) · line 1499
Quoted 2 lines
drivers/thunderbolt/switch.c +2
-0+ ret =sprintf (buf,"%u\n" , sw->dp); +mutex_unlock (&sw->tb->lock);Why is the lock needed? It's an attribute, can it change quickly? Can it change at all? What happens if it changes _right_ after you read the value? What happens?
This particular attribute can change dynamically as DisplayPort tunnels are created/torn down based on user action plugging in monitor.
Quoted 1 line
I don't think you need locking here, do you?
I agree, no need for locking here.
Quoted 12 lines
Quoted 12 lines
drivers/thunderbolt/switch.c +5
-0+ +return ret; +} +static DEVICE_ATTR_RO (dp); +static ssize_t generation_show (struct device *dev,struct device_attribute *attr,char *buf) {@@ -1693,6 +1708,21 @@ static ssize_t nvm_version_show(struct device *dev, }static DEVICE_ATTR_RO (nvm_version);
Quoted 10 lines
drivers/thunderbolt/switch.c static ssize_t nvm_version_show(struct device *dev, · line 1718
Quoted 8 lines
drivers/thunderbolt/switch.c +8
-0+static ssize_t usb3_show (struct device *dev,struct device_attribute *attr, +char *buf) +{ +struct tb_switch *sw =tb_to_switch (dev); +int ret; + +if (!mutex_trylock (&sw->tb->lock)) +return restart_syscall ();Same here for locking comment.
OK.
Quoted 64 lines
Quoted 64 lines
drivers/thunderbolt/switch.c +18
-0+ ret =sprintf (buf,"%u\n" , sw->usb3); +mutex_unlock (&sw->tb->lock); + +return ret; +} +static DEVICE_ATTR_RO (usb3); +static ssize_t vendor_show (struct device *dev,struct device_attribute *attr,char *buf) {@@ -1725,6 +1755,7 @@ static struct attribute *switch_attrs[] = { &dev_attr_boot.attr, &dev_attr_device.attr, &dev_attr_device_name.attr, + &dev_attr_dp.attr, &dev_attr_generation.attr, &dev_attr_key.attr, &dev_attr_nvm_authenticate.attr,@@ -1734,6 +1765,7 @@ static struct attribute *switch_attrs[] = { &dev_attr_rx_lanes.attr, &dev_attr_tx_speed.attr, &dev_attr_tx_lanes.attr, + &dev_attr_usb3.attr, &dev_attr_vendor.attr, &dev_attr_vendor_name.attr, &dev_attr_unique_id.attr,@@ -1757,6 +1789,7 @@ static umode_t switch_attr_is_visible(struct kobject *kobj, {struct device *dev =kobj_to_dev (kobj);struct tb_switch *sw =tb_to_switch (dev); +const struct tb *tb = sw->tb;if (attr == &dev_attr_authorized.attr) { if (sw->tb->security_level == TB_SECURITY_NOPCIE ||@@ -1769,6 +1802,10 @@ static umode_t switch_attr_is_visible(struct kobject *kobj, }else if (attr == &dev_attr_device_name.attr) {if (!sw->device_name)return 0 ; + }else if (attr == &dev_attr_dp.attr) { +if (!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS ) || + !has_port (sw,TB_TYPE_DP_HDMI_OUT )) +return 0 ; }else if (attr == &dev_attr_vendor.attr) {if (!sw->vendor)return 0 ;@@ -1788,6 +1825,10 @@ static umode_t switch_attr_is_visible(struct kobject *kobj,if (tb_route (sw))return attr->mode;return 0 ; + }else if (attr == &dev_attr_usb3.attr) { +if (!(tb->cm_caps &TB_CAP_TUNNEL_DETAILS ) || + !has_port (sw,TB_TYPE_USB3_UP )) +return 0 ; }else if (attr == &dev_attr_nvm_authenticate.attr) {if (nvm_upgradeable (sw))return attr->mode;drivers/thunderbolt/tb.c +0
-0@@ -104,10 +104,39 @@ static void tb_remove_dp_resources(struct tb_switch *sw) } }
Quoted 14 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 117
Quoted 11 lines
drivers/thunderbolt/tb.c +11
-0+static void tb_add_tunnel (struct tb *tb,struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; +struct tb_cm *tcm =tb_priv (tb); + +if (tb_tunnel_is_usb3 (tunnel)) { + sw->usb3++; + }else if (tb_tunnel_is_dp (tunnel)) { + sw->dp++; +/* Inform userspace about DP tunneling change */ +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );What really "changed" here about this device that userspace now needs to know about it?
DisplayPort tunnel came up, so the "dp" attribute value changed.
I'm not entirely sure we need to notify the userspace from changes like these, though. We do this when PCIe tunnel comes up already so this kind of follows that (and USB 3.x tunnel is always created at the same time the device itself is announced so does not require any change event).
Quoted 8 lines
Quoted 8 lines
drivers/thunderbolt/tb.c +8
-0+ } + +list_add_tail (&tunnel->list, &tcm->tunnel_list); +} + +static void tb_remove_tunnel (struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw;
Quoted 8 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 131
Quoted 6 lines
drivers/thunderbolt/tb.c +6
-0+ +if (tb_tunnel_is_usb3 (tunnel) && sw->usb3) { + sw->usb3--; + }else if (tb_tunnel_is_dp (tunnel) && sw->dp) { + sw->dp--; +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );Same here, what causes tunnels to be added or removed?
Here the opposite, a DisplayPort tunnel was torn down so the "dp" attribute changed.
Greg Kroah-Hartman
maintainerRe: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 39 lines · Mika Westerberg
Quoted 6 lines
Quoted 6 lines
drivers/thunderbolt/tb.c +6
-0+static void tb_add_tunnel (struct tb *tb,struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; +struct tb_cm *tcm =tb_priv (tb); + +if (tb_tunnel_is_usb3 (tunnel)) {Quoted 8 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 117
Quoted 5 lines
drivers/thunderbolt/tb.c +5
-0+ sw->usb3++; + }else if (tb_tunnel_is_dp (tunnel)) { + sw->dp++; +/* Inform userspace about DP tunneling change */ +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );What really "changed" here about this device that userspace now needs to know about it?
DisplayPort tunnel came up, so the "dp" attribute value changed.
I'm not entirely sure we need to notify the userspace from changes like these, though. We do this when PCIe tunnel comes up already so this kind of follows that (and USB 3.x tunnel is always created at the same time the device itself is announced so does not require any change event).
Quoted 8 lines
Quoted 8 lines
drivers/thunderbolt/tb.c +8
-0+ } + +list_add_tail (&tunnel->list, &tcm->tunnel_list); +} + +static void tb_remove_tunnel (struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw;Quoted 8 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 131
Quoted 6 lines
drivers/thunderbolt/tb.c +6
-0+ +if (tb_tunnel_is_usb3 (tunnel) && sw->usb3) { + sw->usb3--; + }else if (tb_tunnel_is_dp (tunnel) && sw->dp) { + sw->dp--; +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );Same here, what causes tunnels to be added or removed?
Quoted 2 lines
Here the opposite, a DisplayPort tunnel was torn down so the "dp" attribute changed.
Did just the value in the attribute change, or did the visability of attributes change?
And if it is just the value, who is going to care about this value? Is userspace going to want to know this type of change? What causes this to change in the first place (physical event? Virtual event? Something else?)
thanks,
greg k-h
Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Hi,
Quoted 40 lines · Greg Kroah-Hartman
Quoted 39 lines · Mika Westerberg
Quoted 6 lines
Quoted 6 lines
drivers/thunderbolt/tb.c +6
-0+static void tb_add_tunnel (struct tb *tb,struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; +struct tb_cm *tcm =tb_priv (tb); + +if (tb_tunnel_is_usb3 (tunnel)) {Quoted 8 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 117
Quoted 5 lines
drivers/thunderbolt/tb.c +5
-0+ sw->usb3++; + }else if (tb_tunnel_is_dp (tunnel)) { + sw->dp++; +/* Inform userspace about DP tunneling change */ +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );What really "changed" here about this device that userspace now needs to know about it?
DisplayPort tunnel came up, so the "dp" attribute value changed.
I'm not entirely sure we need to notify the userspace from changes like these, though. We do this when PCIe tunnel comes up already so this kind of follows that (and USB 3.x tunnel is always created at the same time the device itself is announced so does not require any change event).
Quoted 16 lines
Quoted 4 lines
drivers/thunderbolt/tb.c +4
-0+ } + +list_add_tail (&tunnel->list, &tcm->tunnel_list); +}drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 131
Quoted 10 lines
drivers/thunderbolt/tb.c +10
-0+ +static void tb_remove_tunnel (struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; + +if (tb_tunnel_is_usb3 (tunnel) && sw->usb3) { + sw->usb3--; + }else if (tb_tunnel_is_dp (tunnel) && sw->dp) { + sw->dp--; +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );Same here, what causes tunnels to be added or removed?
Quoted 5 lines
Quoted 2 lines
Here the opposite, a DisplayPort tunnel was torn down so the "dp" attribute changed.
Did just the value in the attribute change, or did the visability of attributes change?
The value changes.
Quoted 4 lines
And if it is just the value, who is going to care about this value? Is userspace going to want to know this type of change? What causes this to change in the first place (physical event? Virtual event? Something else?)
It is physical event. Typically this happens when user plugs a monitor to a Thunderbolt dock, or plugs it out. This value changes accordingly.
The caring part is the userspace application, I think bolt in case of non-ChromeOS distro and the ChromeOS equivalent but I'm not sure if this is something they find useful or not. That's why I have Cc'd (hopefully all) the people who work with the userspace side :)
Greg Kroah-Hartman
maintainerRe: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 51 lines · Mika Westerberg
Hi,
Quoted 40 lines · Greg Kroah-Hartman
Quoted 39 lines · Mika Westerberg
Quoted 6 lines
Quoted 6 lines
drivers/thunderbolt/tb.c +6
-0+static void tb_add_tunnel (struct tb *tb,struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; +struct tb_cm *tcm =tb_priv (tb); + +if (tb_tunnel_is_usb3 (tunnel)) {Quoted 8 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 117
Quoted 5 lines
drivers/thunderbolt/tb.c +5
-0+ sw->usb3++; + }else if (tb_tunnel_is_dp (tunnel)) { + sw->dp++; +/* Inform userspace about DP tunneling change */ +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );What really "changed" here about this device that userspace now needs to know about it?
DisplayPort tunnel came up, so the "dp" attribute value changed.
I'm not entirely sure we need to notify the userspace from changes like these, though. We do this when PCIe tunnel comes up already so this kind of follows that (and USB 3.x tunnel is always created at the same time the device itself is announced so does not require any change event).
Quoted 16 lines
Quoted 4 lines
drivers/thunderbolt/tb.c +4
-0+ } + +list_add_tail (&tunnel->list, &tcm->tunnel_list); +}drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 131
Quoted 10 lines
drivers/thunderbolt/tb.c +10
-0+ +static void tb_remove_tunnel (struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; + +if (tb_tunnel_is_usb3 (tunnel) && sw->usb3) { + sw->usb3--; + }else if (tb_tunnel_is_dp (tunnel) && sw->dp) { + sw->dp--; +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );Same here, what causes tunnels to be added or removed?
Quoted 5 lines
Quoted 2 lines
Here the opposite, a DisplayPort tunnel was torn down so the "dp" attribute changed.
Did just the value in the attribute change, or did the visability of attributes change?
The value changes.
Quoted 7 lines
Quoted 4 lines
And if it is just the value, who is going to care about this value? Is userspace going to want to know this type of change? What causes this to change in the first place (physical event? Virtual event? Something else?)
It is physical event. Typically this happens when user plugs a monitor to a Thunderbolt dock, or plugs it out. This value changes accordingly.
So are there other events that show up to userspace when this happens? Like devices added/removed? If so, then sending a kobject change event here doesn't make much sense as userspace can go re-read this based on the fact that other things changed.
Quoted 4 lines
The caring part is the userspace application, I think bolt in case of non-ChromeOS distro and the ChromeOS equivalent but I'm not sure if this is something they find useful or not. That's why I have Cc'd (hopefully all) the people who work with the userspace side :)
What userspace apps read this file today in any Linux distro?
thanks,
greg k-h
Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Mika Westerberg
Hi,
Quoted 40 lines · Greg Kroah-Hartman
Quoted 39 lines · Mika Westerberg
Quoted 6 lines
Quoted 6 lines
drivers/thunderbolt/tb.c +6
-0+static void tb_add_tunnel (struct tb *tb,struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; +struct tb_cm *tcm =tb_priv (tb); + +if (tb_tunnel_is_usb3 (tunnel)) {Quoted 8 lines
drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 117
Quoted 5 lines
drivers/thunderbolt/tb.c +5
-0+ sw->usb3++; + }else if (tb_tunnel_is_dp (tunnel)) { + sw->dp++; +/* Inform userspace about DP tunneling change */ +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );What really "changed" here about this device that userspace now needs to know about it?
DisplayPort tunnel came up, so the "dp" attribute value changed.
I'm not entirely sure we need to notify the userspace from changes like these, though. We do this when PCIe tunnel comes up already so this kind of follows that (and USB 3.x tunnel is always created at the same time the device itself is announced so does not require any change event).
Quoted 16 lines
Quoted 4 lines
drivers/thunderbolt/tb.c +4
-0+ } + +list_add_tail (&tunnel->list, &tcm->tunnel_list); +}drivers/thunderbolt/tb.c static void tb_remove_dp_resources(struct tb_switch *sw) · line 131
Quoted 10 lines
drivers/thunderbolt/tb.c +10
-0+ +static void tb_remove_tunnel (struct tb_tunnel *tunnel) +{ +struct tb_switch *sw = tunnel->dst_port->sw; + +if (tb_tunnel_is_usb3 (tunnel) && sw->usb3) { + sw->usb3--; + }else if (tb_tunnel_is_dp (tunnel) && sw->dp) { + sw->dp--; +kobject_uevent (&sw->dev.kobj,KOBJ_CHANGE );Same here, what causes tunnels to be added or removed?
Quoted 5 lines
Quoted 2 lines
Here the opposite, a DisplayPort tunnel was torn down so the "dp" attribute changed.
Did just the value in the attribute change, or did the visability of attributes change?
The value changes.
Quoted 4 lines
And if it is just the value, who is going to care about this value? Is userspace going to want to know this type of change? What causes this to change in the first place (physical event? Virtual event? Something else?)
Quoted 7 lines
Quoted 2 lines
It is physical event. Typically this happens when user plugs a monitor to a Thunderbolt dock, or plugs it out. This value changes accordingly.
So are there other events that show up to userspace when this happens? Like devices added/removed? If so, then sending a kobject change event here doesn't make much sense as userspace can go re-read this based on the fact that other things changed.
From Thunderbolt driver side in this event (monitor plugged in/out) there are no new devices added or removed. It all happens to the device that already exists (the dock for instance).
Quoted 6 lines
Quoted 4 lines
The caring part is the userspace application, I think bolt in case of non-ChromeOS distro and the ChromeOS equivalent but I'm not sure if this is something they find useful or not. That's why I have Cc'd (hopefully all) the people who work with the userspace side :)
What userspace apps read this file today in any Linux distro?
None at the moment. This is completely new attribute.
RE: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 87 lines
-----Original Message-----
From: Mika Westerberg <[email protected]>
Sent: Wednesday, March 10, 2021 3:40
To: Greg Kroah-Hartman
Cc: [email protected]; Michael Jamet; Yehezkel Bernat; Andreas Noever; Lukas Wunner; Limonciello, Mario; Christian Kellner; Benson Leung; Prashant Malani; Diego Rivas
Subject: Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels[EXTERNAL EMAIL]
Quoted 6 lines · Greg Kroah-Hartman
Quoted 5 lines · Mika Westerberg
Hi,
Quoted 2 lines · Greg Kroah-Hartman
Quoted 1 line · Mika Westerberg
Quoted 1 line
Quoted 1 line
+static void tb_add_tunnel(struct tb *tb, struct
tb_tunnel*tunnel)
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
(quoted diff) +4
-0+{ + struct tb_switch *sw = tunnel->dst_port->sw; + struct tb_cm *tcm = tb_priv(tb); +Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+ if (tb_tunnel_is_usb3(tunnel)) { + sw->usb3++; + } else if (tb_tunnel_is_dp(tunnel)) { + sw->dp++; + /* Inform userspace about DP tunneling change */ + kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE);What really "changed" here about this device that userspace now
needs to
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
know about it?
DisplayPort tunnel came up, so the "dp" attribute value changed.
I'm not entirely sure we need to notify the userspace from changes
like
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
these, though. We do this when PCIe tunnel comes up already so this
kind
Quoted 33 lines
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
of follows that (and USB 3.x tunnel is always created at the same time the device itself is announced so does not require any change event).
Quoted 16 lines
Quoted 4 lines
(quoted diff) +4
-0+ } + + list_add_tail(&tunnel->list, &tcm->tunnel_list); +}Review
Quoted 10 lines
(quoted diff) +10
-0+ +static void tb_remove_tunnel(struct tb_tunnel *tunnel) +{ + struct tb_switch *sw = tunnel->dst_port->sw; + + if (tb_tunnel_is_usb3(tunnel) && sw->usb3) { + sw->usb3--; + } else if (tb_tunnel_is_dp(tunnel) && sw->dp) { + sw->dp--; + kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE);Same here, what causes tunnels to be added or removed?
Quoted 5 lines
Quoted 2 lines
Here the opposite, a DisplayPort tunnel was torn down so the "dp" attribute changed.
Did just the value in the attribute change, or did the visability of attributes change?
The value changes.
Quoted 4 lines
And if it is just the value, who is going to care about this value? Is userspace going to want to know this type of change? What causes this to change in the first place (physical event? Virtual event? Something else?)
Quoted 7 lines
Quoted 2 lines
It is physical event. Typically this happens when user plugs a monitor to a Thunderbolt dock, or plugs it out. This value changes accordingly.
So are there other events that show up to userspace when this happens? Like devices added/removed? If so, then sending a kobject change event here doesn't make much sense as userspace can go re-read this based on the fact that other things changed.
From Thunderbolt driver side in this event (monitor plugged in/out) there are no new devices added or removed. It all happens to the device that already exists (the dock for instance).
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
The caring part is the userspace application, I think bolt in case of non-ChromeOS distro and the ChromeOS equivalent but I'm not sure if this is something they find useful or not. That's why I have Cc'd (hopefully all) the people who work with the userspace side :)
What userspace apps read this file today in any Linux distro?
None at the moment. This is completely new attribute.
In practice software based connection manager isn't in any production system in the field today and these attributes are to determine what sort of useful information userspace can obtain and make messaging or let user's make decisions.
For example you might envision "at some point" you might let a user configure a policy to prefer to allocate bandwidth to certain types of devices, but to enact that policy you'll need to know everything that is connected.
Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 2 lines · Mario
In practice software based connection manager isn't in any production system in the field today
... except everything Apple.
RE: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 11 lines
-----Original Message-----
From: Lukas Wunner <[email protected]>
Sent: Wednesday, March 10, 2021 12:50
To: Limonciello, Mario
Cc: Mika Westerberg; Greg Kroah-Hartman; [email protected]; Michael Jamet; Yehezkel Bernat; Andreas Noever; Christian Kellner; Benson Leung; Prashant Malani; Diego Rivas
Subject: Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Quoted 7 lines
[EXTERNAL EMAIL]
Quoted 2 lines · Mario
In practice software based connection manager isn't in any production system in the field today
... except everything Apple.
I was referring to USB4 products... but yeah you're right.
Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
In reply to Mika WesterbergHi Benson, Prashant, Diego, Christian and Mario (and others who may be interested)
Quoted 17 lines · Mika Westerberg
(quoted diff) +16
-0+What: /sys/bus/thunderbolt/devices/.../domainX/tunneling_details +Date: July 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: The connection manager implementation may expose + additional details about tunneling. If it supports this + the attribute reads 1. + +What: /sys/bus/thunderbolt/devices/.../dp +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + DisplayPort sink. Contents will be number how many + active DisplayPort tunnels end up to this router.
Review
Quoted 10 lines
(quoted diff) +9
-0+ +What: /sys/bus/thunderbolt/devices/.../usb3 +Date: Jul 2021 +KernelVersion: 5.13 +Contact: Mika Westerberg <[email protected]> +Description: Only available if the domain tunneling_details attribute + reads 1. If present means that the device router has + USB 3.x upstream adapter. Reads 1 if there is an active + USB 3.x tunnel to this router.
Do you think these attributes help the userspace at all? I mean if you think they are not usable as is we can consider some alternatives too. I was going to drop the KOBJ_CHANGE event (and the unnecessary locking) from v2 but before sending a new version, I would like to get some feedback if this is even needed.
Thanks!