| Message ID | 20210309134818.63118-4-mika.westerberg@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | thunderbolt: Expose details about tunneling | expand |
On Tue, Mar 09, 2021 at 04:48:18PM +0300, Mika Westerberg wrote: > 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_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. > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > --- > .../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(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt > index c41c68f64693..1569be391ca6 100644 > --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt > +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt > @@ -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 <mika.westerberg@linux.intel.com> > +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: thunderbolt-software@lists.01.org > 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 <mika.westerberg@linux.intel.com> > +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 <mika.westerberg@linux.intel.com> > 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 <mika.westerberg@linux.intel.com> > +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 > diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c > index a7d83eec3d15..3a1fb7a39f90 100644 > --- a/drivers/thunderbolt/domain.c > +++ b/drivers/thunderbolt/domain.c > @@ -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. > +} > +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, > }; > > diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c > index e73cd296db7e..b72589eabf0c 100644 > --- a/drivers/thunderbolt/switch.c > +++ b/drivers/thunderbolt/switch.c > @@ -1487,6 +1487,21 @@ device_name_show(struct device *dev, struct device_attribute *attr, char *buf) > } > static 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? > + 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? > + > + 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); > > +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. > + 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; > diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c > index 7e6dc2b03bed..32b79dce134f 100644 > --- a/drivers/thunderbolt/tb.c > +++ b/drivers/thunderbolt/tb.c > @@ -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) > +{ > + 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? > + } > + > + 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; > + > + 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
Hi Greg, On Tue, Mar 09, 2021 at 03:09:59PM +0100, Greg Kroah-Hartman wrote: > On Tue, Mar 09, 2021 at 04:48:18PM +0300, Mika Westerberg wrote: > > 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_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. > > > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > --- > > .../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(-) > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt > > index c41c68f64693..1569be391ca6 100644 > > --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt > > +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt > > @@ -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 <mika.westerberg@linux.intel.com> > > +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: thunderbolt-software@lists.01.org > > 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 <mika.westerberg@linux.intel.com> > > +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 <mika.westerberg@linux.intel.com> > > 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 <mika.westerberg@linux.intel.com> > > +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 > > diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c > > index a7d83eec3d15..3a1fb7a39f90 100644 > > --- a/drivers/thunderbolt/domain.c > > +++ b/drivers/thunderbolt/domain.c > > @@ -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. Sure. > > +} > > +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, > > }; > > > > diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c > > index e73cd296db7e..b72589eabf0c 100644 > > --- a/drivers/thunderbolt/switch.c > > +++ b/drivers/thunderbolt/switch.c > > @@ -1487,6 +1487,21 @@ device_name_show(struct device *dev, struct device_attribute *attr, char *buf) > > } > > static 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? This was copied from another attribute but not needed here as you point out. > > + 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. > I don't think you need locking here, do you? I agree, no need for locking here. > > + > > + 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); > > > > +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. > > + 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; > > diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c > > index 7e6dc2b03bed..32b79dce134f 100644 > > --- a/drivers/thunderbolt/tb.c > > +++ b/drivers/thunderbolt/tb.c > > @@ -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) > > +{ > > + 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). > > + } > > + > > + 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; > > + > > + 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.
On Wed, Mar 10, 2021 at 09:54:44AM +0200, Mika Westerberg wrote: > > > +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). > > > > + } > > > + > > > + 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; > > > + > > > + 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. 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
Hi, On Wed, Mar 10, 2021 at 09:53:31AM +0100, Greg Kroah-Hartman wrote: > On Wed, Mar 10, 2021 at 09:54:44AM +0200, Mika Westerberg wrote: > > > > +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). > > > > > > + } > > > > + > > > > + 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; > > > > + > > > > + 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. > > Did just the value in the attribute change, or did the visability of > attributes change? The value changes. > 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 :)
On Wed, Mar 10, 2021 at 11:21:55AM +0200, Mika Westerberg wrote: > Hi, > > On Wed, Mar 10, 2021 at 09:53:31AM +0100, Greg Kroah-Hartman wrote: > > On Wed, Mar 10, 2021 at 09:54:44AM +0200, Mika Westerberg wrote: > > > > > +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). > > > > > > > > + } > > > > > + > > > > > + 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; > > > > > + > > > > > + 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. > > > > Did just the value in the attribute change, or did the visability of > > attributes change? > > The value changes. > > > 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. > 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
On Wed, Mar 10, 2021 at 10:34:38AM +0100, Greg Kroah-Hartman wrote: > On Wed, Mar 10, 2021 at 11:21:55AM +0200, Mika Westerberg wrote: > > Hi, > > > > On Wed, Mar 10, 2021 at 09:53:31AM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Mar 10, 2021 at 09:54:44AM +0200, Mika Westerberg wrote: > > > > > > +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). > > > > > > > > > > + } > > > > > > + > > > > > > + 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; > > > > > > + > > > > > > + 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. > > > > > > Did just the value in the attribute change, or did the visability of > > > attributes change? > > > > The value changes. > > > > > 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. 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). > > 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.
> -----Original Message----- > From: Mika Westerberg <mika.westerberg@linux.intel.com> > Sent: Wednesday, March 10, 2021 3:40 > To: Greg Kroah-Hartman > Cc: linux-usb@vger.kernel.org; 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] > > On Wed, Mar 10, 2021 at 10:34:38AM +0100, Greg Kroah-Hartman wrote: > > On Wed, Mar 10, 2021 at 11:21:55AM +0200, Mika Westerberg wrote: > > > Hi, > > > > > > On Wed, Mar 10, 2021 at 09:53:31AM +0100, Greg Kroah-Hartman wrote: > > > > On Wed, Mar 10, 2021 at 09:54:44AM +0200, Mika Westerberg wrote: > > > > > > > +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). > > > > > > > > > > > > + } > > > > > > > + > > > > > > > + 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; > > > > > > > + > > > > > > > + 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. > > > > > > > > Did just the value in the attribute change, or did the visability of > > > > attributes change? > > > > > > The value changes. > > > > > > > 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. > > 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). > > > > 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.
On Wed, Mar 10, 2021 at 04:24:20PM +0000, Limonciello, Mario wrote: > In practice software based connection manager isn't in any production > system in the field today ... except everything Apple.
> -----Original Message----- > From: Lukas Wunner <lukas@wunner.de> > Sent: Wednesday, March 10, 2021 12:50 > To: Limonciello, Mario > Cc: Mika Westerberg; Greg Kroah-Hartman; linux-usb@vger.kernel.org; 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 > > > [EXTERNAL EMAIL] > > On Wed, Mar 10, 2021 at 04:24:20PM +0000, Limonciello, Mario wrote: > > 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.
Hi Benson, Prashant, Diego, Christian and Mario (and others who may be interested) On Tue, Mar 09, 2021 at 04:48:18PM +0300, Mika Westerberg wrote: > +What: /sys/bus/thunderbolt/devices/.../domainX/tunneling_details > +Date: July 2021 > +KernelVersion: 5.13 > +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> > +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 <mika.westerberg@linux.intel.com> > +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/.../usb3 > +Date: Jul 2021 > +KernelVersion: 5.13 > +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> > +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!
diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index c41c68f64693..1569be391ca6 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -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 <mika.westerberg@linux.intel.com> +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: thunderbolt-software@lists.01.org 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 <mika.westerberg@linux.intel.com> +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 <mika.westerberg@linux.intel.com> 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 <mika.westerberg@linux.intel.com> +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 diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c index a7d83eec3d15..3a1fb7a39f90 100644 --- a/drivers/thunderbolt/domain.c +++ b/drivers/thunderbolt/domain.c @@ -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, }; diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c index e73cd296db7e..b72589eabf0c 100644 --- a/drivers/thunderbolt/switch.c +++ b/drivers/thunderbolt/switch.c @@ -1487,6 +1487,21 @@ device_name_show(struct device *dev, struct device_attribute *attr, char *buf) } static 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(); + ret = sprintf(buf, "%u\n", sw->dp); + mutex_unlock(&sw->tb->lock); + + 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); +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(); + 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; diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c index 7e6dc2b03bed..32b79dce134f 100644 --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -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) +{ + 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); + } + + 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; + + 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); + } + + list_del(&tunnel->list); +} + static void tb_discover_tunnels(struct tb_switch *sw) { struct tb *tb = sw->tb; - struct tb_cm *tcm = tb_priv(tb); struct tb_port *port; tb_switch_for_each_port(sw, port) { @@ -146,7 +175,7 @@ static void tb_discover_tunnels(struct tb_switch *sw) pm_runtime_get_sync(&tunnel->dst_port->sw->dev); } - list_add_tail(&tunnel->list, &tcm->tunnel_list); + tb_add_tunnel(tb, tunnel); } tb_switch_for_each_port(sw, port) { @@ -440,7 +469,6 @@ static int tb_tunnel_usb3(struct tb *tb, struct tb_switch *sw) struct tb_switch *parent = tb_switch_parent(sw); int ret, available_up, available_down; struct tb_port *up, *down, *port; - struct tb_cm *tcm = tb_priv(tb); struct tb_tunnel *tunnel; if (!tb_acpi_may_tunnel_usb3()) { @@ -503,7 +531,7 @@ static int tb_tunnel_usb3(struct tb *tb, struct tb_switch *sw) goto err_free; } - list_add_tail(&tunnel->list, &tcm->tunnel_list); + tb_add_tunnel(tb, tunnel); if (tb_route(parent)) tb_reclaim_usb3_bandwidth(tb, down, up); @@ -686,7 +714,7 @@ static void tb_deactivate_and_free_tunnel(struct tb_tunnel *tunnel) return; tb_tunnel_deactivate(tunnel); - list_del(&tunnel->list); + tb_remove_tunnel(tunnel); tb = tunnel->tb; src_port = tunnel->src_port; @@ -937,7 +965,7 @@ static void tb_tunnel_dp(struct tb *tb) goto err_free; } - list_add_tail(&tunnel->list, &tcm->tunnel_list); + tb_add_tunnel(tb, tunnel); tb_reclaim_usb3_bandwidth(tb, in, out); return; @@ -1038,7 +1066,7 @@ static int tb_disconnect_pci(struct tb *tb, struct tb_switch *sw) return -ENODEV; tb_tunnel_deactivate(tunnel); - list_del(&tunnel->list); + tb_remove_tunnel(tunnel); tb_tunnel_free(tunnel); return 0; } @@ -1046,7 +1074,6 @@ static int tb_disconnect_pci(struct tb *tb, struct tb_switch *sw) static int tb_tunnel_pci(struct tb *tb, struct tb_switch *sw) { struct tb_port *up, *down, *port; - struct tb_cm *tcm = tb_priv(tb); struct tb_switch *parent_sw; struct tb_tunnel *tunnel; @@ -1075,7 +1102,7 @@ static int tb_tunnel_pci(struct tb *tb, struct tb_switch *sw) return -EIO; } - list_add_tail(&tunnel->list, &tcm->tunnel_list); + tb_add_tunnel(tb, tunnel); return 0; } @@ -1083,7 +1110,6 @@ static int tb_approve_xdomain_paths(struct tb *tb, struct tb_xdomain *xd, int transmit_path, int transmit_ring, int receive_path, int receive_ring) { - struct tb_cm *tcm = tb_priv(tb); struct tb_port *nhi_port, *dst_port; struct tb_tunnel *tunnel; struct tb_switch *sw; @@ -1108,7 +1134,7 @@ static int tb_approve_xdomain_paths(struct tb *tb, struct tb_xdomain *xd, return -EIO; } - list_add_tail(&tunnel->list, &tcm->tunnel_list); + tb_add_tunnel(tb, tunnel); mutex_unlock(&tb->lock); return 0; } @@ -1586,6 +1612,7 @@ struct tb *tb_probe(struct tb_nhi *nhi) tb->security_level = TB_SECURITY_NOPCIE; tb->cm_ops = &tb_cm_ops; + tb->cm_caps |= TB_CAP_TUNNEL_DETAILS; tcm = tb_priv(tb); INIT_LIST_HEAD(&tcm->tunnel_list); diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h index 2af6d632e3d0..b4bc656a06b6 100644 --- a/drivers/thunderbolt/tb.h +++ b/drivers/thunderbolt/tb.h @@ -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; diff --git a/include/linux/thunderbolt.h b/include/linux/thunderbolt.h index e7c96c37174f..dc6cfb4237d1 100644 --- a/include/linux/thunderbolt.h +++ b/include/linux/thunderbolt.h @@ -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;
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_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. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> --- .../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(-)