linux-kernel - Re: [RFC PATCH] usb: typec: Various API updates and fixes

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]

Date:	Mon, 30 May 2016 15:48:02 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Oliver Neukum <oneukum@...e.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCH] usb: typec: Various API updates and fixes

Hi guys,

On Fri, May 27, 2016 at 07:06:41AM -0700, Guenter Roeck wrote:
> On 05/27/2016 12:55 AM, Heikki Krogerus wrote:
> > I'll merge this into any case to v3, and I'll send on Monday.
> > 
> Sounds good.
> 
> Couple of additional comments.
> 
> I don't really know what to do with the 'desc' field in struct typec_mode
> for modes received from the partner. I wonder if it makes sense to display
> it for partner modes.

The idea comes straight from Billboard class where every mode has an
index to an _optional_ string. Those desc should ultimately come from
the altmode bus driver, and I think never from the port drivers.

> Also, there is currently no attribute to show the partner identity (data
> received from the Discover Identity command). Would it make sense to add
> an 'identity' attribute to the partner device (plus an associated API
> function to set it) ?

The problem is that we can only use it when the partner and our port
are both PD capable. Details about PDUSB devices that are attached are
out side the scope of this interface IMO, and need to be in any case
handled in USB core by using the PD Class specific descriptors etc.,
and possible with the help of the future PD stack that you are working
on. It's an other task. So this interface IMO should expose only the
Type-C specific details about the ports and partners. How about if we
just add an attribute "usb_communication_capable" for the partners?
That is something that we should be able to always determine, even
without USB PD.

Thanks,

-- 
heikki