From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Prashant Malani <pmalani@chromium.org>
Cc: "open list:USB NETWORKING DRIVERS" <linux-usb@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Benson Leung <bleung@chromium.org>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: typec: Add bus type for plug alt modes
Date: Wed, 9 Dec 2020 18:13:56 +0200 [thread overview]
Message-ID: <20201209161356.GI680328@kuha.fi.intel.com> (raw)
In-Reply-To: <CACeCKaehg=HTuQNLtQaJZWvTnOFYM9b1BWfM+WX_ebiZ-_i8JQ@mail.gmail.com>
On Tue, Dec 08, 2020 at 03:45:19PM -0800, Prashant Malani wrote:
> Hi Heikki,
>
> Thanks a lot for looking at the patch.
>
> On Tue, Dec 8, 2020 at 1:37 AM Heikki Krogerus <heikki.krogerus@linux.intel.com> wrote:
> >
> > On Wed, Dec 02, 2020 at 07:08:47PM -0800, Prashant Malani wrote:
> > > Add the Type C bus for plug alternate modes which are being
> > > registered via the Type C connector class. This ensures that udev events
> > > get generated when plug alternate modes are registered (and not just for
> > > partner/port alternate modes), even though the Type C bus doesn't link
> > > plug alternate mode devices to alternate mode drivers.
> >
> > I still don't understand how is the uevent related to the bus? If you
> > check the device_add() function, on line 2917, kobject_uevent() is
> > called unconditionally. The device does not need a bus for that event
> > to be generated.
>
> My initial thought process was to see what is the difference in the adev device
> initialization between partner altmode and plug altmode (the only difference I saw in
> typec_register_altmode() was regarding the bus field).
>
> Yes, kobject_uevent() is called unconditionally, but it's return value isn't checked,
> so we don't know if it succeeded or not.
>
> In the case of cable plug altmode, I see it fail with the following error[1]:
>
> [ 114.431409] kobject: 'port1-plug0.0' (000000004ad42956): kobject_uevent_env: filter function caused the event to drop!
>
> I think the filter function which is called is this one: drivers/base/core.c: dev_uevent_filter() [2]
>
> static int dev_uevent_filter(struct kset *kset, struct kobject *kobj)
> {
> struct kobj_type *ktype = get_ktype(kobj);
>
> if (ktype == &device_ktype) {
> struct device *dev = kobj_to_dev(kobj);
> if (dev->bus)
> return 1;
> if (dev->class)
> return 1;
> }
> return 0;
> }
>
> So, both the "if (dev->bus)" and "if (dev->class)" checks are failing here. In the case of partner alt modes, bus is set by the class.c code
> so this check likely returns 1 in that case.
OK. I understand the issue now. So I would say that the proper
solution to this problem is to link the alt modes with the class
instead of the bus. That is much smaller change IMO.
thanks,
--
heikki
next prev parent reply other threads:[~2020-12-09 16:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 3:08 Prashant Malani
2020-12-08 9:37 ` Heikki Krogerus
2020-12-08 23:45 ` Prashant Malani
2020-12-09 16:13 ` Heikki Krogerus [this message]
2020-12-09 16:22 ` Prashant Malani
2020-12-09 17:15 ` Heikki Krogerus
2020-12-09 22:59 ` Prashant Malani
2020-12-09 23:47 ` Prashant Malani
2020-12-10 11:49 ` Heikki Krogerus
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=20201209161356.GI680328@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=bleung@chromium.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pmalani@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome