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. >> 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) ? > 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. fair enough. -- balbi
Attachment:
signature.asc
Description: PGP signature
