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]

Date:	Thu, 18 Feb 2016 09:08:16 +0200
From:	Felipe Balbi <balbif@...il.com>
To:	Oliver Neukum <oneukum@...e.com>, Felipe Balbi <balbi@...nel.org>
Cc:	balbif@...il.com,
	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


Hi,

Oliver Neukum <oneukum@...e.com> writes:
>> Oliver Neukum <oneukum@...e.com> writes:
>> >> > The API to user space. That is the point. We cannot break user space.
>> >> > Once this sysfs API is upstream we are stuck with it.
>> >> 
>> >> yeah, in fact I have been wondering if sysfs is the best interface to
>> >
>> > That is the discussion we must have.
>> >
>> >> userspace. I talked with Heikki a few days back about this; I was
>> >> wondering if something like what the NFC folks did with netlink would be
>> >> better here.
>> >
>> > I doubt that, because the main user is likely to be udev scripts.
>> 
>> I'm entirely sure about this. I think it's not too far-fetched to think
>
> What exactly are you sure about about?

heh, missed a NOT there :-)

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

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.

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

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)