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

Groups > linux.kernel > #1458776 > unrolled thread

Re: [PATCHv4 0/2] 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: [PATCHv4 0/2] USB Type-C Connector class Greg KH <gregkh@linuxfoundation.org> - 2016-08-09 16:10 +0200
    Re: [PATCHv4 0/2] USB Type-C Connector class Guenter Roeck <linux@roeck-us.net> - 2016-08-09 18:30 +0200
      Re: [PATCHv4 0/2] USB Type-C Connector class Felipe Balbi <felipe.balbi@linux.intel.com> - 2016-08-10 20:50 +0200
      Re: [PATCHv4 0/2] USB Type-C Connector class Oliver Neukum <oneukum@suse.com> - 2016-08-10 22:30 +0200

#1458776 — Re: [PATCHv4 0/2] USB Type-C Connector class

On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote:
> Hi,
> 
> The USB Type-C class is meant to provide unified interface to the
> userspace to present the USB Type-C ports in a system.
> 
> Changes since v3:
> - Documentation cleanup as proposed by Roger Quadros
> - Setting partner altmodes member to NULL on removal and fixing a
>   warning, as proposed by Guenter Roeck
> - Added the following attributes for partners and cables:
>   * supports_usb_power_delivery
>   * id_header_vdo
> - "id_header_vdo" is visible only when the partner or cable supports
>   USB Power Delivery communication.
> - Partner attribute "accessory" is hidden when the partner type is not
>   "Accessory".
> 
> Changes since v2:
> - Notification on role and alternate mode changes
> - cleanups
> 
> Changes since v1:
> - Completely rewrote alternate mode support
> - Patners, cables and cable plugs presented as devices.

I'm not going to take this series until everyone agrees on it, sorry.
I'll wait for you and Guenter and Oliver to all come up with a solution
that works for everyone.

So I'm dropping this from my queue now, sorry.

greg k-h

[toc] | [next] | [standalone]

#1458912

On Tue, Aug 09, 2016 at 04:01:53PM +0200, Greg KH wrote:
> On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote:
> > Hi,
> > 
> > The USB Type-C class is meant to provide unified interface to the
> > userspace to present the USB Type-C ports in a system.
> > 
> > Changes since v3:
> > - Documentation cleanup as proposed by Roger Quadros
> > - Setting partner altmodes member to NULL on removal and fixing a
> >   warning, as proposed by Guenter Roeck
> > - Added the following attributes for partners and cables:
> >   * supports_usb_power_delivery
> >   * id_header_vdo
> > - "id_header_vdo" is visible only when the partner or cable supports
> >   USB Power Delivery communication.
> > - Partner attribute "accessory" is hidden when the partner type is not
> >   "Accessory".
> > 
> > Changes since v2:
> > - Notification on role and alternate mode changes
> > - cleanups
> > 
> > Changes since v1:
> > - Completely rewrote alternate mode support
> > - Patners, cables and cable plugs presented as devices.
> 
> I'm not going to take this series until everyone agrees on it, sorry.
> I'll wait for you and Guenter and Oliver to all come up with a solution
> that works for everyone.
> 

I have not heard from Heikko for a while. There have been some follow-up
patches in

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes

but I am not really sure where this is going. I've been wondering if I
can/should get more actively involved and start driving the series if
Heikki is busy. Thoughts, anyone ?

Guenter

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

#1459493

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

Hi,

Guenter Roeck <linux@roeck-us.net> writes:
> On Tue, Aug 09, 2016 at 04:01:53PM +0200, Greg KH wrote:
>> On Wed, Jun 29, 2016 at 04:38:36PM +0300, Heikki Krogerus wrote:
>> > Hi,
>> > 
>> > The USB Type-C class is meant to provide unified interface to the
>> > userspace to present the USB Type-C ports in a system.
>> > 
>> > Changes since v3:
>> > - Documentation cleanup as proposed by Roger Quadros
>> > - Setting partner altmodes member to NULL on removal and fixing a
>> >   warning, as proposed by Guenter Roeck
>> > - Added the following attributes for partners and cables:
>> >   * supports_usb_power_delivery
>> >   * id_header_vdo
>> > - "id_header_vdo" is visible only when the partner or cable supports
>> >   USB Power Delivery communication.
>> > - Partner attribute "accessory" is hidden when the partner type is not
>> >   "Accessory".
>> > 
>> > Changes since v2:
>> > - Notification on role and alternate mode changes
>> > - cleanups
>> > 
>> > Changes since v1:
>> > - Completely rewrote alternate mode support
>> > - Patners, cables and cable plugs presented as devices.
>> 
>> I'm not going to take this series until everyone agrees on it, sorry.
>> I'll wait for you and Guenter and Oliver to all come up with a solution
>> that works for everyone.
>> 
>
> I have not heard from Heikko for a while. There have been some follow-up
> patches in
>
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes
>
> but I am not really sure where this is going. I've been wondering if I
> can/should get more actively involved and start driving the series if
> Heikki is busy. Thoughts, anyone ?

Heikki is away on patternity leave. He should be back next Monday. Sorry
this wasn't clear, we should have notified involved folks.

best

-- 
balbi

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

#1459835

On Tue, 2016-08-09 at 09:23 -0700, Guenter Roeck wrote:
> > I'm not going to take this series until everyone agrees on it,
> sorry.
> > I'll wait for you and Guenter and Oliver to all come up with a
> solution
> > that works for everyone.
> > 
> 
> I have not heard from Heikko for a while. There have been some
> follow-up
> patches in
> 
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes
> 
> but I am not really sure where this is going. I've been wondering if I
> can/should get more actively involved and start driving the series if
> Heikki is busy. Thoughts, anyone ?

It is not clear to me where we were. It seems to me that we found
the API good but disagreed about locking. Does that sum it up?

	Regards
		Oliver

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web