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]

Date:	Tue, 7 Jun 2016 09:57:58 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	Oliver Neukum <oneukum@...e.com>,
	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 Mon, Jun 06, 2016 at 04:28:08PM +0300, Heikki Krogerus wrote:
[ ... ]
> 
> I would prefer lower case letters. I don't know the SIDs there are at
> them moment, other then Display Port. Do you know them?
> 
SIDs:
	0xff00 - power delivery
	0xff01 - displayport
	0xff02 - MHL
	0xff03 - Thunderbolt 3 (if I recall correctly)

VIDs: Can obviously be anything. I have seen
	0x05ac - Apple
	0x18d1 - Google

> I don't think we can ever guarantee that in every case we will be able
> to provide a human readable name for the alternate modes if they are
> vendor defined. We will then potentially still have the names in two
> different forms: "usbc0.displayport" and "usbc0.svid:xxxx". Is that
> something acceptable to everybody?
> 
> I guess if it's not, then to only way to go forward would be to always
> just use the svid in the name.
> 
I think we should just use the svid.

> > > > Also, do we at some point need to standardize the ABI for the standard
> > > > alternate modes such as DisplayPort (if there are any - again I am not
> > > > there yet) ?
> > > 
> > > I don't have an answer to that.
> > > 
> > Ok, I'll look into it as I proceed with my implementation.
> > 
> > > > 
> > > > Sounds good to me. Many other subsystems do the same, ie create the subsystem
> > > > device(s) during registration with the subsystem, so this is in line with other
> > > > kernel code.
> > > > 
> > > > Should I send you a follow-up patch on top of yours ?
> > > 
> > > Sure. I'm a little bit stuck with an other tasks, so let's keep this
> > > thing rolling.
> > > 
> > See below.
> 
> Thanks. I pushed it to my work branch for this class:
> 
> https://github.com/krohei/linux/commits/typec_class
> 
> There are still a few open questions, but I'm in any case going to
> start polishing the driver. I think the other attributes are more or
> less decided, excluding the alternate modes.
> 
Sounds good.

Thanks,
Guenter