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


Powered by blists - more mailing lists