On Thu, 2016-02-18 at 12:30 +0200, Felipe Balbi wrote: > Hi, > > Oliver Neukum <oneukum@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
