Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 5/5] phy: qcom-qusb2: add QUSB2 support for ipq5210
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Add the phy init sequence for the Super Speed ports found
on ipq5210.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index eb93015be841..749106175742 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -929,6 +929,9 @@ static const struct phy_ops qusb2_phy_gen_ops = {
 
 static const struct of_device_id qusb2_phy_of_match_table[] = {
 	{
+		.compatible	= "qcom,ipq5210-qusb2-phy",
+		.data		= &ipq6018_phy_cfg,
+	}, {
 		.compatible	= "qcom,ipq5424-qusb2-phy",
 		.data		= &ipq6018_phy_cfg,
 	}, {

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* [PATCH 3/5] dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Update dt-bindings to add ipq5210 to USB DWC3 controller list.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index a7f58114c02e..f8e0819be894 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -26,6 +26,7 @@ properties:
       - enum:
           - qcom,ipq4019-dwc3
           - qcom,ipq5018-dwc3
+          - qcom,ipq5210-dwc3
           - qcom,ipq5332-dwc3
           - qcom,ipq5424-dwc3
           - qcom,ipq6018-dwc3

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* [PATCH 4/5] phy: qcom: qmp: Enable ipq5210 support
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Enable QMP USB3 phy support for ipq5210 SoC.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
index b0ecd5ba2464..8d3d7e39697e 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
@@ -2449,6 +2449,9 @@ static const struct of_device_id qmp_usb_of_match_table[] = {
 	{
 		.compatible = "qcom,glymur-qmp-usb3-uni-phy",
 		.data = &glymur_usb3_uniphy_cfg,
+	}, {
+		.compatible = "qcom,ipq5210-qmp-usb3-phy",
+		.data = &ipq9574_usb3phy_cfg,
 	}, {
 		.compatible = "qcom,ipq5424-qmp-usb3-phy",
 		.data = &ipq9574_usb3phy_cfg,

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* [PATCH 2/5] dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Add dt-bindings for USB3 PHY found on Qualcomm ipq5210

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml          | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
index 623c2f8c7d22..bdb80371ea68 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     enum:
       - qcom,glymur-qmp-usb3-uni-phy
+      - qcom,ipq5210-qmp-usb3-phy
       - qcom,ipq5424-qmp-usb3-phy
       - qcom,ipq6018-qmp-usb3-phy
       - qcom,ipq8074-qmp-usb3-phy

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* [PATCH 1/5] dt-bindings: phy: qcom,qusb2: Document ipq5210 compatible
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan
In-Reply-To: <20260515-usb2phy-v1-0-5f8338d466bf@oss.qualcomm.com>

Document the compatible string used for the qusb2 phy in ipq5210.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 39851ba9de43..509cadd31adf 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -18,6 +18,7 @@ properties:
     oneOf:
       - items:
           - enum:
+              - qcom,ipq5210-qusb2-phy
               - qcom,ipq5424-qusb2-phy
               - qcom,ipq6018-qusb2-phy
               - qcom,ipq8074-qusb2-phy

-- 
2.34.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* [PATCH 0/5] Enable ipq5210 USB support
From: Varadarajan Narayanan @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Wesley Cheng, Greg Kroah-Hartman
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-usb,
	Varadarajan Narayanan

The ipq5210 SoC has both USB2.0 and USB3.0 controllers. The USB3.0
can connect to either of USB2.0 or USB3.0 phy and operate in the
respective mode.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Varadarajan Narayanan (5):
      dt-bindings: phy: qcom,qusb2: Document ipq5210 compatible
      dt-bindings: phy: qcom,qmp-usb: Add ipq5210 USB3 PHY
      dt-bindings: usb: qcom,dwc3: Add ipq5210 to USB DWC3 bindings
      phy: qcom: qmp: Enable ipq5210 support
      phy: qcom-qusb2: add QUSB2 support for ipq5210

 Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml              | 1 +
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml        | 1 +
 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml                   | 1 +
 drivers/phy/qualcomm/phy-qcom-qmp-usb.c                                | 3 +++
 drivers/phy/qualcomm/phy-qcom-qusb2.c                                  | 3 +++
 5 files changed, 9 insertions(+)
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260515-usb2phy-bd850e1fb3de

Best regards,
-- 
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Krzysztof Kozlowski @ 2026-05-15 10:47 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260514-pci-phy-v1-1-482429192746@oss.qualcomm.com>

On Thu, May 14, 2026 at 09:28:28AM +0530, Varadarajan Narayanan wrote:
> Document the PCIe phy on the ipq5210 platform using the ipq9574 bindings
> as a fallback, since the PCIe phy on the ipq5210 is similar to ipq9574.
> 
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> index f60804687412..1ac31439c20a 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
> @@ -17,6 +17,7 @@ properties:
>    compatible:
>      oneOf:
>        - enum:
> +          - qcom,ipq5210-qmp-gen3x1-pcie-phy

5210-qmp-gen3x1 here

>            - qcom,ipq6018-qmp-pcie-phy
>            - qcom,ipq8074-qmp-gen3-pcie-phy
>            - qcom,ipq8074-qmp-pcie-phy
> @@ -24,10 +25,12 @@ properties:
>            - qcom,ipq9574-qmp-gen3x2-pcie-phy
>        - items:
>            - enum:
> +              - qcom,ipq5210-qmp-gen3x1-pcie-phy

and here?

>                - qcom,ipq5424-qmp-gen3x1-pcie-phy
>            - const: qcom,ipq9574-qmp-gen3x1-pcie-phy

So it is or it is not compatible with 9574?

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Krzysztof Kozlowski @ 2026-05-15 10:45 UTC (permalink / raw)
  To: Varadarajan Narayanan
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260514-pci-phy-v1-1-482429192746@oss.qualcomm.com>

On Thu, May 14, 2026 at 09:28:28AM +0530, Varadarajan Narayanan wrote:
> Document the PCIe phy on the ipq5210 platform using the ipq9574 bindings
> as a fallback, since the PCIe phy on the ipq5210 is similar to ipq9574.

I don't understand that. You claim to use fallback only because
they are "similar", which is clearly incomplete reason. Many things are
similar. And your driver explicitly does not use fallback, which MUST be
explained WHY.

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: qcom: Introduce Shikra SoC base dtsi
From: Konrad Dybcio @ 2026-05-15 10:37 UTC (permalink / raw)
  To: Komal Bajaj, Bjorn Andersson, Konrad Dybcio, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
	Wesley Cheng, Ulf Hansson
  Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
	Imran Shaik, Krishna Kurapati, Monish Chunara, Rakesh Kota,
	Raviteja Laggyshetty, Sneh Mankad, Vishnu Santhosh, Xueyao An
In-Reply-To: <20260512-shikra-dt-v1-2-716438330dd0@oss.qualcomm.com>

On 5/12/26 6:08 AM, Komal Bajaj wrote:
> Add initial device tree support for the Qualcomm Shikra SoC,
> an IoT-focused platform built around a heterogeneous CPU cluster
> (Cortex-A55 + Cortex-A78C) with RPM-based power and clock management.

[...]

> +	pmu {
> +		compatible = "arm,armv8-pmuv3";
> +		interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_HIGH>;

Considering there's 2 core types, you may need something like:

9ce52e908bd5 ("arm64: dts: qcom: sm8650: switch to interrupt-cells 4 to add PPI partitions")
2c06e0797c32 ("arm64: dts: qcom: sm8650: add PPI interrupt partitions for the ARM PMUs")

> +	};
> +
> +	psci: psci {

Unused label, please drop

otherwise:

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context
From: David Laight @ 2026-05-15  9:47 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Claudiu Beznea, yoshihiro.shimoda.uh, vkoul, neil.armstrong,
	geert+renesas, magnus.damm, prabhakar.mahadev-lad.rj,
	linux-renesas-soc, linux-phy, linux-kernel, Claudiu Beznea,
	stable, Nobuhiro Iwamatsu
In-Reply-To: <agY8NAyCcHkhBvBv@duo.ucw.cz>

On Thu, 14 May 2026 23:18:44 +0200
Pavel Machek <pavel@nabladev.com> wrote:

> Hi!
> 
> > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > 
> > The OTG PHY initialization sequence needs to wait for 20 ms at a specific
> > step, as described in commit 72c0339c115b ("phy: renesas:
> > rcar-gen3-usb2: follow the hardware manual procedure").
> > 
> > Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware
> > registers and driver data") tried to address various problems in the
> > rcar-gen3-usb2 driver and converted the mutex protecting HW register
> > accesses to a spin lock, leaving, however, a long delay in the critical
> > section protected by the spin lock. This may become a problem,
> > especially on RT kernels.
> > 
> > To address this, release the spin lock before sleeping for 20 ms as
> > required by the HW manual and reacquire it afterwards. To avoid other
> > threads entering the critical section and configuring the HW while the
> > software is waiting for the OTG initialization to complete, introduce the
> > otg_initializing variable alongside the otg_init_done completion. Any
> > other thread trying to configure the HW while the OTG PHY initialization
> > is in progress waits for the completion instead of immediately returning
> > errors to PHY users. The IRQs were also disabled while waiting for the OTG
> > PHY initialization to complete, as the interrupt handler may also apply HW
> > settings.  
> 
> Just... there has to be a better way.
> 
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +static int rcar_gen3_phy_wait_otg_init(struct rcar_gen3_chan *channel,
> > +				       unsigned long *flags)
> > +{
> > +	unsigned long timeout = msecs_to_jiffies(25);
> > +	unsigned long ret = 1;
> > +
> > +	lockdep_assert_held(&channel->lock);
> > +
> > +	/*
> > +	 * The OTG can be initialized only once and needs to release the lock
> > +	 * and wait for 20 ms due to hardware constraints. Wait for the OTG PHY
> > +	 * initialization to complete if another PHY executes configuration
> > +	 * code while the OTG PHY is waiting. This avoids returning failures to
> > +	 * PHY users.
> > +	 */
> > +	if (READ_ONCE(channel->otg_initializing)) {
> > +		spin_unlock_irqrestore(&channel->lock, *flags);  
> 
> This is not nice, passing flags between functions like this is a red flag.

It would be better to just inline the code.
And I'd guess you need to redo the initial tests after re-acquiring the lock?
Or even need to do a state change/reference count before releasing the
lock to stop other threads 'doing anything nasty'.

-- David

> 
> You are only accessing otg_initializing under the spinlock. That means
> that READ_ONCE is reduntant.
> 
> But AFAICT spinlock is only held over this function to protect
> channel->otg_initializing access. I suspect correct answer here is
> getting rid of spinlock over this function, and using
> test_bit(BIT_INITIALIZING, ...) or something similar.
> 
> Best regards,
> 								Pavel
> 


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH phy-next 1/2] dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHY
From: Ioana Ciornei @ 2026-05-15  9:23 UTC (permalink / raw)
  To: Conor Dooley
  Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, johan, linux-phy,
	devicetree, linux-kernel
In-Reply-To: <20260514-scorebook-uproot-c9766b3e1be4@spud>

On Thu, May 14, 2026 at 07:09:13PM +0100, Conor Dooley wrote:
> On Wed, May 13, 2026 at 09:51:02PM +0300, Ioana Ciornei wrote:
> > Add device tree binding for the TI DS125DF111 Retimer PHY.
> > 
> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > ---
> >  .../bindings/phy/ti,ds125df111.yaml           | 46 +++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/ti,ds125df111.yaml
> > 

(...)

> > +
> > +examples:
> > +  - |
> > +    i2c {
> > +      #address-cells = <1>;
> > +      #size-cells = <0>;
> > +
> > +      ti_retimer: retimer@18 {
> 
> Drop the unused label here please. How come the node name isn't phy@
> btw?
> Otherwise,
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: changes-requested

Ok, will drop the label, change the node name to phy and add your
Acked-by.

Thanks!

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: qcom: Document Shikra and its EVK boards
From: Krzysztof Kozlowski @ 2026-05-15  8:51 UTC (permalink / raw)
  To: Komal Bajaj
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
	Ulf Hansson, linux-arm-msm, devicetree, linux-kernel, linux-phy,
	linux-mmc
In-Reply-To: <20260512-shikra-dt-v1-1-716438330dd0@oss.qualcomm.com>

On Tue, May 12, 2026 at 09:38:04AM +0530, Komal Bajaj wrote:
> Shikra is a Qualcomm IoT SoC available in a System-on-Module (SoM)
> form factor. The SoM integrates the Shikra SoC, PMICs, and essential
> passives, and is designed to be mounted on carrier boards.
> 
> One SoM variant is introduced:
>   - CQM: retail variant with integrated modem (PM4125 PMIC)
> 
> Two EVK boards are supported:
>   - shikra-cqm-evk: pairs with the CQM SoM
>   - shikra-cqs-evk: pairs with the CQM SoM, with no modem support

s/CQM/CQS/

but anyway I would prefer to use full product names from
include/dt-bindings/arm/qcom,ids.h (so CQXXXXM).

> 
> Each EVK provides debug UART, USB, and other peripheral interfaces.
> 
> Add compatible strings for the CQM SoM variant and its two
> corresponding EVK boards.
> 
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 2741c07e9f41..f041d71d7957 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -963,6 +963,13 @@ properties:
>            - const: qcom,qcs9100
>            - const: qcom,sa8775p
>  
> +      - items:
> +          - enum:
> +              - qcom,shikra-cqm-evk
> +              - qcom,shikra-cqs-evk
> +          - const: qcom,shikra-cqm-som

This is not accurate. The SoM has physically different SoC - either CQM
or CQS. You either need two lists, like Toradex is doing (e.g.
toradex,verdin-imx95), or enum in the middle of the lists, like Renesas
is doing (e.g. renesas,rzt2h-evk).

I prefer the first option, so Toradex choice.

But for sure you do not get the third solution... Really, you are not
supposed to invent these things, but look at existing solutions (and I
was mentioning Toradex during internal meetings whenever someone asked
me how the SoM and carrier should be organized).

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: net: Document Infineon/Intel XMM6260 modem
From: Svyatoslav Ryhel @ 2026-05-15  8:39 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260515-precious-ginger-lori-d1fde7@quoll>

пт, 15 трав. 2026 р. о 11:18 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Mon, May 11, 2026 at 04:56:58PM +0300, Svyatoslav Ryhel wrote:
> > +  ap-wake-gpios:
> > +    description: GPIO connected to the EINT3 pin
> > +    maxItems: 1
> > +
> > +  cp-wake-gpios:
> > +    description: GPIO connected to the EINT2 pin
> > +    maxItems: 1
> > +
> > +  phys:
> > +    maxItems: 1
> > +
> > +  vbat-supply:
> > +    description: Supply connected to the VBAT lines.
>
> This should be rather name of the pin on this device, not the provider
> name. VBAT suggests the latter. Please double check.
>

There is no documentation on this device from Infineon, I have used
schematics of the P895 where this modem is used. According to it power
supply is connected to pin with name VBAT (and yes, I am not mixing it
up since supplies have different names)

> Rest looks fine, with respect to Sashiko comment on description:
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH v1 5/6] dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY
From: Svyatoslav Ryhel @ 2026-05-15  8:37 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260515-utopian-malamute-of-patience-367e8e@quoll>

пт, 15 трав. 2026 р. о 11:20 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Mon, May 11, 2026 at 04:57:00PM +0300, Svyatoslav Ryhel wrote:
> > Document the XMM6260 PHY used by various devices based on the Nvidia Tegra
> > SoC, describing its usage
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  .../bindings/phy/nvidia,tegra-xmm6260.yaml    | 58 +++++++++++++++++++
> >  1 file changed, 58 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> > new file mode 100644
> > index 000000000000..0346433c9772
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> > @@ -0,0 +1,58 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/nvidia,tegra-xmm6260.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Nvidia Tegra PHY for XMM6260 modem
>
> XMM6260 is Infineon modem, so any combination with nvidia,tegra is very
> confusing.
>

May you please suggest how to adjust the name then? Thank you.

> > +
> > +description:
> > +  A hardware configuration used in Tegra SoCs to provide proper interaction
> > +  between the application processor and the modem, as well as control over
> > +  one of the SoC's USB lines for the modem.
> > +
> > +maintainers:
> > +  - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra-xmm6260
>
> Also here.
>
> What sort of phy is this? So far looks more like a software construct.
>

Infineon XMM6260 does not work as an ordinary USB modem, it is a
standalone CPU which just exposes itself to AP via USB. In order to do
so, it has to have control over a USB bus of AP which is dedicated to
it. In case of Tegra - XMM6260 interaction it looks like this: second
Tegra USB controller is set into HSIC mode and is dedicated solely to
the modem, modem controls this USB bus. Then the main XMM6260 driver
performs power and init sequence and once it is ready it calls phy to
register controller. Phy has its own supply, controls USB controller
de/register and using enable GPIO sends signal to modem to proceed.
Additionally, since some XMM626 versions have a few steps to setup
exposing different USB devices, phy handles controller reinit for each
step. If treat XMM6260 as an simple USB modem it will never init.

One more benefit of having PHY is that modem driver itself is generic
and PHY handles SoC specific configurations required by the modem.
Since this modem was used on a variety of different SoC's (Exynos and
OMAP for example) they can reuse modem's driver and provide only PHY
which handles modem interactions with the USB bus.

> Best regards,
> Krzysztof
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH v1 5/6] dt-bindings: phy: tegra: Document Nvidia Tegra XMM6260 PHY
From: Krzysztof Kozlowski @ 2026-05-15  8:20 UTC (permalink / raw)
  To: Svyatoslav Ryhel
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260511135703.62470-6-clamor95@gmail.com>

On Mon, May 11, 2026 at 04:57:00PM +0300, Svyatoslav Ryhel wrote:
> Document the XMM6260 PHY used by various devices based on the Nvidia Tegra
> SoC, describing its usage
> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
>  .../bindings/phy/nvidia,tegra-xmm6260.yaml    | 58 +++++++++++++++++++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> new file mode 100644
> index 000000000000..0346433c9772
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xmm6260.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nvidia,tegra-xmm6260.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nvidia Tegra PHY for XMM6260 modem

XMM6260 is Infineon modem, so any combination with nvidia,tegra is very
confusing.

> +
> +description:
> +  A hardware configuration used in Tegra SoCs to provide proper interaction
> +  between the application processor and the modem, as well as control over
> +  one of the SoC's USB lines for the modem.
> +
> +maintainers:
> +  - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra-xmm6260

Also here.

What sort of phy is this? So far looks more like a software construct.

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH v1 3/6] dt-bindings: net: Document Infineon/Intel XMM6260 modem
From: Krzysztof Kozlowski @ 2026-05-15  8:18 UTC (permalink / raw)
  To: Svyatoslav Ryhel
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Vinod Koul, Neil Armstrong, Thierry Reding, Jonathan Hunter,
	Greg Kroah-Hartman, Peter Chen, netdev, devicetree, linux-kernel,
	linux-phy, linux-tegra, linux-usb
In-Reply-To: <20260511135703.62470-4-clamor95@gmail.com>

On Mon, May 11, 2026 at 04:56:58PM +0300, Svyatoslav Ryhel wrote:
> +  ap-wake-gpios:
> +    description: GPIO connected to the EINT3 pin
> +    maxItems: 1
> +
> +  cp-wake-gpios:
> +    description: GPIO connected to the EINT2 pin
> +    maxItems: 1
> +
> +  phys:
> +    maxItems: 1
> +
> +  vbat-supply:
> +    description: Supply connected to the VBAT lines.

This should be rather name of the pin on this device, not the provider
name. VBAT suggests the latter. Please double check.

Rest looks fine, with respect to Sashiko comment on description:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH v1 1/6] dt-bindings: usb: ci-hdrc-usb2: Document nvidia,external-control property
From: Krzysztof Kozlowski @ 2026-05-15  8:15 UTC (permalink / raw)
  To: Svyatoslav Ryhel
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
	devicetree, linux-kernel, linux-phy, linux-tegra, linux-usb
In-Reply-To: <CAPVz0n2GkucfHqvgusF=K_KakqaJmZSLP=8VYMyVT5HAVDD_XQ@mail.gmail.com>

On Wed, May 13, 2026 at 08:34:45PM +0300, Svyatoslav Ryhel wrote:
> пн, 11 трав. 2026 р. о 16:57 Svyatoslav Ryhel <clamor95@gmail.com> пише:
> >
> > Document the nvidia,external-control property required, for example, for
> > USB lines in HSIC mode connected to a modem, where the modem requires
> > precise control over the USB bus to properly enumerate all its stages and
> > intermediate devices.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > index 691d6cf02c27..a13c1ef49a57 100644
> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> > @@ -75,6 +75,13 @@ properties:
> >      type: boolean
> >      deprecated: true
> >
> > +  nvidia,external-control:
> > +    description:
> > +      Indicates that the controller is configured externally and that the host
> > +      should not attempt to touch it. Usually used by a modem which requires
> > +      precise bus configuration.
> > +    type: boolean
> > +
> 
> Would schema maintainers mind if I create separate schema like
> chipidea,usb2-imx.yaml is handled? At the moment ci-hdrc-usb2 holds a
> mixed properties of several SoC and can cause unwanted/unsupported
> node combinations.

This is a good idea. All nvidia devices and their properties should be
moved there.

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: 回复: Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Hongling Zeng @ 2026-05-15  7:32 UTC (permalink / raw)
  To: Vinod Koul, 曾红玲
  Cc: sashiko-bot, linux-phy, neil.armstrong, olteanv
In-Reply-To: <agbCaI490NQN37te@vaman>

Hi Vinod,

Apologies for the earlier HTML mail — that was unintentional.

I have resent the patches. They include:
- Fix for clock resource leak on probe errors
- Correct handling of -EPROBE_DEFER for sysclk and SATA refclk

Please let me know if anything else needs adjustment.

Best regards,
Hongling

在 2026年05月15日 14:51, Vinod Koul 写道:
> On 15-05-26, 13:14, 曾红玲 wrote:
>
> Please send text only emails on the list!!!
>
>> <div style="font-family:Microsoft YaHei;font-size:14px;color:#000000;" class="l_node_has_color"><div>Hi,</div>
>> <div>Thanks for pointing out the probe deferral problems.</div>
>> <div>Both issues you mentioned are valid:</div>
>> <ul>
>> <li>
>> <div>sysclk should not convert <code>-EPROBE_DEFER</code>to <code>-EINVAL</code>.</div>
>> </li>
>> <li>
>> <div>SATA refclk must not ignore <code>-EPROBE_DEFER</code>, although <code>-ENOENT</code>can still be tolerated for compatibility.</div>
>> </li>
>> </ul>
>> <div>I have fix them together with the clock leak fix in .</div>
>> <div>[PATCH 1/2 v3] phy: ti: pipe3: Fix clock resource leak on probe errors</div>
>> <div>[PATCH 2/2] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources</div>
>> <div>&nbsp;</div>
>> <div>Appreciate the careful review.</div>
>> <div>&nbsp;</div>
>> <div>Regards,</div>
>> <div>Hongling</div>
>> <p>&nbsp;</p>
>> <div id="signatureTop"></div>
>> <div id="cs2c_re" style="margin-left: 0.5em; padding-left: 0.5em; border-left: 1px solid #cacaca; -webkit-user-modify: read-only; -moz-user-modify: read-only; -ms-user-modify: read-only; -o-user-modify: read-only;"><br><br><br>
>> <div style="background-color: #f8f8f8; padding: 8px 10px; font-family: Microsoft YaHei; font-size: 14px; color: #000;"><strong>主&nbsp;&nbsp;&nbsp;题：</strong><span id="cs2c_subject">Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors</span> <br><strong>日&nbsp;&nbsp;&nbsp;期：</strong><span id="cs2c_date">2026年05月15日10:32</span> <br><strong>发件人：</strong><span id="cs2c_from">sashiko-bot</span> <br><strong>收件人：</strong><span id="cs2c_to" style="word-break: break-all;">sashiko-bot</span> <br><strong>抄送人：</strong><span id="cs2c_to" style="word-break: break-all;">linux-phy,neil.armstrong,olteanv,vkoul</span></div>
>> <br>
>> <div id="cs2c_content">Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Masking of -EPROBE_DEFER to -EINVAL when fetching sysclk. - [High] Ignoring -EPROBE_DEFER for the SATA refclk. -- commit 4f2fbd627ee80455cac194a4ae1b559d48180075 Author: Hongling Zeng &lt;zenghongling@kylinos.cn&gt; phy: ti: pipe3: Fix clock resource leak on probe errors When devm_phy_create() or devm_of_phy_provider_register() fails, the refclk that was enabled earlier is not disabled, causing a resource leak. Fix this by adding an error handling path to disable the clock when these functions fail. &gt; diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c &gt; index b5543b5c674c8..58fbc3b278130 100644 &gt; --- a/drivers/phy/ti/phy-ti-pipe3.c &gt; +++ b/drivers/phy/ti/phy-ti-pipe3.c [ ... ] This isn't a regression introduced by this patch, but looking at ti_pipe3_get_clk() called earlier in the probe sequence: drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() { ... if (phy-&gt;mode != PIPE3_MODE_PCIE || phy-&gt;phy_power_syscon) { phy-&gt;sys_clk = devm_clk_get(dev, "sysclk"); if (IS_ERR(phy-&gt;sys_clk)) { dev_err(dev, "unable to get sysclk\n"); return -EINVAL; } } ... } Does this code mask -EPROBE_DEFER to -EINVAL when fetching sysclk? If devm_clk_get() for the sysclk returns -EPROBE_DEFER, the function explicitly converts the error and returns -EINVAL. This completely breaks the lifecycle of probe deferral for the sysclk resource. Instead of retrying when the clock provider becomes available later in the boot process, the driver initialization fails permanently, rendering the PHY device unusable on systems with non-deterministic probe orders. Similarly, looking at the SATA refclk handling in the same function: drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() { ... phy-&gt;refclk = devm_clk_get(dev, "refclk"); if (IS_ERR(phy-&gt;refclk)) { dev_err(dev, "unable to get refclk\n"); /* older DTBs have missing refclk in SATA PHY * so don't bail out in case of SATA PHY. */ if (phy-&gt;mode != PIPE3_MODE_SATA) return PTR_ERR(phy-&gt;refclk); } ... } Are errors returned by devm_clk_get() for the refclk ignored when the mode is PIPE3_MODE_SATA? While ignoring -ENOENT is intentionally done to support older DTBs missing the clock, indiscriminately ignoring -EPROBE_DEFER breaks the probe deferral mechanism. The driver will proceed immediately without waiting for the clock provider to probe, resulting in the SATA PHY being initialized without its required reference clock and subsequently failing to function properly. -- Sashiko AI review · https://sashiko.dev/#/patchset/20260515021635.13444-1-zenghongling@kylinos.cn?part=1 &lt;/zenghongling@kylinos.cn&gt;</div>
>> </div>
>> <p>&nbsp;</p>
>> <p>&nbsp;</p>
>> <div id="signatureBom">
>> <div>
>> <p>&nbsp;</p>
>> <br>
>> <p style="color: #000; font-size: 16px;">---</p>
>> <div id="cs2c_mail_sigature" style="color: #000; font-size: 16px; font-family: Microsoft YaHei;"></div>
>> <p>&nbsp;</p>
>> </div>
>> </div></div>



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: [PATCH 01/10] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add Hawi compatibles
From: Krzysztof Kozlowski @ 2026-05-15  7:13 UTC (permalink / raw)
  To: Matthew Leung
  Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260508-hawi-phy-pcie-v1-1-237b894353fc@oss.qualcomm.com>

On Fri, May 08, 2026 at 11:31:16PM +0000, Matthew Leung wrote:
> Document the compatibles for the Gen3 x2 and Gen4 x1 QMP PCIe PHYs found
> on the Hawi platform.
> 
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml         | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* Re: 回复: Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Vinod Koul @ 2026-05-15  6:51 UTC (permalink / raw)
  To: 曾红玲
  Cc: sashiko-bot, linux-phy, neil.armstrong, olteanv, zhongling0719
In-Reply-To: <1hn0m80l7wbt-1hn5kvizr04q@nsmail8.2--kylin--1>

On 15-05-26, 13:14, 曾红玲 wrote:

Please send text only emails on the list!!!

> <div style="font-family:Microsoft YaHei;font-size:14px;color:#000000;" class="l_node_has_color"><div>Hi,</div>
> <div>Thanks for pointing out the probe deferral problems.</div>
> <div>Both issues you mentioned are valid:</div>
> <ul>
> <li>
> <div>sysclk should not convert <code>-EPROBE_DEFER</code>to <code>-EINVAL</code>.</div>
> </li>
> <li>
> <div>SATA refclk must not ignore <code>-EPROBE_DEFER</code>, although <code>-ENOENT</code>can still be tolerated for compatibility.</div>
> </li>
> </ul>
> <div>I have fix them together with the clock leak fix in .</div>
> <div>[PATCH 1/2 v3] phy: ti: pipe3: Fix clock resource leak on probe errors</div>
> <div>[PATCH 2/2] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources</div>
> <div>&nbsp;</div>
> <div>Appreciate the careful review.</div>
> <div>&nbsp;</div>
> <div>Regards,</div>
> <div>Hongling</div>
> <p>&nbsp;</p>
> <div id="signatureTop"></div>
> <div id="cs2c_re" style="margin-left: 0.5em; padding-left: 0.5em; border-left: 1px solid #cacaca; -webkit-user-modify: read-only; -moz-user-modify: read-only; -ms-user-modify: read-only; -o-user-modify: read-only;"><br><br><br>
> <div style="background-color: #f8f8f8; padding: 8px 10px; font-family: Microsoft YaHei; font-size: 14px; color: #000;"><strong>主&nbsp;&nbsp;&nbsp;题：</strong><span id="cs2c_subject">Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors</span> <br><strong>日&nbsp;&nbsp;&nbsp;期：</strong><span id="cs2c_date">2026年05月15日10:32</span> <br><strong>发件人：</strong><span id="cs2c_from">sashiko-bot</span> <br><strong>收件人：</strong><span id="cs2c_to" style="word-break: break-all;">sashiko-bot</span> <br><strong>抄送人：</strong><span id="cs2c_to" style="word-break: break-all;">linux-phy,neil.armstrong,olteanv,vkoul</span></div>
> <br>
> <div id="cs2c_content">Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] Masking of -EPROBE_DEFER to -EINVAL when fetching sysclk. - [High] Ignoring -EPROBE_DEFER for the SATA refclk. -- commit 4f2fbd627ee80455cac194a4ae1b559d48180075 Author: Hongling Zeng &lt;zenghongling@kylinos.cn&gt; phy: ti: pipe3: Fix clock resource leak on probe errors When devm_phy_create() or devm_of_phy_provider_register() fails, the refclk that was enabled earlier is not disabled, causing a resource leak. Fix this by adding an error handling path to disable the clock when these functions fail. &gt; diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c &gt; index b5543b5c674c8..58fbc3b278130 100644 &gt; --- a/drivers/phy/ti/phy-ti-pipe3.c &gt; +++ b/drivers/phy/ti/phy-ti-pipe3.c [ ... ] This isn't a regression introduced by this patch, but looking at ti_pipe3_get_clk() called earlier in the probe sequence: drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() { ... if (phy-&gt;mode != PIPE3_MODE_PCIE || phy-&gt;phy_power_syscon) { phy-&gt;sys_clk = devm_clk_get(dev, "sysclk"); if (IS_ERR(phy-&gt;sys_clk)) { dev_err(dev, "unable to get sysclk\n"); return -EINVAL; } } ... } Does this code mask -EPROBE_DEFER to -EINVAL when fetching sysclk? If devm_clk_get() for the sysclk returns -EPROBE_DEFER, the function explicitly converts the error and returns -EINVAL. This completely breaks the lifecycle of probe deferral for the sysclk resource. Instead of retrying when the clock provider becomes available later in the boot process, the driver initialization fails permanently, rendering the PHY device unusable on systems with non-deterministic probe orders. Similarly, looking at the SATA refclk handling in the same function: drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() { ... phy-&gt;refclk = devm_clk_get(dev, "refclk"); if (IS_ERR(phy-&gt;refclk)) { dev_err(dev, "unable to get refclk\n"); /* older DTBs have missing refclk in SATA PHY * so don't bail out in case of SATA PHY. */ if (phy-&gt;mode != PIPE3_MODE_SATA) return PTR_ERR(phy-&gt;refclk); } ... } Are errors returned by devm_clk_get() for the refclk ignored when the mode is PIPE3_MODE_SATA? While ignoring -ENOENT is intentionally done to support older DTBs missing the clock, indiscriminately ignoring -EPROBE_DEFER breaks the probe deferral mechanism. The driver will proceed immediately without waiting for the clock provider to probe, resulting in the SATA PHY being initialized without its required reference clock and subsequently failing to function properly. -- Sashiko AI review · https://sashiko.dev/#/patchset/20260515021635.13444-1-zenghongling@kylinos.cn?part=1 &lt;/zenghongling@kylinos.cn&gt;</div>
> </div>
> <p>&nbsp;</p>
> <p>&nbsp;</p>
> <div id="signatureBom">
> <div>
> <p>&nbsp;</p>
> <br>
> <p style="color: #000; font-size: 16px;">---</p>
> <div id="cs2c_mail_sigature" style="color: #000; font-size: 16px; font-family: Microsoft YaHei;"></div>
> <p>&nbsp;</p>
> </div>
> </div></div>

-- 
~Vinod

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* [PATCH 2/2] phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources
From: Hongling Zeng @ 2026-05-15  4:07 UTC (permalink / raw)
  To: vkoul, neil.armstrong, johan, kishon, rogerq
  Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng

ti_pipe3_get_clk() has two issues with -EPROBE_DEFER error handling:

1. When devm_clk_get() for sysclk fails, the function returns -EINVAL
   instead of propagating the actual error code. This masks -EPROBE_DEFER
   to -EINVAL, breaking the probe deferral mechanism and causing permanent
   driver initialization failure on systems with non-deterministic probe
   ordering.

2. For SATA PHY refclk, the function ignores all errors to support older
   DTBs missing the refclk property. However, this incorrectly ignores
   -EPROBE_DEFER as well, causing the driver to proceed without waiting
   for the clock provider to become available.

Fix both issues:
- Return PTR_ERR(phy->sys_clk) instead of -EINVAL to propagate all
  error codes including -EPROBE_DEFER
- For SATA refclk, only ignore -ENOENT (clock not found in old DTBs)
  but propagate other errors like -EPROBE_DEFER

Fixes: a70143bbef6b ("drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework")
Fixes: 7f33912d2978 ("phy: ti-pipe3: Fix SATA across suspend/resume")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
 drivers/phy/ti/phy-ti-pipe3.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 58fbc3b27813..2bfcd0c70abd 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -604,15 +604,22 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
 {
 	struct clk *clk;
 	struct device *dev = phy->dev;
+	int ret;
 
 	phy->refclk = devm_clk_get(dev, "refclk");
 	if (IS_ERR(phy->refclk)) {
-		dev_err(dev, "unable to get refclk\n");
+		ret = PTR_ERR(phy->refclk);
 		/* older DTBs have missing refclk in SATA PHY
-		 * so don't bail out in case of SATA PHY.
+		 * so don't bail out for -ENOENT, but still defer
+		 * probe for other errors like -EPROBE_DEFER.
 		 */
-		if (phy->mode != PIPE3_MODE_SATA)
-			return PTR_ERR(phy->refclk);
+		if (ret == -ENOENT) {
+			if (phy->mode != PIPE3_MODE_SATA)
+				return ret;
+		} else {
+			dev_err(dev, "unable to get refclk\n");
+			return ret;
+		}
 	}
 
 	if (phy->mode != PIPE3_MODE_SATA) {
@@ -629,7 +636,7 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
 		phy->sys_clk = devm_clk_get(dev, "sysclk");
 		if (IS_ERR(phy->sys_clk)) {
 			dev_err(dev, "unable to get sysclk\n");
-			return -EINVAL;
+			return PTR_ERR(phy->sys_clk);
 		}
 	}
 
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* [PATCH 1/2 v3] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Hongling Zeng @ 2026-05-15  4:05 UTC (permalink / raw)
  To: vkoul, neil.armstrong, johan, kishon
  Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng

When devm_phy_create() or devm_of_phy_provider_register() fails,
the refclk that was enabled earlier is not disabled, causing a
resource leak.

Fix this by adding an error handling path to disable the clock
when these functions fail.

Fixes: 234738ea3390 ("phy: ti-pipe3: move clk initialization to a separate function")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>

---
 Change in v2:
  -Add pm_runtime_disable() in error path (reported by Sashiko AI).
---
 change in v3:
  -Fix unbalanced clock disable by checking clk_prepare_enable()return value and
setting sata_refclk_enabledonly on success.
  -Fix error path teardown order to match ti_pipe3_remove()(disable clock before
disabling runtime PM).
---
 drivers/phy/ti/phy-ti-pipe3.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index b5543b5c674c..58fbc3b27813 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -831,21 +831,39 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	 */
 	if (phy->mode == PIPE3_MODE_SATA) {
 		if (!IS_ERR(phy->refclk)) {
-			clk_prepare_enable(phy->refclk);
+			ret = clk_prepare_enable(phy->refclk);
+			if (ret) {
+				dev_err(dev, "Failed to enable refclk %d\n", ret);
+				goto err_pm_disable;
+			}
 			phy->sata_refclk_enabled = true;
 		}
 	}
 
 	generic_phy = devm_phy_create(dev, NULL, &ops);
-	if (IS_ERR(generic_phy))
-		return PTR_ERR(generic_phy);
+	if (IS_ERR(generic_phy)) {
+		ret = PTR_ERR(generic_phy);
+		goto err_clk_disable;
+	}
 
 	phy_set_drvdata(generic_phy, phy);
 
 	ti_pipe3_power_off(generic_phy);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
-	return PTR_ERR_OR_ZERO(phy_provider);
+	if (IS_ERR(phy_provider)) {
+		ret = PTR_ERR(phy_provider);
+		goto err_clk_disable;
+	}
+
+	return 0;
+
+err_clk_disable:
+	if (phy->sata_refclk_enabled && !IS_ERR(phy->refclk))
+		clk_disable_unprepare(phy->refclk);
+err_pm_disable:
+	pm_runtime_disable(dev);
+	return ret;
 }
 
 static void ti_pipe3_remove(struct platform_device *pdev)
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* Re: [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors
From: sashiko-bot @ 2026-05-15  2:32 UTC (permalink / raw)
  To: Hongling Zeng; +Cc: linux-phy, neil.armstrong, olteanv, vkoul
In-Reply-To: <20260515021635.13444-1-zenghongling@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Masking of -EPROBE_DEFER to -EINVAL when fetching sysclk.
- [High] Ignoring -EPROBE_DEFER for the SATA refclk.
--

commit 4f2fbd627ee80455cac194a4ae1b559d48180075
Author: Hongling Zeng <zenghongling@kylinos.cn>

phy: ti: pipe3: Fix clock resource leak on probe errors

When devm_phy_create() or devm_of_phy_provider_register() fails,
the refclk that was enabled earlier is not disabled, causing a
resource leak.

Fix this by adding an error handling path to disable the clock
when these functions fail.

> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
> index b5543b5c674c8..58fbc3b278130 100644
> --- a/drivers/phy/ti/phy-ti-pipe3.c
> +++ b/drivers/phy/ti/phy-ti-pipe3.c

[ ... ]

This isn't a regression introduced by this patch, but looking at
ti_pipe3_get_clk() called earlier in the probe sequence:

drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() {
	...
	if (phy->mode != PIPE3_MODE_PCIE || phy->phy_power_syscon) {
		phy->sys_clk = devm_clk_get(dev, "sysclk");
		if (IS_ERR(phy->sys_clk)) {
			dev_err(dev, "unable to get sysclk\n");
			return -EINVAL;
		}
	}
	...
}

Does this code mask -EPROBE_DEFER to -EINVAL when fetching sysclk?

If devm_clk_get() for the sysclk returns -EPROBE_DEFER, the function
explicitly converts the error and returns -EINVAL. This completely breaks
the lifecycle of probe deferral for the sysclk resource.

Instead of retrying when the clock provider becomes available later in the
boot process, the driver initialization fails permanently, rendering the PHY
device unusable on systems with non-deterministic probe orders.

Similarly, looking at the SATA refclk handling in the same function:

drivers/phy/ti/phy-ti-pipe3.c:ti_pipe3_get_clk() {
	...
	phy->refclk = devm_clk_get(dev, "refclk");
	if (IS_ERR(phy->refclk)) {
		dev_err(dev, "unable to get refclk\n");
		/* older DTBs have missing refclk in SATA PHY
		 * so don't bail out in case of SATA PHY.
		 */
		if (phy->mode != PIPE3_MODE_SATA)
			return PTR_ERR(phy->refclk);
	}
	...
}

Are errors returned by devm_clk_get() for the refclk ignored when the mode
is PIPE3_MODE_SATA?

While ignoring -ENOENT is intentionally done to support older DTBs missing
the clock, indiscriminately ignoring -EPROBE_DEFER breaks the probe deferral
mechanism. The driver will proceed immediately without waiting for the clock
provider to probe, resulting in the SATA PHY being initialized without its
required reference clock and subsequently failing to function properly.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515021635.13444-1-zenghongling@kylinos.cn?part=1

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
* [PATCH v3] phy: ti: pipe3: Fix clock resource leak on probe errors
From: Hongling Zeng @ 2026-05-15  2:16 UTC (permalink / raw)
  To: vkoul, neil.armstrong, johan, kishon
  Cc: linux-phy, linux-kernel, zhongling0719, Hongling Zeng

When devm_phy_create() or devm_of_phy_provider_register() fails,
the refclk that was enabled earlier is not disabled, causing a
resource leak.

Fix this by adding an error handling path to disable the clock
when these functions fail.

Fixes: 234738ea3390 ("phy: ti-pipe3: move clk initialization to a separate function")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>

---
 Change in v2:
  -Add pm_runtime_disable() in error path (reported by Sashiko AI).
---
 change in v3:
  -Fix unbalanced clock disable by checking clk_prepare_enable()return value and
setting sata_refclk_enabledonly on success.
  -Fix error path teardown order to match ti_pipe3_remove()(disable clock before
disabling runtime PM).
---
 drivers/phy/ti/phy-ti-pipe3.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index b5543b5c674c..58fbc3b27813 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -831,21 +831,39 @@ static int ti_pipe3_probe(struct platform_device *pdev)
 	 */
 	if (phy->mode == PIPE3_MODE_SATA) {
 		if (!IS_ERR(phy->refclk)) {
-			clk_prepare_enable(phy->refclk);
+			ret = clk_prepare_enable(phy->refclk);
+			if (ret) {
+				dev_err(dev, "Failed to enable refclk %d\n", ret);
+				goto err_pm_disable;
+			}
 			phy->sata_refclk_enabled = true;
 		}
 	}
 
 	generic_phy = devm_phy_create(dev, NULL, &ops);
-	if (IS_ERR(generic_phy))
-		return PTR_ERR(generic_phy);
+	if (IS_ERR(generic_phy)) {
+		ret = PTR_ERR(generic_phy);
+		goto err_clk_disable;
+	}
 
 	phy_set_drvdata(generic_phy, phy);
 
 	ti_pipe3_power_off(generic_phy);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
-	return PTR_ERR_OR_ZERO(phy_provider);
+	if (IS_ERR(phy_provider)) {
+		ret = PTR_ERR(phy_provider);
+		goto err_clk_disable;
+	}
+
+	return 0;
+
+err_clk_disable:
+	if (phy->sata_refclk_enabled && !IS_ERR(phy->refclk))
+		clk_disable_unprepare(phy->refclk);
+err_pm_disable:
+	pm_runtime_disable(dev);
+	return ret;
 }
 
 static void ti_pipe3_remove(struct platform_device *pdev)
-- 
2.25.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic context
From: Pavel Machek @ 2026-05-14 21:18 UTC (permalink / raw)
  To: Claudiu Beznea
  Cc: yoshihiro.shimoda.uh, vkoul, neil.armstrong, geert+renesas,
	magnus.damm, prabhakar.mahadev-lad.rj, linux-renesas-soc,
	linux-phy, linux-kernel, Claudiu Beznea, stable, Pavel Machek,
	Nobuhiro Iwamatsu
In-Reply-To: <20260514111300.2152386-1-claudiu.beznea@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 2597 bytes --]

Hi!

> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> 
> The OTG PHY initialization sequence needs to wait for 20 ms at a specific
> step, as described in commit 72c0339c115b ("phy: renesas:
> rcar-gen3-usb2: follow the hardware manual procedure").
> 
> Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware
> registers and driver data") tried to address various problems in the
> rcar-gen3-usb2 driver and converted the mutex protecting HW register
> accesses to a spin lock, leaving, however, a long delay in the critical
> section protected by the spin lock. This may become a problem,
> especially on RT kernels.
> 
> To address this, release the spin lock before sleeping for 20 ms as
> required by the HW manual and reacquire it afterwards. To avoid other
> threads entering the critical section and configuring the HW while the
> software is waiting for the OTG initialization to complete, introduce the
> otg_initializing variable alongside the otg_init_done completion. Any
> other thread trying to configure the HW while the OTG PHY initialization
> is in progress waits for the completion instead of immediately returning
> errors to PHY users. The IRQs were also disabled while waiting for the OTG
> PHY initialization to complete, as the interrupt handler may also apply HW
> settings.

Just... there has to be a better way.

> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +static int rcar_gen3_phy_wait_otg_init(struct rcar_gen3_chan *channel,
> +				       unsigned long *flags)
> +{
> +	unsigned long timeout = msecs_to_jiffies(25);
> +	unsigned long ret = 1;
> +
> +	lockdep_assert_held(&channel->lock);
> +
> +	/*
> +	 * The OTG can be initialized only once and needs to release the lock
> +	 * and wait for 20 ms due to hardware constraints. Wait for the OTG PHY
> +	 * initialization to complete if another PHY executes configuration
> +	 * code while the OTG PHY is waiting. This avoids returning failures to
> +	 * PHY users.
> +	 */
> +	if (READ_ONCE(channel->otg_initializing)) {
> +		spin_unlock_irqrestore(&channel->lock, *flags);

This is not nice, passing flags between functions like this is a red flag.

You are only accessing otg_initializing under the spinlock. That means
that READ_ONCE is reduntant.

But AFAICT spinlock is only held over this function to protect
channel->otg_initializing access. I suspect correct answer here is
getting rid of spinlock over this function, and using
test_bit(BIT_INITIALIZING, ...) or something similar.

Best regards,
								Pavel


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 112 bytes --]

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox