Hi Michael, On Fri, Feb 01, 2019 at 10:02:19PM +0000, Michael Hsu wrote: > Hi Heikki, the use of "con->port_altmode[cur]->mode" (which is a 1-based > index, not a 32-bit mode VDO) can cause incorrect matches if the > GET_ALTERNATE_MODES returns different ordering for recipient=connector and > recipient=sop for a particular svid. > > For example, UCSI command GET_ALTERNATE_MODES with recipient=connector returns > [0] SVID=0xff01, ModeVDO=0x00000405 (Mode = 1) > [1] SVID=0xff01, ModeVDO=0x00000805 (Mode = 2) > And UCSI command GET_ALTERNATE_MODES with recipient=sop returns > [0] SVID=0xff01, ModeVDO=0x00000c05 (Mode = 1) > > Then when DP alternate mode with pin D is active, GET_CURRENT_CAM returns > index 1 (connector alternate mode = 1, i.e. SVID=0xff01, Mode=2, > ModeVDO=0x00000805). > But, the function will be unable to match it with partner_alt_mode > corresponding to (SVID=0xff01,Mode=1). > > Can you compare against 32-bit VDO instead of ->mode? Also, use '&' bitwise > AND operator when masking the partner's mode VDO (0x0c05) against the > connector's mode VDO (0x405 or 0x805) to determine it there is an alternate > mode match. FYI, I'll improve the matching done ucsi_altmode_update_active(), it is true that we cannot rely on the the mode index, but note I'm not going to support those masks at this point. I'm still expecting that the firmware can be updated. The UCSI data structures really need to supply consistent information to the OS, regardless of the PPM implementation. I threw some ideas how we should be able to determine the DP pin assignment with more certainty in my previous mail, in case the currently executed "guessing" is not reliable enough for you guys. Let me know what you think. thanks, -- heikki
