usb: typec: Missing link for altmode active store

usb: typec: Missing link for altmode active store

[Mats Karrman]

Hello Heikki,

I'm working with the new typec class code and have run into a problem.
The struct typec_capability defines a callback function as:

int (*activate_mode)(const struct typec_capability *, int mode, int activate);

 From the capability I can get to the corresponding port/plug/partner private
data and to the svid's registered for that device.
The mode argument tells me which of the modes registered for a svid that is to
be (de)activated.
However, as far as I can tell there is no way for activate_mode() to find out
which svid is in question without an additional argument, e.g. "u16 svid".

Please correct me if I'm wrong.

BR,
Mats

Re: usb: typec: Missing link for altmode active store

[Heikki Krogerus]

Hi Mats,

On Sun, Apr 16, 2017 at 09:28:01PM +0200, Mats Karrman wrote:
> Hello Heikki,
> 
> I'm working with the new typec class code and have run into a problem.
> The struct typec_capability defines a callback function as:
> 
> int (*activate_mode)(const struct typec_capability *, int mode, int activate);
> 
> From the capability I can get to the corresponding port/plug/partner private
> data and to the svid's registered for that device.
> The mode argument tells me which of the modes registered for a svid that is to
> be (de)activated.
> However, as far as I can tell there is no way for activate_mode() to find out
> which svid is in question without an additional argument, e.g. "u16 svid".

True. If there is more then one supported alternate mode, we need to
identify it with the svid. But there is an other thing that needs to
be considered.

We need to be able to determine are we dealing with port or
partner/plug alternate mode. An easy fix would be to add something
like "is_port" argument on top of "svid", but I would like to think
about this. Perhaps we can fix this a bit more elegantly? For example,
if we could use struct typec_altmode_desc as the first argument
instead of typec_capapbility, we would not need to touch or add other
arguments.


Thanks,

-- 
heikki