lkml.org 
[lkml]   [2016]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
From
Date
On Thu, 2016-02-18 at 12:30 +0200, Felipe Balbi wrote:
> Hi,
>
> Oliver Neukum <oneukum@suse.com> writes:
> >> > 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?
>
> I'm not sure it's the best interface. My fear is that as new
> requirements/features come along, the amount of files will continue to
> grow.

That will happen. The alternative, however is a "typectool" or
"usbpdtool" which would need to be updated for new features.

> >> 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
>
> that assumes kernel always knows all possible alternate modes. What do
> we about bogus requests (request alternate mode X when X is not
> supported) ?

Do as the spec says: NACK it.

The questions which modes we offer, if we are a slave, still remains.
And I think the API is deficient in that regard. But again that question
is orthogonal of both issue, handling of bogus requests and how the
CC pins are exported.

Regards
Oliver


\
 
 \ /
  Last update: 2016-02-18 12:01    [W:0.221 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site