linux-kernel - Re: [PATCHv12 2/3] usb: USB Type-C connector class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Nov 2016 12:11:43 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Oliver Neukum <oneukum@...e.com>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCHv12 2/3] usb: USB Type-C connector class

On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> 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
> > 

The Type-C specification states (in 4.5.2.2.11):

"Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one shall be
enabled by the port at any given time. Deciding which of these two mechanisms
is enabled is product design-specific."

I read into this:
- The class code can not assume that either of those mechanisms are implemented.
- "product-design specific" means that the product designer determines which of
  the two mechanisms (if any) is enabled. While not explicitly stated, I would
  assume this to be set either by hardware or via devicetree / ACPI, and not
  from user space.

I don't mind to have user space control; all I am asking for is to have the
means for lower level code (which is the most likely entity to know about
product design) to be able to inform higher layers about its initial
preferences. We have this now, so I am happy.

> > 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.
> 
Personally I don't really care about a module parameter; as mentioned above,
I would expect the preference, if it needs to be selectable, to be configured
with devicetree or ACPI properties (or by a platform driver which sets a device
property).

Thanks,
Guenter