[PATCH v2 2/4] dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra

[Krzysztof Kozlowski]

On 15/05/2026 17:36, Krishna Kurapati wrote:
> 
> 
> On 5/14/2026 8:07 PM, Krzysztof Kozlowski wrote:
>> On 14/05/2026 08:22, Krishna Kurapati wrote:
>>>
>>>
>>> On 5/14/2026 12:26 AM, Krzysztof Kozlowski wrote:
>>>> On 07/05/2026 13:37, Krishna Kurapati wrote:
>>>>>
>>>>>
>>>>> On 5/5/2026 7:30 PM, Krzysztof Kozlowski wrote:
>>>>>> On 05/05/2026 15:57, Krishna Kurapati wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 5/5/2026 6:59 PM, Krzysztof Kozlowski wrote:
>>>>>>>> On 05/05/2026 15:27, Krishna Kurapati wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/5/2026 4:22 PM, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 05/05/2026 12:49, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On Mon, May 04, 2026 at 10:36:57PM +0530, Krishna Kurapati wrote:
>>>>>>>>>>>> Declare the USB-C QMP PHY present on the Qualcomm Shikra platform.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Krishna Kurapati <krishna.kurapati at oss.qualcomm.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>       .../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml      | 2 ++
>>>>>>>>>>>>       1 file changed, 2 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
>>>>>>>>>>
>>>>>>>>>> ... and then I looked at the driver. So un-reviewed. Devices are clearly
>>>>>>>>>> compatible. If not, explain what is not compatible.
>>>>>>>>>>
>>>>>>>>> Talos uses GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>>>>>
>>>>>>>>> In Shikra, we are using GCC_USB3_PRIM_PHY_COM_AUX_CLK. We don't have
>>>>>>>>> GCC_USB3_PRIM_PHY_AUX_CLK.
>>>>>>>>>
>>>>>>>>> Hence, I didn't use a fallback compatible.
>>>>>>>>
>>>>>>>> This still explains nothing. How different clock makes interface for SW
>>>>>>>> incompatible exactly?
>>>>>>>>
>>>>>>> So I went by the naming. AUX vs COM_AUX.
>>>>>>
>>>>>> The naming does not matter. If the clock is called
>>>>>> "no_one_expects_spanish_inquisition", does that make software
>>>>>> incompatible? Why would the name itself matter?
>>>>>>
>>>>>>>
>>>>>>> Can I use a fallback compatible and in DT vote for "COM_AUX" clock with
>>>>>>> clock-names mentioning "aux" ?
>>>>>>
>>>>>> I don't know, I asked what is different in software interface.
>>>>>>
>>>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>>     I checked with the hw team here and found out two things.
>>>>>
>>>>>     1. Shikra is a spinoff of Agatti and its sw interface (clocks used and
>>>>> regulators used) is the same as agatti.
>>>>>
>>>>>     2. I thought we could use qcm2290 as a fallback since the phy register
>>>>> init sequence is the same for Talos/Shikra/Agatti. The difference
>>>>> between Talos and agatti when checked in the driver was the init load
>>>>> settings. I checked with the hw team and they suggested using the init
>>>>> load settings which talos was using.
>>>>>
>>>>>     Hence both these compatibles (qcm2290 and qcs615) cannot be used as
>>>>> fallback for Shikra.
>>>>
>>>> Then I do not understand why you are using qcs615_usb3phy_cfg for
>>>> Shikra. You say that the initialization is different, but you use
>>>> exactly the same initialization. So in a meaning of compatibility
>>>> between hardware for Devicetree they are compatible.
>>>>
>>> Hi Krzysztof,
>>>
>>>    There are 3 things:
>>>
>>> 1. Clocks used:
>>> -> Talos supports AUX Clock since it supports DP over USB.
>>> -> Agatti and Shikra use COM_AUX clock since they dont support DP over USB.
>>>
>>> 2. Phy register Init sequence - same for all 3 targets
>>>
>>> 3. Regulator init load:
>>> -> Different for both Talos and Agatti
>>> -> Recommendation is to use Talos regulator load values.
>>>
>>> SW interface wise, shikra is comaptible with agatti. If we use agatti as
>>> fallback, we would end up using the platform data of Agatti where the
>>> regulator init load is not suitable for Shikra. Hence not using Agatti
>>> as fallback.
>>>
>>> Coming to driver changes, I used qcs615_cfg because it has required phy
>>> register sequence and regulator init load as needed by shikra.
>>
>> So is it compatible with QCS615? If not, then something is incomplete or
>> confusing. The driver uses the same software interface.
>>
> Sorry for the confusion. The Talos compatible represents the USB/DP PHY 
> with aux clock input, while Shikra is a USB-only PHY with com_aux input 
> clock, so the two PHYs are not compatible with each other.
> 
> In the Linux driver implementation the match data is currently used only 
> to affect the init sequence and regulator init load and here Shikra can 
> reuse the Talos match data structure.
> 

I wrote three times already, not writing anymore. You still did not
answer the problem here.

Best regards,
Krzysztof