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

Groups > linux.kernel > #1330476 > unrolled thread

[PATCH 1/3] usb: USB Type-C Connector Class

Started byHeikki Krogerus <heikki.krogerus@linux.intel.com>
First post2016-02-09 18:10 +0100
Last post2016-02-18 16:20 +0100
Articles 4 on this page of 24 — 5 participants

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

  [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
    Re: [PATCH 1/3] usb: USB Type-C Connector Class Greg KH <gregkh@linuxfoundation.org> - 2016-02-09 19:30 +0100
      Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 11:40 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Greg KH <gregkh@linuxfoundation.org> - 2016-02-10 18:30 +0100
          Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:10 +0100
    Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-10 12:00 +0100
      Re: [PATCH 1/3] usb: USB Type-C Connector Class Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 12:10 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 12:20 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 12:20 +0100
      Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 12:30 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-15 16:20 +0100
      Re: [PATCH 1/3] usb: USB Type-C Connector Class Felipe Balbi <balbi@kernel.org> - 2016-02-11 10:00 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-11 10:20 +0100
          Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 16:00 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:40 +0100
          Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-11 16:00 +0100
    Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-17 15:20 +0100
      Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 09:50 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-18 10:30 +0100
          Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 14:10 +0100
        Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-18 10:40 +0100
          Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 14:30 +0100
            Re: [PATCH 1/3] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-02-18 14:50 +0100
              Re: [PATCH 1/3] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 16:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1337195

FromOliver Neukum <oneukum@suse.com>
Date2016-02-18 10:40 +0100
Message-ID<r3te2-3vZ-5@gated-at.bofh.it>
In reply to#1337154
On Thu, 2016-02-18 at 10:47 +0200, Heikki Krogerus wrote:

Hi,

> P.S. That reminds me, here's my current draft for the
> Documentation/ABI/. Could you take a look?

And I am afraid, that I have a few remarks not bound
to a specific entry.

We have port directories for port power switching. How is
the connector directory linked to them?

Likewise, if we have USB PD, we have to know how that
is linked to the connector directory.

In addition, writes to those files have results. We need
the error codes to be described.

Furthermore, do these files support poll?

And lastly we can get "Attention" as a message connected
with a connector in an alternate mode. How does user space
learn about that?

I am sorry to be this obnoxious, but this is an API which
will be with us for a long time, so we better get it right.

	HTH
		Oliver

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

#1337351

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-18 14:30 +0100
Message-ID<r3wOD-66U-9@gated-at.bofh.it>
In reply to#1337195
Hi,

On Thu, Feb 18, 2016 at 10:35:41AM +0100, Oliver Neukum wrote:
> On Thu, 2016-02-18 at 10:47 +0200, Heikki Krogerus wrote:
> 
> Hi,
> 
> > P.S. That reminds me, here's my current draft for the
> > Documentation/ABI/. Could you take a look?
> 
> And I am afraid, that I have a few remarks not bound
> to a specific entry.
> 
> We have port directories for port power switching. How is
> the connector directory linked to them?

I'm sorry, I don't think I understand this point.

> Likewise, if we have USB PD, we have to know how that
> is linked to the connector directory.

So you mean when we have USB PD PHY or controller, right? That
will be the parent of the connector device if we have one on the
platform.

I think I'm misunderstanding this point as well..

> In addition, writes to those files have results. We need
> the error codes to be described.

Yes, I need to document those.

> Furthermore, do these files support poll?
> 
> And lastly we can get "Attention" as a message connected
> with a connector in an alternate mode. How does user space
> learn about that?

The class should notify the userspace with uevent on
connection/disconnection regardless what is being connected, or what
mode the connector enters initially.

So do you want to see that explained in the ABI document?

The uevent does not contain any details, but I thought that it's OK to
expect the userspace to read that separately. If this is not OK, let's
add a new uevent variable that specifies what was just connected.

I hope I did not misunderstand also this one.

> I am sorry to be this obnoxious, but this is an API which
> will be with us for a long time, so we better get it right.

I would not say you are being obnoxious. If you are, feel free :).
Your input is most welcome. Thanks a lot for that. And I agree, we
need to make this solid from the beginning.


Thanks,

-- 
heikki

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

#1337363

FromOliver Neukum <oneukum@suse.com>
Date2016-02-18 14:50 +0100
Message-ID<r3x7Y-6f7-3@gated-at.bofh.it>
In reply to#1337351
On Thu, 2016-02-18 at 15:25 +0200, Heikki Krogerus wrote:

Hi,


> > We have port directories for port power switching. How is
> > the connector directory linked to them?
> 
> I'm sorry, I don't think I understand this point.

Like this:

oneukum@linux-dtbq:/sys/bus/usb/devices/3-0:1.0> ls -l
total 0
-rw-r--r-- 1 root root 4096 Feb 18 14:34 authorized
-r--r--r-- 1 root root 4096 Feb 18 14:34 bAlternateSetting
-r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceClass
-r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceNumber
-r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceProtocol
-r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceSubClass
-r--r--r-- 1 root root 4096 Feb 18 14:34 bNumEndpoints
lrwxrwxrwx 1 root root    0 Feb 17 15:59 driver
-> ../../../../../bus/usb/drivers/hub
drwxr-xr-x 3 root root    0 Feb 18 09:35 ep_81
-r--r--r-- 1 root root 4096 Feb 18 14:34 modalias
drwxr-xr-x 2 root root    0 Feb 18 09:35 power
lrwxrwxrwx 1 root root    0 Feb 17 15:59 subsystem
-> ../../../../../bus/usb
-r--r--r-- 1 root root 4096 Feb 18 14:34 supports_autosuspend
-rw-r--r-- 1 root root 4096 Feb 18 14:34 uevent
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port1
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port10
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port11
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port12
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port13
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port14
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port15
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port2
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port3
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port4
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port5
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port6
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port7
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port8
drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port9

usb*-port*

They correspond to the connectors a system has.
It seems to me that we want a link connecting them
if the correspondance is known.

> > Likewise, if we have USB PD, we have to know how that
> > is linked to the connector directory.
> 
> So you mean when we have USB PD PHY or controller, right? That
> will be the parent of the connector device if we have one on the
> platform.

So the parentage is different on whether a PD controller is present?
That needs to be documented. And so we cannot deal with separate modules
for a PD driver?

[..]
> > Furthermore, do these files support poll?

At least the current role and mode can change, so in principle
poll() makes sense.

> > And lastly we can get "Attention" as a message connected
> > with a connector in an alternate mode. How does user space
> > learn about that?
> 
> The class should notify the userspace with uevent on
> connection/disconnection regardless what is being connected, or what
> mode the connector enters initially.

Yes, but "Attention" in the sense of 6.4.4.3.6 of the PD spec.
Does this need to be handled in the kernel? Do we generate a uevent
for that?

> So do you want to see that explained in the ABI document?

No.

	Regards
		Oliver

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

#1337456

FromHeikki Krogerus <heikki.krogerus@linux.intel.com>
Date2016-02-18 16:20 +0100
Message-ID<r3yx4-7uQ-17@gated-at.bofh.it>
In reply to#1337363
On Thu, Feb 18, 2016 at 02:44:25PM +0100, Oliver Neukum wrote:
> On Thu, 2016-02-18 at 15:25 +0200, Heikki Krogerus wrote:
> 
> Hi,
> 
> 
> > > We have port directories for port power switching. How is
> > > the connector directory linked to them?
> > 
> > I'm sorry, I don't think I understand this point.
> 
> Like this:
> 
> oneukum@linux-dtbq:/sys/bus/usb/devices/3-0:1.0> ls -l
> total 0
> -rw-r--r-- 1 root root 4096 Feb 18 14:34 authorized
> -r--r--r-- 1 root root 4096 Feb 18 14:34 bAlternateSetting
> -r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceClass
> -r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceNumber
> -r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceProtocol
> -r--r--r-- 1 root root 4096 Feb 18 14:34 bInterfaceSubClass
> -r--r--r-- 1 root root 4096 Feb 18 14:34 bNumEndpoints
> lrwxrwxrwx 1 root root    0 Feb 17 15:59 driver
> -> ../../../../../bus/usb/drivers/hub
> drwxr-xr-x 3 root root    0 Feb 18 09:35 ep_81
> -r--r--r-- 1 root root 4096 Feb 18 14:34 modalias
> drwxr-xr-x 2 root root    0 Feb 18 09:35 power
> lrwxrwxrwx 1 root root    0 Feb 17 15:59 subsystem
> -> ../../../../../bus/usb
> -r--r--r-- 1 root root 4096 Feb 18 14:34 supports_autosuspend
> -rw-r--r-- 1 root root 4096 Feb 18 14:34 uevent
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port1
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port10
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port11
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port12
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port13
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port14
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port15
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port2
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port3
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port4
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port5
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port6
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port7
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port8
> drwxr-xr-x 3 root root    0 Feb 18 09:35 usb3-port9
> 
> usb*-port*
> 
> They correspond to the connectors a system has.
> It seems to me that we want a link connecting them
> if the correspondance is known.

Ah, got it. In case of ACPI enumerated UCSI, we will have the actual
ACPI device object for the port as a child device object. So when we
attach the port ACPI companion to the connector device we create in
the class, it will link us directly to the correct usb*-port*.

I have not done it so far because the same port ACPI device object
will also be bound to the usb peripheral once it gets enumerated, and
I was worried if that would cause a problem. But after talking to guys
that know more about ACPI then I do, I'm sure that is not going to be
a problem.

With ACPI, the binding should happen the same way even without UCSI.
What ever device driver registers the connector device should have the
port ACPI device object as it's child. So I'm thinking about doing
this in typec_register_port() and not in UCSI driver.


Thanks,

-- 
heikki

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web