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]

Message-ID: <696552a7-c36a-1d73-9517-543907e9da39@gmail.com>
Date:   Tue, 7 Mar 2017 23:30:54 +0100
From:   Mats Karrman <mats.dev.list@...il.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Guenter Roeck <linux@...ck-us.net>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        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

On 2017-03-06 14:14, Heikki Krogerus wrote:

> Hi Mats,
>
> On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote:
>>>> My system is a bit different. It's an i.MX6 SoC with the typec phy and DP controller connected
>>>> directly to the SoC and it's using DTB/OF.
>>> Is this "DP controller" a controller that is capable of taking care of
>>> the USB Power Delivery communication with the partner regarding
>>> DisplayPort alternate mode?
>> No, the "DP controller" just talks DP and knows nothing about Type-C or USB PD.
>> It takes a video stream from the SoC and turns it into a DP link, set up and orchestrated
>> by the corresponding driver. And all the driver needs from Type-C is the plugged in / interrupt /
>> plugged out events.
> Got it.
>
>> The analog switching between USB / safe / DP signal levels in the Type-C connector is, I think,
>> best handled by the software doing the USB PD negotiation / Altmode handling (using some GPIOs).
>>
>>>> Do we need to further standardize attributes under (each) specific alternate mode to
>>>> include things such as HPD for the DP mode?
>>> I'm not completely sure what kind of system you have, but I would
>>> imagine that if we had the bus, your DP controller driver would be the
>>> port (and partner) alternate mode driver. The bus would bind you to
>>> the typec phy.
>> So, both the DP controller and the USB PD phy are I2C devices, and now I have to make them both
>> attach to the AM bus as well?
> The DP controller would provide the driver and the USB PD phy
> (actually, the typec class) the device.
>
> Would it be a problem to register these I2C devices with some other
> subsystem, was it extcon or something like AM bus? It really would not
> be that uncommon. Or have I misunderstood your question?

OK, so a bus could be used for drivers to find each other but it still does not say
anything about how those drivers are supposed to communicate so that must be prescribed
separately, right?

If I read Heikki's original suggestion I understand it like the DP driver would be
responsible for AM specific USB PD/VDM communication. But wouldn't that lead
to a lot of code duplication since the AM protocol is the same for all drivers of
a kind?

I'm still struggling to catch up on what you guys have been up to during the
last year or so :-) and came across some patches of Guenter from last October:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html

What happened to them? Has there been any progress since then?

BR // Mats