linux-kernel - Re: usb: typec: Missing link for altmode active store

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] [day] [month] [year] [list]

Message-ID: <20170418142034.GC24062@kuha.fi.intel.com>
Date:   Tue, 18 Apr 2017 17:20:34 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Mats Karrman <mats.dev.list@...il.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: usb: typec: Missing link for altmode active store

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