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: <20170306131442.GC6999@kuha.fi.intel.com>
Date:   Mon, 6 Mar 2017 15:14:42 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Mats Karrman <mats.dev.list@...il.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        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

Hi Mats,

On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote:
> On 2017-03-03 13:59, Heikki Krogerus wrote:
> 
> > On Fri, Mar 03, 2017 at 08:29:18AM +0100, Mats Karrman wrote:
> > ....
> 
> > How would something like that sound to you guys?
> 
> Complicated... Need to marinate on that for a while ;)

Sorry about the bad explanation :-). Let me try again..  I'm simply
looking for a method that is as scalable as possible to handle the
alternate modes, basically how to couple the different components
involved. Bus would feel like the best approach at the moment.

> > > 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?


Thanks,

-- 
heikki