> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
> Sent: Wednesday, March 10, 2021 3:40
> To: Greg Kroah-Hartman
> Cc: linux-usb@xxxxxxxxxxxxxxx; 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.
