On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote: > > Hi, > > Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> writes: > > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote: > >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote: > >> > Hi, > >> > > >> > Oliver Neukum <oneukum@xxxxxxxx> writes: > >> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote: > >> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote: > >> > >> > >> > Yes, but we need an API. We can't keep adding to it. So if that > >> > >> > is to be supported, it needs to be defined now. > >> > >> > >> > >> When you say API, do you mean the API the class provides to the > >> > >> drivers? Or did you mean ABI which would be the sysfs in this case? > >> > > > >> > > The API to user space. That is the point. We cannot break user space. > >> > > Once this sysfs API is upstream we are stuck with it. > >> > > >> > yeah, in fact I have been wondering if sysfs is the best interface to > >> > >> That is the discussion we must have. > >> > >> > userspace. I talked with Heikki a few days back about this; I was > >> > wondering if something like what the NFC folks did with netlink would be > >> > better here. > >> > >> I doubt that, because the main user is likely to be udev scripts. > >> They can easily deal with sysfs attributes. > > > > IMHO for high level interface like this, sysfs is ideal because of the > > simple fact that you only need a shell to access the files. netlink > > would make us depend on custom software, no? > > > > I'm not against using netlink, but what would be the benefit from it > > in this case? > > With HW we see nowadays, CC stack is hidden on some microcontroller, but > is it too far-fetched to consider a system where this is not the case ? There already are several USB PD stacks out there, like also Greg pointed out. > Specially when we consider things like power delivery which, I know, you > wanted to keep it out of this interface, however we would have two > 'stacks' competing for access to the same pins, right ? No. This class would be the top layer for the coming stack, where ever it ends up coming. The class is only the interface to the user space and nothing else. By saying we need to keep USB Type-C separate from USB PD I meant that the userspace access can not be mixed somewhere in layers of the USB PD/CC stack like it has been in the USB PD stacks I've seen so far. They assume that we always use the software USB PD stack with USB Type-C, which as we can see is not true when the stack is implemented in EC or firmware or some complex USB PD controller or what ever. However, the operations the userspace needs to do are exactly the same in both cases. - data role swapping - power role swapping (depends on USB PD) - Alternate Modes (depends on USB PD) And we really should not forget that we actually also have USB Type-C PHYs that can't do any USB PD communication over the CC pin, so USB PD is simply not always going to be available. But the data role swapping and also accessories are still available with them, as the do not need USB PD. This was the whole point with the class. It allows the different ways of dealing with Type-C ports to be exposed to userspace in the same way. > IIRC mode and role negotiation goes via CC pins using the power delivery > protocol. If I misunderstand anything, let me know. The data role swap with USB Type-C connectors is in no way tied to USB Power Delivery. The USB Type-C spec defines that when USB PD is available, DR_Swap USB PD function is used to swap the role, otherwise emulated disconnect will do the trick. Data role swapping is a must thing to have with USB Type-C connectors because of the fact that the role is selected randomly. Regardless was USB PD supported or not. Thanks, -- heikki -- 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
