linux-kernel - Re: [PATCH 1/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, 18 Feb 2016 14:44:25 +0100
From:	Oliver Neukum <oneukum@...e.com>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	Felipe Balbi <balbi@...nel.org>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 1/3] usb: USB Type-C Connector Class

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@...ux-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