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: <20160525112846.GB27570@kuha.fi.intel.com>
Date:	Wed, 25 May 2016 14:28:46 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Oliver Neukum <oneukum@...e.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

Hi,

On Tue, May 24, 2016 at 02:51:40PM +0200, Oliver Neukum wrote:
> 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

I'm fine with adding an attribute for port and cable resets if it's
something that is needed. So do you want to be able to execute hard
reset on a port?

But could you please explain the case(s) where you need to tricker a
reset.

> > 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.

OK, but what is Try.SNK? It's not in the specs?

> 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.

I don't have a problem with that, but what does Greg say?

> > 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.


Thanks,

-- 
heikki