Re: [PATCH] soc: qcom: pmic_glink_altmode: Fix SVID=DP && unconnected edge case

[Konrad Dybcio]

On 3/9/26 11:43 AM, Neil Armstrong wrote:
> On 3/9/26 11:38, Konrad Dybcio wrote:
>> On 3/6/26 3:47 PM, Neil Armstrong wrote:
>>> On 3/6/26 12:20, Konrad Dybcio wrote:[...]
>>
>>> So what's the difference with :
>>>
>>>
>>> if (blah)
>>>      ...
>>> else (alt_port->svid == USB_TYPEC_DP_SID) {
>>>      if (alt_port->mux_ctrl == MUX_CTRL_STATE_NO_CONN)
>>>          pmic_glink_altmode_safe()
>>>      else
>>>          pmic_glink_altmode_enable_dp
>>> }
>>> else (blah)
>>>      ...
>>> else (blah)
>>>      ...
>>> else (alt_port->mux_ctrl == MUX_CTRL_STATE_NO_CONN)
>>>      pmic_glink_altmode_safe()
>>>
>>>
>>> Before, if mux_ctrl was MUX_CTRL_STATE_NO_CONN, it would set to safe mode whatever the svid,
>>> now it's either in the DP case or at the end.
>>>
>>> I don't see the difference here, except if your desire is to ignore
>>> the MUX_CTRL_STATE_NO_CONN for USB_TYPEC_TBT_SID and MUX_CTRL_STATE_TUNNELING.
>>>
>>> But it doesn't match the commit message at all.
>>
>>
>> The difference is the call to drm_aux_hpd_bridge_notify() in the DP
>> case, which isn't very visible in the patch diff.
> 
> Oh I see it now thx, but with this change MUX_CTRL_STATE_NO_CONN will be ignored for USB_TYPEC_TBT_SID and MUX_CTRL_STATE_TUNNELING.

Both are very much intended

For TBT SVID, it can only show up if STATE_TUNNELING

In the other case, STATE_TUNNELING and STATE_NO_CONN appear in the same
field, so only one of them can be present at once


Actually that's why I made the mistake of ignoring the DP case in the first
place - I assumed NO_CONN must not be valid with any active (alt)mode, but
the DP path was wired up in this.. interesting.. way

Konrad