Hi Oliver, On Fri, May 20, 2016 at 04:19:59PM +0200, Oliver Neukum wrote: > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > Like I've told some of you guys, I'm trying to implement a bus for > > the Alternate Modes, but I'm still nowhere near finished with that > > one, so let's just get the class ready now. The altmode bus should in > > any case not affect the userspace interface proposed in this patch. > > Is this strictly divorced from USB PD? The bus can not be tied to the USB PD stack we will have in the kernel completely, or there is no change of using it with things like UCSI. It's going to be difficult to achieve that in any case as we simply won't be able to send and rescieve the VDMs with things like UCSI, but let's see. > How do you trigger a cable reset or a USB PD reset? There needs to be an API, but I'm sure that's not going to be a problem. The bus and the altmode specific drivers will reside inside kernel. But I'm getting the sense that you are thinking about having some responsibility of USB PD in userspace. Please correct me if I'm wrong. I don't think it will be possible. I think the role of userspace can only be the source for high level requests via this interface, like enter/exit mode and swap role, and receiving the status and details of the ports, but any knowledge about the requirements regarding those steps belongs to the kernel. This includes also the knowledge about stuff like mode dependencies, for example if cable plug has to be in a certain mode in order for the partner to be able to enter some specific mode, etc. 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
