linux-kernel - Re: [RFC PATCHv2] usb: USB Type-C Connector Class

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

Message-ID: <1464094300.11721.17.camel@suse.com>
Date:	Tue, 24 May 2016 14:51:40 +0200
From:	Oliver Neukum <oneukum@...e.com>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:

Hi,

as this discussion seems to go in circles, I am starting anew
at the top.

> Like I've told some of you guys, I'm trying to implement a bus for
> the Alternate Modes, but I'm still nowhere near finished with that
> one, so let's just get the class ready now. The altmode bus should in
> any case not affect the userspace interface proposed in this patch.
> 
> As you can see, the Alternate Modes are handled completely differently
> compared to the original proposal. Every Alternate Mode will have
> their own device instance (which will be then later bound to an
> Alternate Mode specific driver once we have the bus), but also every
> partner, cable and cable plug will have their own device instances
> representing them.

The API works for a DFP. I fail to see how the UFP learns about entering
an alternate mode.
Secondly, support to trigger a reset is missing

> An other change is that the data role is now handled in two ways.
> The current_data_role file will represent static mode of the port, and
> it will use the names for the roles as they are defined in the spec:
> DFP, UFP and DRP. This file should be used if the port needs to be

Good, but support for Try.SRC and Try.SNK is missing.
An additional problem with that is that it needs to work
without user space during boot. So I think module parameters
to set the default are necessary.

> fixed to one specific role with DRP ports. So this approach will
> replace the suggestions for "preferred" data role we had. The
> current_usb_data_role will use values "host" and "device" and it will
> be used for data role swapping when already connected.
> 
> The tree of devices that will be populated when the cable is active
> and when the cable has controller on both plug, will look as
> following:
> 
> usbc0
> |- usbc0-cable
> |   |- usbc0-plug0
> |   |   |- usbc0-plug.svid:xxx
> |   |   |   |-mode0
> |   |   |   |   |- vdo
> |   |   |   |   |- desc
> |   |   |   |   |- active
> ...
> |   |- usbc0-plug1
> |   |   |-usbc0-partner
> |   |   |   |- usbc0-partner.svid:xxxx
> |   |   |   |	|-mode0
> |   |   |   |	|   |- vdo
> |   |   |   |	|   |- desc
> |   |   |   |	|   |- active
> |   |   |   |	|-mode1
> ...
> |   |   |- usbc0-plug1.svid:xxx
> |   |   |   |-mode0
> |   |   |   |   |- vdo
> ...
> 
> If there is no active cable, the partner will be directly attached to
> the port, but symlink to the partner is now always added to the port
> folder in any case. I'm not sure about this approach. There is a
> question about it in the code. Please check it.

This approach looks workable.
An the whole the approach looks good, but needs to be extended.

	Regards
		Oliver