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
