Hi Michael, On Wed, Feb 06, 2019 at 10:36:22PM +0000, Michael Hsu wrote: > Your existing patch matches the SVID and then requires one-for-one ordering in > case either alt mode table has multiple mode entries for a particular SVID. And we'll fix that, but that does not solve the issue that I'm talking about. There are two separate issues here. That problem is a bug in the driver, but the major problem still is that you have separate alternate modes for the two DP pin assignments, and fixing the index handling does not help with that. According to the DP alt mode standard you do not have a separate mode for every supported DṔ pin assignment. When you change the DP alt mode pin assignment, the current mode is not exited and a new one entered. You stay in the DisplayPort mode, and simply re-configure using the DisplayPort Configure command. In your implementation however, the mode is existed, and a new one entered. So your implementation is not made according to the DisplayPort Alt Mode standard. I guess I have been able to explain just how big of a problem that is, and also how exactly we will have to handle it... Let's look at this from user space perspective. The user space should not need to be aware of the method used to interface with the USB Type-C connectors on the system. The kernel needs to hide that and supply unified interface to the user space which looks and behaves the same, _always_. In case of the DP alt mode, the user space should be allowed to expect the behaviour to follow the DP alt mode spec, so when the user space selects another pin assignment for the DP alt mode adapter, it should be a pass-fail operation without any side effects, just like explained in the VDM flows in the DP alt mode spec. But now with your PPM, there is a major side effect. Every time the user space selects a new DP pin assignment, the current mode is actually exited and a new mode entered. That is not standard behaviour. The user space will not just ignore the mode being exited. It has to react to it, most likely by assuming there was a fatal error somewhere. So in practice the user space is now forced to handle your connector as a special case. To protect the user space from that, and to keep the interface we provide to it consistent and predictable, we would have to handle your PPM completely separately. The user space will see only one connector DP alt mode no matter what. Even if you are unable change the PPM, the driver will still have to expose the two connector DP alternate modes as one connector alternate mode to the user space. That does not leave much use for the separated modes for the two pin assignments. The only thing they are providing in any case is the guarantee of the initial pin assignment, but as said, that we can guess in any case. Sorry for the long explanation. Br, -- heikki
