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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 15 Dec 2016 07:01:08 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Oliver Neukum <oneukum@...e.com>
Cc:     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 12/15/2016 03:50 AM, Heikki Krogerus wrote:
> 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?
>

Ok with me.

Guenter