linux-kernel - Re: [PATCHv13 2/3] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161215115055.GB8312@kuha.fi.intel.com>
Date:   Thu, 15 Dec 2016 13:50:55 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [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