Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1542662 > unrolled thread

Re: [PATCHv13 2/3] usb: USB Type-C connector class

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv13 2/3] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-12-15 13:00 +0100
    Re: [PATCHv13 2/3] usb: USB Type-C connector class Oliver Neukum <oneukum@suse.com> - 2016-12-15 13:20 +0100
    Re: [PATCHv13 2/3] usb: USB Type-C connector class Guenter Roeck <linux@roeck-us.net> - 2016-12-15 16:30 +0100
      Re: [RFC PATCH] usb: USB Type-C connector class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-12-20 15:30 +0100

#1542662 — 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

[toc] | [next] | [standalone]

#1542683

On Thu, 2016-12-15 at 13:50 +0200, Heikki Krogerus wrote:

> 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?

Hi,

they are all right with me.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1542820

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

[toc] | [prev] | [next] | [standalone]

#1545167 — Re: [RFC PATCH] usb: USB Type-C connector class

[Multipart message — attachments visible in raw view] — view raw

On Mon, Dec 19, 2016 at 09:22:33AM -0800, Guenter Roeck wrote:
> On 12/19/2016 06:45 AM, Heikki Krogerus wrote:
> > The purpose of USB Type-C connector class is to provide
> > unified interface for the user space to get the status and
> > basic information about USB Type-C connectors on a system,
> > control over data role swapping, and when the port supports
> > USB Power Delivery, also control over power role swapping
> > and Alternate Modes.
> > 
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > ---
> >  Documentation/ABI/testing/sysfs-class-typec |  220 ++++++
> >  Documentation/usb/typec.txt                 |  174 +++++
> >  MAINTAINERS                                 |    9 +
> >  drivers/usb/Kconfig                         |    2 +
> >  drivers/usb/Makefile                        |    2 +
> >  drivers/usb/typec/Kconfig                   |    7 +
> >  drivers/usb/typec/Makefile                  |    1 +
> >  drivers/usb/typec/typec.c                   | 1047 +++++++++++++++++++++++++++
> >  include/linux/usb/typec.h                   |  212 ++++++
> >  9 files changed, 1674 insertions(+)
> >  create mode 100644 Documentation/ABI/testing/sysfs-class-typec
> >  create mode 100644 Documentation/usb/typec.txt
> >  create mode 100644 drivers/usb/typec/Kconfig
> >  create mode 100644 drivers/usb/typec/Makefile
> >  create mode 100644 drivers/usb/typec/typec.c
> >  create mode 100644 include/linux/usb/typec.h
> > 
> > 
> > Hi,
> > 
> > There was one more change to the ABI: the ports are now named
> > "port<id>" instead of "usbc<id>". Let me know if that is OK!
> > 
> > The series is still being reviewed internally, but I'm sending this
> > already here so you guys can take a look.
> > 
> > The API now expects the drivers to register every part separately,
> > including the alternate modes for the port itself. Structures for the
> > partner/cable/plug/altmode are now protected, and the drivers need to
> > register those with separate descriptor structures and get a handle to
> > struct typec_partner/cable/plug/altmode if the registration is
> > successful, or just NULL in case of failure as Greg proposed.
> > 
> > As the drivers need to register the partners and the cables separately
> > in any case, the drivers do not declare connections with the class
> > anymore. If the default role changes during initial negotiation with a
> > partner, the drivers need to notify the class before registering the
> > partner or cable.
> > 
> 
> Can you also publish the Whiskey Cove driver ? That might help figuring out
> the necessary driver changes.

Please find it attached.

Br,

-- 
heikki

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web