linux-kernel - Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

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: <1455790706.1384.29.camel@suse.com>
Date:	Thu, 18 Feb 2016 11:18:26 +0100
From:	Oliver Neukum <oneukum@...e.com>
To:	Felipe Balbi <balbif@...il.com>
Cc:	Felipe Balbi <balbi@...nel.org>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	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 2/3] usb: type-c: USB Type-C Connector System Software
 Interface

On Thu, 2016-02-18 at 09:08 +0200, Felipe Balbi wrote:

> Oliver Neukum <oneukum@...e.com> writes:
> >> Oliver Neukum <oneukum@...e.com> writes:

Hi,

> > What exactly are you sure about about?
> 
> heh, missed a NOT there :-)

I am still confused :-)
Do you think a sysfs interface is good, bad or good
but insufficient?

> >> that, eventually, we will need an actual stack exposed for the CC pin.
> >
> > The raw CC pin? What about the timing requirement?
> 
> well, not the _raw_ CC pin, but a situation where the microcontroller
> handling CC pin is "dumb", in the sense that it provides an interface
> for us to request/start arbitrary transactions. That will, in turn,
> shift the actual bits on the CC pin. Or something along these lines.

Well, how else would we send vendor specific messages?

> An example would be the alternate mode thing. CC microcontroller doesn't
> have to know what are the available alternate modes, but it needs to be
> able to tell processor what request is coming from the other end.

Indeed.

> I guess what I'm trying to say is that CC microcontroller might not be
> the one controlling the multiplexer which switches USB pins to another
> function. IOW:
> 
> Change to alternate mode X message
>  CC microcontroller interrupts CPU
>   read status to get X
>    change multiplexer
> 

Yes. But it seems to me that in this case we need a kernel driver
without an API to user space. There are necessarily internal users
of the PD controller. There are also external users. So the CC pins
should be seen as a bus, which in essence they are (it reminds me
of ancient ethernet actually), and if you really want full user
space access, you'd need the quivalent of an sg driver.

The issue is orthogonal to the question how we support UCSI,
except that UCSI is a user of the CC pins and PD and frankly
I don't see the firmware and a driver access this sanely simultaneously.
Therefore I'd prefer we make an API here which does not depend on UCSI,
but can, if necessary, work on top of a driver doing full hardware
access.

	Regards
		Oliver