Skip to contentSkip to conversation

usb: typec: ucsi: Preliminary support for alternate modes

PATCH New Heikki Krogerus 1 participant 1 message Feb 6, 2019 USB

lore
Share & tools
lore

Heikki Krogerus

author
#0 lore raw

PATCH 4/5 usb: typec: ucsi: Preliminary support for alternate modes

Hi Michael,

Quoted 17 lines · Michael Hsu

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).

Quoted 4 lines

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,