lkml.org 
[lkml]   [2016]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv13 2/3] usb: USB Type-C connector class
On Wed, Dec 07, 2016 at 02:52:31PM +0200, Heikki Krogerus wrote:
> Hi Oliver,
>
> On Wed, Dec 07, 2016 at 10:46:48AM +0100, Oliver Neukum wrote:
> > On Fri, 2016-12-02 at 10:04 -0800, Guenter Roeck wrote:
> >
> > Hi,
> >
> > > At least for my part I very much concentrated on making sure that
> > > the user space ABI as well as the port driver API are sane and usable.
> >
> > Rightly so, as this part cannot be changed once included in a kernel
> > release.
> > So, can we agree that that part at least is ready to go?
>
> I at least have no plans on doing any changes to the ABI. The API will
> change.

I have received (off-list) some questions related to this. There are a
few things that people would like to still change after all.

1) Should we use "source" and "sink" instead of "device" and "host"
with the prefer_role attribute after all? I was uncomfortable with
that when we talked about it last time because the terms kept changing
with every new Type-C specification version. But I guess "source" and
"sink" would make sense in the end. This has been requested by several
guys now.

2) Can we change the way we list the supported roles? They are now
comma separated, but can we use new line instead:

% cat supported_data_roles
host
device
%

3) Instead of the "supports_usb_power_delivery" attribute file which
we have for the ports and partners, it seem it would be more
interesting to know the supported USB Power Delivery Specification
version for some, and also USB Type-C Specification version in
separate attribute file. So basically we would have
"usb_power_delivery_version" and "usb_typec_version" attributes
instead or "supports_usb_power_delivery".


So would these changes be OK still at this point to everybody?


Thanks,

--
heikki

\
 
 \ /
  Last update: 2016-12-15 12:53    [W:0.119 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site