linux-kernel - Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160511094011.GA26869@kuha.fi.intel.com>
Date:	Wed, 11 May 2016 12:40:11 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Greg KH <gregkh@...uxfoundation.org>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Felipe Balbi <balbi@...nel.org>
Subject: Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

On Tue, May 10, 2016 at 08:14:34PM -0700, Guenter Roeck wrote:
> Heikki,
> 
> On 05/06/2016 01:08 AM, Heikki Krogerus wrote:
> > Hi,
> > 
> [ ... ]
> > 
> > I don't have not made any new code for the class driver yet, but I'm
> > attempting to prepare v2 next week.
> > 
> Would it make sense to send feedback about v1 now, or should I wait for v2 ?

I don't think I'm able to send v2 today, or even tomorrow, so feel
free to give the feedback. Just be aware that I've rewritten the
alternate mode part completely.

I'm creating a separate device for the partner and also the cable
during connection. I'm also already going to introduce a small bus for
the AltModes. It's clear that we need to have AltMode specific
drivers. The generic parts can't take care of all the AltMode specific
requirements and VDMs. The bus will give us a nice way to bind those
drivers to the actual AltModes a partner and the cable plugs offer.

So if there are dependencies between the altmodes, for example if the
cable plugs needs to be in a certain mode in order for the partner to
be able to function in some specific mode, the responsibility of
taking care of those will fall primarily to in the AltMode drivers.
So not userspace.

The AltMode drivers actually are useful also as they can be part of
the relevant frameworks, for example DP in some graphics framework.
For example in case of DP, the number of lanes (I guess 2 or 4) should
be ideally known if I have understood correctly. Knowledge about the
connection seems to also be needed, and I've so far seen some pretty
weird solutions for hotplug events with the DP AltMode. With the
driver we should be able to avoid those.

But in any case, every SVIDs a partner (or plug) offers will have
their own device registered with the partner (or cable) itself as
parent in this design. I'm expecting a little bit of conversation
about this plan, but right now I feel confident about it.

How does this sound to you?

Cheers,

-- 
heikki