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:   Fri, 3 Mar 2017 08:29:18 +0100
From:   Mats Karrman <mats.dev.list@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     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-03 04:13, Guenter Roeck wrote:

> On 03/02/2017 07:22 AM, Mats Karrman wrote:
>> ....
>> 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?
> That really depends on the lower level driver. For Chromebooks, where the Type-C
> Protocol Manager runs on the EC, we have an extcon driver which reports the pin states
> to the graphics drivers and connects to the Type-C class code using the Type-C class
> API. I still need to update, re-test, and publish that code. The published code in
> https://chromium.googlesource.com/chromiumos/third_party/kernel/, branch chromeos-4.4,
> shows how it can be done, though that code currently still uses the Android Type-C
> infrastructure.

OK, thanks!

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.

Using extcon I would have a driver that is both typec class and extcon driver at the same time

since I can't share the access to the typec phy. Is this done elsewhere in the kernel?

I don't know much about the wcove PMIC and what alternate modes it might support but I

guess that driver would end up in the same place.

Do we need to further standardize attributes under (each) specific alternate mode to

include things such as HPD for the DP mode?

BR // Mats