On Tue, May 10, 2016 at 08:14:34PM -0700, Guenter Roeck wrote: > Heikki, > > On 05/06/2016 01:08 AM, Heikki Krogerus wrote: > > Hi, > > > [ ... ] > > > > I don't have not made any new code for the class driver yet, but I'm > > attempting to prepare v2 next week. > > > Would it make sense to send feedback about v1 now, or should I wait for v2 ? I don't think I'm able to send v2 today, or even tomorrow, so feel free to give the feedback. Just be aware that I've rewritten the alternate mode part completely. I'm creating a separate device for the partner and also the cable during connection. I'm also already going to introduce a small bus for the AltModes. It's clear that we need to have AltMode specific drivers. The generic parts can't take care of all the AltMode specific requirements and VDMs. The bus will give us a nice way to bind those drivers to the actual AltModes a partner and the cable plugs offer. So if there are dependencies between the altmodes, for example if the cable plugs needs to be in a certain mode in order for the partner to be able to function in some specific mode, the responsibility of taking care of those will fall primarily to in the AltMode drivers. So not userspace. The AltMode drivers actually are useful also as they can be part of the relevant frameworks, for example DP in some graphics framework. For example in case of DP, the number of lanes (I guess 2 or 4) should be ideally known if I have understood correctly. Knowledge about the connection seems to also be needed, and I've so far seen some pretty weird solutions for hotplug events with the DP AltMode. With the driver we should be able to avoid those. But in any case, every SVIDs a partner (or plug) offers will have their own device registered with the partner (or cable) itself as parent in this design. I'm expecting a little bit of conversation about this plan, but right now I feel confident about it. How does this sound to you? Cheers, -- 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
