From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Oliver Neukum <oneukum@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
Badhri Jagan Sridharan <badhri@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCHv12 2/3] usb: USB Type-C connector class
Date: Mon, 28 Nov 2016 16:23:23 +0200 [thread overview]
Message-ID: <20161128142323.GA32668@kuha.fi.intel.com> (raw)
In-Reply-To: <1480328372.22547.8.camel@suse.com>
On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> On Thu, 2016-11-24 at 11:57 +0200, Heikki Krogerus wrote:
> > On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
>
> > > In our implementation, the default preferred role is determined by the
> > > low level driver (as, in my understanding, is suggested by the standard).
> > > This means that the ABI will report "no preferred role", unless user space
> > > overwrites it, even though there _is_ in fact a preferred role, and the
> > > low level driver will execute try.src or try.snk based on that role.
> >
> > I'm not sure which standard are you referring? Try.SNK and Try.SRC are
> > optional mechanisms for *policy-based* role preference according to
> > the USB Type-C spec. The policy really should always come from the
>
> Not all that obvious. If you are looking at it from a distro view
> point if you know that you are booting on basically a gadget, you'll
> be happy to take the hint. And if the hardware knows it is better
> as a sink or source, we should take the hint.
>
> > user space in our case, but I don't think that rules out for example
> > initial role preferences coming from the lower level drivers.
>
> Indeed. That should not be a hindrance to submission and inclusion.
>
> > We will need a way the OS can set the initial preference for every
> > port. Note that once we can support that, what ever the lower level
> > drivers request will be overridden by it. So if for example the
> > platform has preference for an initial role, we will simply ignore it
> > if the policy says otherwise.
>
> Again, not obvious in a distro. I would actually prefer a module
> parameter that would allow us to prefer try.src, as we know how
> to be a master.
I would be happy with module parameter.
> None of that should hinder submission and inclusion.
It's already there in v13.
I better ping Greg already after rc1 this time, just so we don't start
the review again when we are already at rc5 (and I have forgotten
about this whole thing). I'll ask about the module parameter idea
then, though I'm guessing he won't like it. But maybe he has some
suggestions.
Thanks Oliver,
--
heikki
next prev parent reply other threads:[~2016-11-28 14:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 14:11 [PATCHv12 0/3] USB Type-C Connector class Heikki Krogerus
2016-11-22 14:11 ` [PATCHv12 1/3] lib/string: add sysfs_match_string helper Heikki Krogerus
2016-11-23 16:14 ` Guenter Roeck
2016-11-24 0:17 ` Guenter Roeck
2016-11-22 14:11 ` [PATCHv12 2/3] usb: USB Type-C connector class Heikki Krogerus
2016-11-23 16:27 ` Guenter Roeck
2016-11-24 0:17 ` Guenter Roeck
2016-11-24 5:12 ` Guenter Roeck
2016-11-24 9:57 ` Heikki Krogerus
2016-11-28 10:19 ` Oliver Neukum
2016-11-28 14:23 ` Heikki Krogerus [this message]
2016-11-28 20:11 ` Guenter Roeck
2016-11-29 7:40 ` Oliver Neukum
2016-11-29 12:59 ` Heikki Krogerus
2016-11-29 13:20 ` Greg KH
2016-11-29 13:48 ` Oliver Neukum
2016-11-29 14:02 ` Greg KH
2016-11-22 14:11 ` [PATCHv12 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY Heikki Krogerus
2016-11-23 16:42 ` Guenter Roeck
2016-11-23 14:55 ` [PATCHv12 0/3] USB Type-C Connector class 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=20161128142323.GA32668@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=badhri@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=oneukum@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome