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

From: Krishna Kurapati

Date: Fri May 15 2026 - 11:58:15 EST




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@xxxxxxxxxxxxxxxx>
---
.../devicetree/bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
1 file changed, 2 insertions(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxxxxx>

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

Regards,
Krishna,