Messages in this thread | | | Subject | Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface | From | Oliver Neukum <> | Date | Thu, 18 Feb 2016 11:40:03 +0100 |
| |
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
| |