linux-kernel - Re: [PATCH v17 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, 2 Mar 2017 16:22:26 +0100
From:   Mats Karrman <mats.dev.list@...il.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Oliver Neukum <oneukum@...e.com>, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki,

Good to see things are happening with Type-C!

On 2017-02-21 15:24, Heikki Krogerus wrote:

> ...
> +When connected, the partner will be presented also as its own device under
> +/sys/class/typec/. The parent of the partner device will always be the port it
> +is attached to. The partner attached to port "port0" will be named
> +"port0-partner". Full path to the device would be
> +/sys/class/typec/port0/port0-partner/.

A "/port0" too much?

> +
> +The cable and the two plugs on it may also be optionally presented as their own
> +devices under /sys/class/typec/. The cable attached to the port "port0" port
> +will be named port0-cable and the plug on the SOP Prime end (see USB Power
> +Delivery Specification ch. 2.4) will be named "port0-plug0" and on the SOP
> +Double Prime end "port0-plug1". The parent of a cable will always be the port,
> +and the parent of the cable plugs will always be the cable.
> +
> +If the port, partner or cable plug support Alternate Modes, every supported
> +Alternate Mode SVID will have their own device describing them. The Alternate
> +Modes will not be attached to the typec class. The parent of an alternate mode
> +will be the device that supports it, so for example an alternate mode of
> +port0-partner will bees presented under /sys/class/typec/port0-partner/. Every

bees?

> +mode that is supported will have its own group under the Alternate Mode device
> +named "mode<index>", for example /sys/class/typec/port0/<alternate mode>/mode1/.
> +The requests for entering/exiting a mode can be done with "active" attribute
> +file in that group.
> +
> ...

I'm hoping to find time to upgrade the kernel and try these patches in my system.

Looking forward, one thing I have run into is how to connect the typec driver with a
driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification
includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in the
Attention message. These signals are needed by the DisplayPort driver to know when to
start negotiation etc.
Have you got any thoughts on how to standardize such interfaces?

BR // Mats