On Thu, 2016-02-18 at 09:08 +0200, Felipe Balbi wrote: > Oliver Neukum <oneukum@xxxxxxxx> writes: > >> Oliver Neukum <oneukum@xxxxxxxx> writes: Hi, > > 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? > >> 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. Well, how else would we send vendor specific messages? > 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. Indeed. > 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 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. 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
