All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-usb@vger.kernel.org,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Lukas Wunner <lukas@wunner.de>,
	Mario Limonciello <mario.limonciello@dell.com>,
	Christian Kellner <christian@kellner.me>,
	Benson Leung <bleung@google.com>,
	Prashant Malani <pmalani@google.com>,
	Diego Rivas <diegorivas@google.com>
Subject: Re: [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels
Date: Wed, 10 Mar 2021 09:53:31 +0100	[thread overview]
Message-ID: <YEiJC/oZ2ZasVtvf@kroah.com> (raw)
In-Reply-To: <20210310075444.GB2542@lahna.fi.intel.com>

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

  reply	other threads:[~2021-03-10  8:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 13:48 [PATCH 0/3] thunderbolt: Expose details about tunneling Mika Westerberg
2021-03-09 13:48 ` [PATCH 1/3] thunderbolt: Add details to router uevent Mika Westerberg
2021-03-09 14:10   ` Greg Kroah-Hartman
2021-03-10 17:28   ` Limonciello, Mario
2021-03-11  7:59     ` Mika Westerberg
2021-03-09 13:48 ` [PATCH 2/3] thunderbolt: Hide authorized attribute if router does not support PCIe tunnels Mika Westerberg
2021-03-09 14:10   ` Greg Kroah-Hartman
2021-03-09 13:48 ` [PATCH 3/3] thunderbolt: Expose more details about USB 3.x and DisplayPort tunnels Mika Westerberg
2021-03-09 14:09   ` Greg Kroah-Hartman
2021-03-10  7:54     ` Mika Westerberg
2021-03-10  8:53       ` Greg Kroah-Hartman [this message]
2021-03-10  9:21         ` Mika Westerberg
2021-03-10  9:34           ` Greg Kroah-Hartman
2021-03-10  9:39             ` Mika Westerberg
2021-03-10 16:24               ` Limonciello, Mario
2021-03-10 18:49                 ` Lukas Wunner
2021-03-10 19:32                   ` Limonciello, Mario
2021-03-17 10:19   ` Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEiJC/oZ2ZasVtvf@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=bleung@google.com \
    --cc=christian@kellner.me \
    --cc=diegorivas@google.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mario.limonciello@dell.com \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=pmalani@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.