Hi, On Sat, Feb 16, 2019 at 01:36:05AM +0000, Michael Hsu wrote: > > I think for clarity's sake I better fix the mode index issue now and send second > > version of these patches so we can concentrate on the bigger problem, the two > > connector DP alt modes. > > > > Agreed. Please update your patch for the mode index issue (being able to > reliably match partner mode index with the connector mode index returned by > UCSI). I'll finish some other task before coming back to this. We shouldn't be in any hurry with this. These are not going to v5.1 in any case. > > > Here's a method of avoiding the above dilemma: > > > - create partner sysfs alt mode nodes using UCSI GET_ALT_MODES (with > > > recipient == connector) > > > - also query UCSI GET_SUPPORTED_CAM > > > - create partner sysfs alt modes only if GET_SUPPORT_CAM returns 1 bit > > > for a particular connector alt mode index > > > > No! We must not hide stuff like that from the user. Even if the connector does > > not support a partner mode, we still show it to the user space. > > > > OK, but this means the "active" sysfs node for a partner mode (which is not > supported by GET_SUPPORTED_CAM) will always show "no". And writing "yes" > to it will silently fail... They will not always say "no", but you can not change the value without an alternate mode driver. > Did this intentional? Having some partner sysfs "active" nodes which do > nothing without any warning to user that they don't work? The key here is the driver. The user will know that partner alternate mode can't be operated unless it has been bind to a driver. The ABI for the alternate modes is defined for the typec bus, not the class. So in real world the user space applications will not start doing anything with an alternate mode, other than possible notifying the user of its existence, until the user space sees kernel event indicating that the alternate mode has been bind to a driver. Br, -- heikki
