Date: Tue, 18 Apr 2017 17:20:34 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Mats Karrman <mats.dev.list@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
        Felipe Balbi <felipe.balbi@linux.intel.com>, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: usb: typec: Missing link for altmode active store
Message-ID: <20170418142034.GC24062@kuha.fi.intel.com>
References: <6d138cdd-de75-c58b-623f-1296039a2585@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6d138cdd-de75-c58b-623f-1296039a2585@gmail.com>
User-Agent: Mutt/1.8.0 (2017-02-23)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1291
Lines: 34

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