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

[Heikki Krogerus]

On Wed, Nov 23, 2016 at 09:12:04PM -0800, Guenter Roeck wrote:
> Hello Heikki,
> 
> On 11/22/2016 06:11 AM, Heikki Krogerus wrote:
> [ ... ]
> > +
> > +struct typec_port *typec_register_port(struct device *dev,
> > +				       const struct typec_capability *cap)
> > +{
> > +	struct typec_port *port;
> > +	int ret;
> > +	int id;
> > +
> > +	port = kzalloc(sizeof(*port), GFP_KERNEL);
> > +	if (!port)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	id = ida_simple_get(&typec_index_ida, 0, 0, GFP_KERNEL);
> > +	if (id < 0) {
> > +		kfree(port);
> > +		return ERR_PTR(id);
> > +	}
> > +
> > +	port->prefer_role = TYPEC_NO_PREFERRED_ROLE;
> > +
> 
> Following up on this:
> 
> 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
user space in our case, but I don't think that rules out for example
initial role preferences coming from the lower level drivers.

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.

> It might make sense to add the preferred role to struct typec_capability
> and get the initial value from there. If a low level driver does not want
> to specify it, it can easily set its value to TYPEC_NO_PREFERRED_ROLE.

Well, ideally the port drivers would not need to do anything if there
is no preference, but I don't think it's a problem. Since this is API,
I guess we can even change this later if we come up with a better way
of doing this. I'll add it.


Thanks,

-- 
heikki