All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.