Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V2 3/4] arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
From: Pradeep P V K @ 2025-12-31 10:19 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
	andersson, konradybcio, taniya.das, dmitry.baryshkov,
	manivannan.sadhasivam
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat, Pradeep P V K
In-Reply-To: <20251231101951.1026163-1-pradeep.pragallapati@oss.qualcomm.com>

Add UFS host controller and PHY nodes for x1e80100 SoC.

Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 123 +++++++++++++++++++++++++++-
 1 file changed, 120 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 21ab6ef61520..cd7e2f130fe2 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -835,9 +835,9 @@ gcc: clock-controller@100000 {
 				 <0>,
 				 <0>,
 				 <0>,
-				 <0>,
-				 <0>,
-				 <0>;
+				 <&ufs_mem_phy 0>,
+				 <&ufs_mem_phy 1>,
+				 <&ufs_mem_phy 2>;
 
 			power-domains = <&rpmhpd RPMHPD_CX>;
 			#clock-cells = <1>;
@@ -3848,6 +3848,123 @@ pcie4_phy: phy@1c0e000 {
 			status = "disabled";
 		};
 
+		ufs_mem_phy: phy@1d80000 {
+			compatible = "qcom,x1e80100-qmp-ufs-phy",
+				     "qcom,sm8550-qmp-ufs-phy";
+			reg = <0x0 0x01d80000 0x0 0x2000>;
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>,
+				 <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
+				 <&tcsr TCSR_UFS_PHY_CLKREF_EN>;
+
+			clock-names = "ref",
+				      "ref_aux",
+				      "qref";
+			resets = <&ufs_mem_hc 0>;
+			reset-names = "ufsphy";
+
+			power-domains = <&gcc GCC_UFS_MEM_PHY_GDSC>;
+
+			#clock-cells = <1>;
+			#phy-cells = <0>;
+
+			status = "disabled";
+		};
+
+		ufs_mem_hc: ufs@1d84000 {
+			compatible = "qcom,x1e80100-ufshc",
+				     "qcom,sm8550-ufshc",
+				     "qcom,ufshc",
+				     "jedec,ufs-2.0";
+			reg = <0x0 0x01d84000 0x0 0x3000>;
+
+			interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
+
+			clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
+				 <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+				 <&gcc GCC_UFS_PHY_AHB_CLK>,
+				 <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+				 <&rpmhcc RPMH_LN_BB_CLK3>,
+				 <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+				 <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+				 <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+			clock-names = "core_clk",
+				      "bus_aggr_clk",
+				      "iface_clk",
+				      "core_clk_unipro",
+				      "ref_clk",
+				      "tx_lane0_sync_clk",
+				      "rx_lane0_sync_clk",
+				      "rx_lane1_sync_clk";
+
+			operating-points-v2 = <&ufs_opp_table>;
+
+			resets = <&gcc GCC_UFS_PHY_BCR>;
+			reset-names = "rst";
+
+			interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+					<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+					 &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+			interconnect-names = "ufs-ddr",
+					     "cpu-ufs";
+
+			power-domains = <&gcc GCC_UFS_PHY_GDSC>;
+			required-opps = <&rpmhpd_opp_nom>;
+
+			iommus = <&apps_smmu 0x1a0 0>;
+			dma-coherent;
+
+			lanes-per-direction = <2>;
+
+			phys = <&ufs_mem_phy>;
+			phy-names = "ufsphy";
+
+			#reset-cells = <1>;
+
+			status = "disabled";
+
+			ufs_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-75000000 {
+					opp-hz = /bits/ 64 <75000000>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <75000000>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>;
+					required-opps = <&rpmhpd_opp_low_svs>;
+				};
+
+				opp-150000000 {
+					opp-hz = /bits/ 64 <150000000>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <150000000>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>;
+					required-opps = <&rpmhpd_opp_svs>;
+				};
+
+				opp-300000000 {
+					opp-hz = /bits/ 64 <300000000>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <300000000>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>,
+						 /bits/ 64 <0>;
+					required-opps = <&rpmhpd_opp_nom>;
+				};
+			};
+		};
+
 		cryptobam: dma-controller@1dc4000 {
 			compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
 			reg = <0x0 0x01dc4000 0x0 0x28000>;
-- 
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 V2 2/4] scsi: ufs: qcom: dt-bindings: Document UFSHC compatible for x1e80100
From: Pradeep P V K @ 2025-12-31 10:19 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
	andersson, konradybcio, taniya.das, dmitry.baryshkov,
	manivannan.sadhasivam
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat, Pradeep P V K
In-Reply-To: <20251231101951.1026163-1-pradeep.pragallapati@oss.qualcomm.com>

Add the UFS Host Controller (UFSHC) compatible for Qualcomm x1e80100
SoC.  Use SM8550 as a fallback since x1e80100 shares compatibility
with SM8550 UFSHC, enabling reuse of existing support.

Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
 .../bindings/ufs/qcom,sc7180-ufshc.yaml       | 38 +++++++++++--------
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
index d94ef4e6b85a..0f6ea7ca06c8 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
@@ -26,26 +26,34 @@ select:
           - qcom,sm8350-ufshc
           - qcom,sm8450-ufshc
           - qcom,sm8550-ufshc
+          - qcom,x1e80100-ufshc
   required:
     - compatible
 
 properties:
   compatible:
-    items:
-      - enum:
-          - qcom,msm8998-ufshc
-          - qcom,qcs8300-ufshc
-          - qcom,sa8775p-ufshc
-          - qcom,sc7180-ufshc
-          - qcom,sc7280-ufshc
-          - qcom,sc8180x-ufshc
-          - qcom,sc8280xp-ufshc
-          - qcom,sm8250-ufshc
-          - qcom,sm8350-ufshc
-          - qcom,sm8450-ufshc
-          - qcom,sm8550-ufshc
-      - const: qcom,ufshc
-      - const: jedec,ufs-2.0
+    oneOf:
+      - items:
+          - enum:
+              - qcom,x1e80100-ufshc
+          - const: qcom,sm8550-ufshc
+          - const: qcom,ufshc
+          - const: jedec,ufs-2.0
+      - items:
+          - enum:
+              - qcom,msm8998-ufshc
+              - qcom,qcs8300-ufshc
+              - qcom,sa8775p-ufshc
+              - qcom,sc7180-ufshc
+              - qcom,sc7280-ufshc
+              - qcom,sc8180x-ufshc
+              - qcom,sc8280xp-ufshc
+              - qcom,sm8250-ufshc
+              - qcom,sm8350-ufshc
+              - qcom,sm8450-ufshc
+              - qcom,sm8550-ufshc
+          - const: qcom,ufshc
+          - const: jedec,ufs-2.0
 
   reg:
     maxItems: 1
-- 
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 V2 1/4] dt-bindings: phy: Add QMP UFS PHY compatible for x1e80100
From: Pradeep P V K @ 2025-12-31 10:19 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
	andersson, konradybcio, taniya.das, dmitry.baryshkov,
	manivannan.sadhasivam
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat, Pradeep P V K
In-Reply-To: <20251231101951.1026163-1-pradeep.pragallapati@oss.qualcomm.com>

Add the QMP UFS PHY compatible string for Qualcomm x1e80100 SoC to
support its physical layer functionality for UFS. Use SM8550 as a
fallback since x1e80100 UFS PHY shares the same tech node, allowing
reuse of existing UFS PHY support.

Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
 .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml    | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index fba7b2549dde..552dd663b7c9 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -28,6 +28,10 @@ properties:
           - enum:
               - qcom,kaanapali-qmp-ufs-phy
           - const: qcom,sm8750-qmp-ufs-phy
+      - items:
+          - enum:
+              - qcom,x1e80100-qmp-ufs-phy
+          - const: qcom,sm8550-qmp-ufs-phy
       - enum:
           - qcom,msm8996-qmp-ufs-phy
           - qcom,msm8998-qmp-ufs-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 V2 0/4] Add UFS support for x1e80100 SoC
From: Pradeep P V K @ 2025-12-31 10:19 UTC (permalink / raw)
  To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
	andersson, konradybcio, taniya.das, dmitry.baryshkov,
	manivannan.sadhasivam
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat, Pradeep P V K

Add UFSPHY, UFSHC compatible binding names and UFS devicetree
enablement changes for Qualcomm x1e80100 SoC.

Changes in V2:
- Update all dt-bindings commit messages to explain fallback
  to SM8550 [Krzysztof]
- Pad register addresses to 8-digit hex format [Konrad]
- Place one compatible string per line [Konrad]
- Replace chip codenames with numeric identifiers throughout [Konrad]
- Fix dt_binding_check error in UFSHC dt-bindings [Rob]

- This series is rebased on GCC bindings and driver changes:
  https://lore.kernel.org/lkml/20251230-ufs_symbol_clk-v1-0-47d46b24c087@oss.qualcomm.com/

- This series address issues and gaps noticed on:
  https://lore.kernel.org/linux-devicetree/20250814005904.39173-2-harrison.vanderbyl@gmail.com/
  https://lore.kernel.org/linux-devicetree/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/   

- Link to V1:
  https://lore.kernel.org/linux-phy/20251229060642.2807165-1-pradeep.pragallapati@oss.qualcomm.com/

---
Pradeep P V K (4):
  dt-bindings: phy: Add QMP UFS PHY compatible for x1e80100
  scsi: ufs: qcom: dt-bindings: Document UFSHC compatible for x1e80100
  arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
  arm64: dts: qcom: hamoa-iot-evk: Enable UFS

 .../phy/qcom,sc8280xp-qmp-ufs-phy.yaml        |   4 +
 .../bindings/ufs/qcom,sc7180-ufshc.yaml       |  38 +++---
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts    |  18 +++
 arch/arm64/boot/dts/qcom/hamoa.dtsi           | 123 +++++++++++++++++-
 4 files changed, 165 insertions(+), 18 deletions(-)

-- 
2.34.1


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

^ permalink raw reply

* Re: [PATCH] phy: core: Reinstate pm_runtime_enabled() check in phy_pm_runtime_put()
From: Wysocki, Rafael J @ 2025-12-30 17:10 UTC (permalink / raw)
  To: Geert Uytterhoeven, Vinod Koul, Neil Armstrong
  Cc: linux-phy, linux-renesas-soc, linux-kernel
In-Reply-To: <3ca9f8166d21685bfbf97535da30172f74822130.1767107014.git.geert+renesas@glider.be>


On 12/30/2025 4:04 PM, Geert Uytterhoeven wrote:
> On Koelsch (R-Car M2-W), during boot and s2ram:
>
>      phy phy-e6590100.usb-phy-controller.0: Runtime PM usage count underflow!
>
> While phy_pm_runtime_get{,_sync}() and phy_pm_runtime_put_sync() still
> contain pm_runtime_enabled() checks, the same check in
> phy_pm_runtime_put() was deemed redundant and removed, causing count
> underflows with PHY drivers like drivers/phy/renesas/phy-rcar-gen2.c
> that do not use Runtime PM yet,
>
> Fix this by reinstating the check.
>
> Fixes: caad07ae07e3fb17 ("phy: core: Discard pm_runtime_put() return values")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>


> ---
>   drivers/phy/phy-core.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 160ecb757d1d62a0..e2a2a99d069789c7 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -195,6 +195,9 @@ void phy_pm_runtime_put(struct phy *phy)
>   	if (!phy)
>   		return;
>   
> +	if (!pm_runtime_enabled(&phy->dev))
> +		return;
> +
>   	pm_runtime_put(&phy->dev);
>   }
>   EXPORT_SYMBOL_GPL(phy_pm_runtime_put);

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

^ permalink raw reply

* Re: [PATCH] phy: adjust function name reference
From: Daniel Golle @ 2025-12-30 16:56 UTC (permalink / raw)
  To: Julia Lawall
  Cc: yunbolyu, kexinsun, ratnadiraw, xutong.ma, Qingfang Deng,
	SkyLake Huang, Chunfeng Yun, Vinod Koul, Kishon Vijay Abraham I,
	Matthias Brugger, AngeloGioacchino Del Regno, netdev,
	linux-arm-kernel, linux-mediatek, linux-phy, linux-kernel
In-Reply-To: <20251230140601.93474-1-Julia.Lawall@inria.fr>

On Tue, Dec 30, 2025 at 03:06:01PM +0100, Julia Lawall wrote:
> There is no function clk_bulk_prepare_disable.  Refer instead to
> clk_bulk_disable_unprepare, which is called in the function
> defined just below.
> 
> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>

Thanks for spotting this obviously wrong comment!

Reviewed-by: Daniel Golle <daniel@makrotopia.org>

> 
> ---
>  drivers/phy/mediatek/phy-mtk-xfi-tphy.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> index 1a0b7484f525..100a50d0e861 100644
> --- a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> +++ b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> @@ -353,7 +353,7 @@ static int mtk_xfi_tphy_power_on(struct phy *phy)
>   * Disable and unprepare all clocks previously enabled.
>   *
>   * Return:
> - * See clk_bulk_prepare_disable().
> + * See clk_bulk_disable_unprepare().
>   */
>  static int mtk_xfi_tphy_power_off(struct phy *phy)
>  {
> 
> 

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

^ permalink raw reply

* Re: [PATCH v1 15/23] phy: core: Discard pm_runtime_put() return values
From: Rafael J. Wysocki @ 2025-12-30 16:18 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Rafael J. Wysocki, Linux PM, LKML, Ulf Hansson, Brian Norris,
	Vinod Koul, Neil Armstrong, linux-phy, Linux-Renesas
In-Reply-To: <CAMuHMdVeHY7+9Jz60OX521iaEorGOcrxuGC8iuzDRUA-tkEvLQ@mail.gmail.com>

On Tue, Dec 30, 2025 at 4:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Tue, 30 Dec 2025 at 11:54, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, 30 Dec 2025 at 11:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Mon, 22 Dec 2025 at 21:40, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > >
> > > > The PHY core defines phy_pm_runtime_put() to return an int, but that
> > > > return value is never used.  It also passes the return value of
> > > > pm_runtime_put() to the caller which is not very useful.
> > > >
> > > > Returning an error code from pm_runtime_put() merely means that it has
> > > > not queued up a work item to check whether or not the device can be
> > > > suspended and there are many perfectly valid situations in which that
> > > > can happen, like after writing "on" to the devices' runtime PM "control"
> > > > attribute in sysfs for one example.
> > > >
> > > > Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
> > > > value and change its return type to void.  Also drop the redundant
> > > > pm_runtime_enabled() call from there.
> > > >
> > > > No intentional functional impact.
> > > >
> > > > This will facilitate a planned change of the pm_runtime_put() return
> > > > type to void in the future.
> > > >
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > Thanks for your patch, which is now commit caad07ae07e3fb17 ("phy:
> > > core: Discard pm_runtime_put() return values") in phy/next.
> > >
> > > This is causing several messages like
> > >
> > >     phy phy-e6590100.usb-phy-controller.2: Runtime PM usage count underflow!
> > >
> > > during boot, and s2ram on Koelsch (R-Car M2-W).
> >
> > On R-Car Gen3, there are no such messages, as e.g.
> > drivers/phy/renesas/phy-rcar-gen3-usb2.c does support Runtime PM.
> > R-Car Gen2 uses drivers/phy/renesas/phy-rcar-gen2.c, which does not
> > use Runtime PM yet, but still relies on explicit clock management.
> >
> > > > --- a/drivers/phy/phy-core.c
> > > > +++ b/drivers/phy/phy-core.c
> > > > @@ -190,15 +190,12 @@ int phy_pm_runtime_get_sync(struct phy *
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
> > > >
> > > > -int phy_pm_runtime_put(struct phy *phy)
> > > > +void phy_pm_runtime_put(struct phy *phy)
> > > >  {
> > > >         if (!phy)
> > > > -               return 0;
> > > > +               return;
> > > >
> > > > -       if (!pm_runtime_enabled(&phy->dev))
> > > > -               return -ENOTSUPP;
> > >
> > > Adding some instrumentation shows that this branch was taken before,
> > > thus skipping the call to pm_runtime_put().
> > >
> > > Can I just put the check back, or is there an underlying problem that
> > > should be fixed instead?
> >
> > I assume the PHY core should support both drivers that do and do not
> > support Runtime PM.
>
> I have sent a patch:
> https://lore.kernel.org/3ca9f8166d21685bfbf97535da30172f74822130.1767107014.git.geert+renesas@glider.be

LGTM

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

^ permalink raw reply

* Re: [PATCH v1 15/23] phy: core: Discard pm_runtime_put() return values
From: Rafael J. Wysocki @ 2025-12-30 16:17 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Rafael J. Wysocki, Linux PM, LKML, Ulf Hansson, Brian Norris,
	Vinod Koul, Neil Armstrong, linux-phy, Linux-Renesas
In-Reply-To: <CAMuHMdWshJOjzD5DGzyRUG66jvPC6PPVBgaT=UdWy+XOk_T5Pw@mail.gmail.com>

On Tue, Dec 30, 2025 at 11:54 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> On Tue, 30 Dec 2025 at 11:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, 22 Dec 2025 at 21:40, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > The PHY core defines phy_pm_runtime_put() to return an int, but that
> > > return value is never used.  It also passes the return value of
> > > pm_runtime_put() to the caller which is not very useful.
> > >
> > > Returning an error code from pm_runtime_put() merely means that it has
> > > not queued up a work item to check whether or not the device can be
> > > suspended and there are many perfectly valid situations in which that
> > > can happen, like after writing "on" to the devices' runtime PM "control"
> > > attribute in sysfs for one example.
> > >
> > > Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
> > > value and change its return type to void.  Also drop the redundant
> > > pm_runtime_enabled() call from there.
> > >
> > > No intentional functional impact.
> > >
> > > This will facilitate a planned change of the pm_runtime_put() return
> > > type to void in the future.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Thanks for your patch, which is now commit caad07ae07e3fb17 ("phy:
> > core: Discard pm_runtime_put() return values") in phy/next.
> >
> > This is causing several messages like
> >
> >     phy phy-e6590100.usb-phy-controller.2: Runtime PM usage count underflow!
> >
> > during boot, and s2ram on Koelsch (R-Car M2-W).
>
> On R-Car Gen3, there are no such messages, as e.g.
> drivers/phy/renesas/phy-rcar-gen3-usb2.c does support Runtime PM.
> R-Car Gen2 uses drivers/phy/renesas/phy-rcar-gen2.c, which does not
> use Runtime PM yet, but still relies on explicit clock management.
>
> > > --- a/drivers/phy/phy-core.c
> > > +++ b/drivers/phy/phy-core.c
> > > @@ -190,15 +190,12 @@ int phy_pm_runtime_get_sync(struct phy *
> > >  }
> > >  EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
> > >
> > > -int phy_pm_runtime_put(struct phy *phy)
> > > +void phy_pm_runtime_put(struct phy *phy)
> > >  {
> > >         if (!phy)
> > > -               return 0;
> > > +               return;
> > >
> > > -       if (!pm_runtime_enabled(&phy->dev))
> > > -               return -ENOTSUPP;
> >
> > Adding some instrumentation shows that this branch was taken before,
> > thus skipping the call to pm_runtime_put().
> >
> > Can I just put the check back, or is there an underlying problem that
> > should be fixed instead?

Sorry for breaking this!

> I assume the PHY core should support both drivers that do and do not
> support Runtime PM.

Yes, it should be sufficient to restore the pm_runtime_enabled() check.

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

^ permalink raw reply

* Re: [PATCH v1 15/23] phy: core: Discard pm_runtime_put() return values
From: Geert Uytterhoeven @ 2025-12-30 15:05 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM, LKML, Ulf Hansson, Brian Norris, Vinod Koul,
	Neil Armstrong, linux-phy, Linux-Renesas
In-Reply-To: <CAMuHMdWshJOjzD5DGzyRUG66jvPC6PPVBgaT=UdWy+XOk_T5Pw@mail.gmail.com>

On Tue, 30 Dec 2025 at 11:54, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 30 Dec 2025 at 11:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Mon, 22 Dec 2025 at 21:40, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > The PHY core defines phy_pm_runtime_put() to return an int, but that
> > > return value is never used.  It also passes the return value of
> > > pm_runtime_put() to the caller which is not very useful.
> > >
> > > Returning an error code from pm_runtime_put() merely means that it has
> > > not queued up a work item to check whether or not the device can be
> > > suspended and there are many perfectly valid situations in which that
> > > can happen, like after writing "on" to the devices' runtime PM "control"
> > > attribute in sysfs for one example.
> > >
> > > Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
> > > value and change its return type to void.  Also drop the redundant
> > > pm_runtime_enabled() call from there.
> > >
> > > No intentional functional impact.
> > >
> > > This will facilitate a planned change of the pm_runtime_put() return
> > > type to void in the future.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Thanks for your patch, which is now commit caad07ae07e3fb17 ("phy:
> > core: Discard pm_runtime_put() return values") in phy/next.
> >
> > This is causing several messages like
> >
> >     phy phy-e6590100.usb-phy-controller.2: Runtime PM usage count underflow!
> >
> > during boot, and s2ram on Koelsch (R-Car M2-W).
>
> On R-Car Gen3, there are no such messages, as e.g.
> drivers/phy/renesas/phy-rcar-gen3-usb2.c does support Runtime PM.
> R-Car Gen2 uses drivers/phy/renesas/phy-rcar-gen2.c, which does not
> use Runtime PM yet, but still relies on explicit clock management.
>
> > > --- a/drivers/phy/phy-core.c
> > > +++ b/drivers/phy/phy-core.c
> > > @@ -190,15 +190,12 @@ int phy_pm_runtime_get_sync(struct phy *
> > >  }
> > >  EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
> > >
> > > -int phy_pm_runtime_put(struct phy *phy)
> > > +void phy_pm_runtime_put(struct phy *phy)
> > >  {
> > >         if (!phy)
> > > -               return 0;
> > > +               return;
> > >
> > > -       if (!pm_runtime_enabled(&phy->dev))
> > > -               return -ENOTSUPP;
> >
> > Adding some instrumentation shows that this branch was taken before,
> > thus skipping the call to pm_runtime_put().
> >
> > Can I just put the check back, or is there an underlying problem that
> > should be fixed instead?
>
> I assume the PHY core should support both drivers that do and do not
> support Runtime PM.

I have sent a patch:
https://lore.kernel.org/3ca9f8166d21685bfbf97535da30172f74822130.1767107014.git.geert+renesas@glider.be

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

^ permalink raw reply

* [PATCH] phy: core: Reinstate pm_runtime_enabled() check in phy_pm_runtime_put()
From: Geert Uytterhoeven @ 2025-12-30 15:04 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Rafael J . Wysocki
  Cc: linux-phy, linux-renesas-soc, linux-kernel, Geert Uytterhoeven

On Koelsch (R-Car M2-W), during boot and s2ram:

    phy phy-e6590100.usb-phy-controller.0: Runtime PM usage count underflow!

While phy_pm_runtime_get{,_sync}() and phy_pm_runtime_put_sync() still
contain pm_runtime_enabled() checks, the same check in
phy_pm_runtime_put() was deemed redundant and removed, causing count
underflows with PHY drivers like drivers/phy/renesas/phy-rcar-gen2.c
that do not use Runtime PM yet,

Fix this by reinstating the check.

Fixes: caad07ae07e3fb17 ("phy: core: Discard pm_runtime_put() return values")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/phy/phy-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 160ecb757d1d62a0..e2a2a99d069789c7 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -195,6 +195,9 @@ void phy_pm_runtime_put(struct phy *phy)
 	if (!phy)
 		return;
 
+	if (!pm_runtime_enabled(&phy->dev))
+		return;
+
 	pm_runtime_put(&phy->dev);
 }
 EXPORT_SYMBOL_GPL(phy_pm_runtime_put);
-- 
2.43.0


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

^ permalink raw reply related

* Re: [PATCH V1 4/4] arm64: dts: qcom: hamoa-iot-evk: Enable UFS
From: Konrad Dybcio @ 2025-12-30 14:48 UTC (permalink / raw)
  To: Pradeep Pragallapati, vkoul, neil.armstrong, robh, krzk+dt,
	conor+dt, martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <80529f8d-8db0-4b3c-b79e-8d5a3004241e@oss.qualcomm.com>

On 12/30/25 3:19 PM, Konrad Dybcio wrote:
> On 12/30/25 9:58 AM, Pradeep Pragallapati wrote:
>>
>> On 12/29/2025 5:47 PM, Konrad Dybcio wrote:
>>> On 12/29/25 7:06 AM, Pradeep P V K wrote:
>>>> Enable UFS for HAMOA-IOT-EVK board.
>>>>
>>>> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
>>>> ---
>>> [...]
>>>
>>>> +&ufs_mem_hc {
>>>> +    reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
>>>> +
>>>> +    vcc-supply = <&vreg_l17b_2p5>;
>>>> +    vcc-max-microamp = <1300000>;
>>> I think they should both be 1.2 A peak
>>>
>>> Konrad
>> This (1.3 A) is as per Hamoa power grid, which is same as SM8550.
> 
> Please check again, I opened the power grid tab in the internal
> documentation source that shall remain nameless and it said 1200 mA
> for both regulators

My source indeed said 1.2 and Pradeep's source indeed said 1.3

Because we don't know the source of this disjoint information we
agreed to keep the higher value, especially since it was battle-tested

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: phy-rcar-gen2: fix typo in function name reference
From: Geert Uytterhoeven @ 2025-12-30 14:27 UTC (permalink / raw)
  To: Julia Lawall
  Cc: Vinod Koul, yunbolyu, kexinsun, ratnadiraw, xutong.ma,
	Kishon Vijay Abraham I, Magnus Damm, linux-phy, linux-renesas-soc,
	linux-kernel
In-Reply-To: <20251230141050.93856-1-Julia.Lawall@inria.fr>

On Tue, 30 Dec 2025 at 15:10, Julia Lawall <Julia.Lawall@inria.fr> wrote:
> Replace cmpxcgh by cmpxchg.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

^ permalink raw reply

* Re: [PATCH V1 4/4] arm64: dts: qcom: hamoa-iot-evk: Enable UFS
From: Konrad Dybcio @ 2025-12-30 14:19 UTC (permalink / raw)
  To: Pradeep Pragallapati, vkoul, neil.armstrong, robh, krzk+dt,
	conor+dt, martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <a64f088b-8509-40cc-9f01-23c8b87a8f3c@oss.qualcomm.com>

On 12/30/25 9:58 AM, Pradeep Pragallapati wrote:
> 
> On 12/29/2025 5:47 PM, Konrad Dybcio wrote:
>> On 12/29/25 7:06 AM, Pradeep P V K wrote:
>>> Enable UFS for HAMOA-IOT-EVK board.
>>>
>>> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
>>> ---
>> [...]
>>
>>> +&ufs_mem_hc {
>>> +    reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
>>> +
>>> +    vcc-supply = <&vreg_l17b_2p5>;
>>> +    vcc-max-microamp = <1300000>;
>> I think they should both be 1.2 A peak
>>
>> Konrad
> This (1.3 A) is as per Hamoa power grid, which is same as SM8550.

Please check again, I opened the power grid tab in the internal
documentation source that shall remain nameless and it said 1200 mA
for both regulators

Konrad

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

^ permalink raw reply

* [PATCH] phy: renesas: phy-rcar-gen2: fix typo in function name reference
From: Julia Lawall @ 2025-12-30 14:10 UTC (permalink / raw)
  To: Vinod Koul
  Cc: yunbolyu, kexinsun, ratnadiraw, xutong.ma, Kishon Vijay Abraham I,
	Geert Uytterhoeven, Magnus Damm, linux-phy, linux-renesas-soc,
	linux-kernel

Replace cmpxcgh by cmpxchg.

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>

---
 drivers/phy/renesas/phy-rcar-gen2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
index c0221e7258c0..08d36e6eabcd 100644
--- a/drivers/phy/renesas/phy-rcar-gen2.c
+++ b/drivers/phy/renesas/phy-rcar-gen2.c
@@ -85,7 +85,7 @@ static int rcar_gen2_phy_init(struct phy *p)
 	 * Try to acquire exclusive access to PHY.  The first driver calling
 	 * phy_init()  on a given channel wins, and all attempts  to use another
 	 * PHY on this channel will fail until phy_exit() is called by the first
-	 * driver.   Achieving this with cmpxcgh() should be SMP-safe.
+	 * driver.   Achieving this with cmpxchg() should be SMP-safe.
 	 */
 	if (cmpxchg(&channel->selected_phy, -1, phy->number) != -1)
 		return -EBUSY;


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

^ permalink raw reply related

* [PATCH] phy: adjust function name reference
From: Julia Lawall @ 2025-12-30 14:06 UTC (permalink / raw)
  To: Daniel Golle
  Cc: yunbolyu, kexinsun, ratnadiraw, xutong.ma, Qingfang Deng,
	SkyLake Huang, Chunfeng Yun, Vinod Koul, Kishon Vijay Abraham I,
	Matthias Brugger, AngeloGioacchino Del Regno, netdev,
	linux-arm-kernel, linux-mediatek, linux-phy, linux-kernel

There is no function clk_bulk_prepare_disable.  Refer instead to
clk_bulk_disable_unprepare, which is called in the function
defined just below.

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>

---
 drivers/phy/mediatek/phy-mtk-xfi-tphy.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
index 1a0b7484f525..100a50d0e861 100644
--- a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
@@ -353,7 +353,7 @@ static int mtk_xfi_tphy_power_on(struct phy *phy)
  * Disable and unprepare all clocks previously enabled.
  *
  * Return:
- * See clk_bulk_prepare_disable().
+ * See clk_bulk_disable_unprepare().
  */
 static int mtk_xfi_tphy_power_off(struct phy *phy)
 {


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

^ permalink raw reply related

* Re: [PATCH 2/5] dt-bindings: soc: canaan: Add top syscon for Canaan K230 SoC
From: Krzysztof Kozlowski @ 2025-12-30 14:00 UTC (permalink / raw)
  To: Jiayu Du
  Cc: conor, vkoul, gregkh, pjw, palmer, aou, alex, neil.armstrong,
	krzk+dt, linux-riscv, devicetree, linux-kernel, linux-phy,
	linux-usb
In-Reply-To: <aVPQNIhyfR/Da/gk@duge-virtual-machine>

On 30/12/2025 14:14, Jiayu Du wrote:
> On Tue, Dec 30, 2025 at 08:39:19AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Dec 30, 2025 at 10:37:21AM +0800, Jiayu Du wrote:
>>> The Canaan K230 SoC top system controller provides register access
>>> to configure related modules. It includes a USB2 PHY and eMMC/SDIO PHY.
>>>
>>> Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
> ...
>>> +
>>> +  "#size-cells":
>>> +    const: 1
>>> +
>>> +  usb-phy@70:
>>> +    $ref: schemas/phy/canaan,k230-usb-phy.yaml#
>>
>> So that's why you did not have example there? But where did you explain
>> merging strategy/constraints/dependencies? How maintainers can now they
>> can apply this or not?
> 
> Sorry, I will update in v2.
> 
>>
>>
>>> +    unevaluatedProperties: false
>>> +
>>> +  usb-phy@90:
>>> +    $ref: schemas/phy/canaan,k230-usb-phy.yaml#
>>> +    unevaluatedProperties: false
>>
>> Anyway, these are not really real children. Defining child per phy,
>> where each such phy is just few registers, is way too granular. Instead
>> define one phy with phy-cells=2.

Just a note: phy-cells=1, I made mistake before.

>>
>> You also MUST make this device - hisys - binding complete. If you do
>> not, then my review is: fold the children here, because you do not have
>> any other resources for the parent.
> 
> This hisys memory area not only includes the usbphy registers,
> but also contains the registers of sd/mmc phy. Therefore, the
> hisys node is necessary and cannot be folded.

Can be. There is absolutely nothing stopping it.

Anyway, define all nodes.

> 
> 
> If what I said above is accepted by you, do I still need to
> merge the two usb phy nodes by defining one phy with phy-cells=2?

You should read your datasheet, not exactly rely on me guessing. In
current form of the binding, you must fold the child into the parent.

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/5] dt-bindings: soc: canaan: Add top syscon for Canaan K230 SoC
From: Jiayu Du @ 2025-12-30 13:14 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: conor, vkoul, gregkh, pjw, palmer, aou, alex, neil.armstrong,
	krzk+dt, linux-riscv, devicetree, linux-kernel, linux-phy,
	linux-usb
In-Reply-To: <20251230-jumping-visionary-coyote-c0be31@quoll>

On Tue, Dec 30, 2025 at 08:39:19AM +0100, Krzysztof Kozlowski wrote:
> On Tue, Dec 30, 2025 at 10:37:21AM +0800, Jiayu Du wrote:
> > The Canaan K230 SoC top system controller provides register access
> > to configure related modules. It includes a USB2 PHY and eMMC/SDIO PHY.
> > 
> > Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
...
> > +
> > +  "#size-cells":
> > +    const: 1
> > +
> > +  usb-phy@70:
> > +    $ref: schemas/phy/canaan,k230-usb-phy.yaml#
> 
> So that's why you did not have example there? But where did you explain
> merging strategy/constraints/dependencies? How maintainers can now they
> can apply this or not?

Sorry, I will update in v2.

> 
> 
> > +    unevaluatedProperties: false
> > +
> > +  usb-phy@90:
> > +    $ref: schemas/phy/canaan,k230-usb-phy.yaml#
> > +    unevaluatedProperties: false
> 
> Anyway, these are not really real children. Defining child per phy,
> where each such phy is just few registers, is way too granular. Instead
> define one phy with phy-cells=2.
> 
> You also MUST make this device - hisys - binding complete. If you do
> not, then my review is: fold the children here, because you do not have
> any other resources for the parent.

This hisys memory area not only includes the usbphy registers,
but also contains the registers of sd/mmc phy. Therefore, the
hisys node is necessary and cannot be folded.


If what I said above is accepted by you, do I still need to
merge the two usb phy nodes by defining one phy with phy-cells=2?

> 
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    hi_sys_config: syscon@91585000 {
> > +        compatible = "canaan,k230-hisys-cfg", "syscon", "simple-mfd";
> > +        reg = <0x91585000 0x400>;
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +
> > +        usbphy0: usb-phy@70 {
> > +            compatible = "canaan,k230-usb-phy";
> > +            reg = <0x70 0x1C>, <0xb0 0x8>;
> > +            clocks = <&sysclk K230_HS_USB0_AHB_GATE>;
> 
> You never bothered to test your code. Community is not a testing
> service. It's your job to TEST IT before sending.

Sorry, I've realized this now. I'll test it.

Best regards,
jiayu

>
> 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/4] scsi: ufs: phy: dt-bindings: Add QMP UFS PHY compatible for Hamoa
From: Krzysztof Kozlowski @ 2025-12-30 12:08 UTC (permalink / raw)
  To: Pradeep Pragallapati, vkoul, neil.armstrong, robh, krzk+dt,
	conor+dt, martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <d3d63b08-43ba-4b25-a939-416d5d647098@oss.qualcomm.com>

On 30/12/2025 12:13, Pradeep Pragallapati wrote:
> 
> On 12/30/2025 3:08 PM, Krzysztof Kozlowski wrote:
>> On 30/12/2025 10:05, Pradeep Pragallapati wrote:
>>> On 12/29/2025 12:41 PM, Krzysztof Kozlowski wrote:
>>>> On 29/12/2025 07:06, Pradeep P V K wrote:
>>>>> Document the QMP UFS PHY compatible for Qualcomm Hamoa to support
>>>>> physical layer functionality for UFS found on the SoC. Use fallback to
>>>>> indicate the compatibility of the QMP UFS PHY on the Hamoa with that
>>>>> on the SM8550.
>>>> Last sentence is pointless. You keep explaining what you did, but you
>>>> did not say why. Why Hamoa is compatible with SM8550, but not with SM8650?
>>> i will update in my next patchset.
>> Actually the problem is that you introduced completely new SoC name -
>> Hamoa - so that's why I was wondering. If you used correct name, X1E, it
>> would be more logical as it is basically SM8550.
>>
>> But then follow up question - why are you duplicating existing patches?
>>
>> https://lore.kernel.org/linux-devicetree/20250814005904.39173-2-harrison.vanderbyl@gmail.com/
> 
> Hi Krzysztof,
> 
> I’m not familiar with these patches in detail, but I noticed several gaps:
> 
>   * The UFSHC compatibility string was not added in the correct file.
>   * Fallback compatibility was not utilized.
>   * A PHY clock entry is missing.
>   * OPP framework is not used for clock frequency configuration.
>   * |dma-coherency| entry is missing.
>   * UFS nodes are not sorted.
>   * Clock provider entries for the GCC node are missing.
> 
> Additionally, there hasn’t been any follow-up on the comments since 
> August 2025. So, I’d like to take this up with my
> 
> current series.
> 
> Please let me know your thoughts.
> 
>>
>> https://lore.kernel.org/linux-devicetree/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/

The ones here received review. I prefer not to re-review just because
you want to go with your series...

But if you insist, at least do it right. You are re-doing the same work
in worse way.

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 15/23] phy: core: Discard pm_runtime_put() return values
From: Geert Uytterhoeven @ 2025-12-30 10:54 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM, LKML, Ulf Hansson, Brian Norris, Vinod Koul,
	Neil Armstrong, linux-phy, Linux-Renesas
In-Reply-To: <CAMuHMdVMFQebA43FJ53PBnd67C8fxWAC21cr4jWTGDwg-HV53w@mail.gmail.com>

On Tue, 30 Dec 2025 at 11:34, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, 22 Dec 2025 at 21:40, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > The PHY core defines phy_pm_runtime_put() to return an int, but that
> > return value is never used.  It also passes the return value of
> > pm_runtime_put() to the caller which is not very useful.
> >
> > Returning an error code from pm_runtime_put() merely means that it has
> > not queued up a work item to check whether or not the device can be
> > suspended and there are many perfectly valid situations in which that
> > can happen, like after writing "on" to the devices' runtime PM "control"
> > attribute in sysfs for one example.
> >
> > Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
> > value and change its return type to void.  Also drop the redundant
> > pm_runtime_enabled() call from there.
> >
> > No intentional functional impact.
> >
> > This will facilitate a planned change of the pm_runtime_put() return
> > type to void in the future.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Thanks for your patch, which is now commit caad07ae07e3fb17 ("phy:
> core: Discard pm_runtime_put() return values") in phy/next.
>
> This is causing several messages like
>
>     phy phy-e6590100.usb-phy-controller.2: Runtime PM usage count underflow!
>
> during boot, and s2ram on Koelsch (R-Car M2-W).

On R-Car Gen3, there are no such messages, as e.g.
drivers/phy/renesas/phy-rcar-gen3-usb2.c does support Runtime PM.
R-Car Gen2 uses drivers/phy/renesas/phy-rcar-gen2.c, which does not
use Runtime PM yet, but still relies on explicit clock management.

> > --- a/drivers/phy/phy-core.c
> > +++ b/drivers/phy/phy-core.c
> > @@ -190,15 +190,12 @@ int phy_pm_runtime_get_sync(struct phy *
> >  }
> >  EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
> >
> > -int phy_pm_runtime_put(struct phy *phy)
> > +void phy_pm_runtime_put(struct phy *phy)
> >  {
> >         if (!phy)
> > -               return 0;
> > +               return;
> >
> > -       if (!pm_runtime_enabled(&phy->dev))
> > -               return -ENOTSUPP;
>
> Adding some instrumentation shows that this branch was taken before,
> thus skipping the call to pm_runtime_put().
>
> Can I just put the check back, or is there an underlying problem that
> should be fixed instead?

I assume the PHY core should support both drivers that do and do not
support Runtime PM.

> Thanks!
>
> > -
> > -       return pm_runtime_put(&phy->dev);
> > +       pm_runtime_put(&phy->dev);
> >  }
> >  EXPORT_SYMBOL_GPL(phy_pm_runtime_put);

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

^ permalink raw reply

* Re: [PATCH v1 15/23] phy: core: Discard pm_runtime_put() return values
From: Geert Uytterhoeven @ 2025-12-30 10:34 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM, LKML, Ulf Hansson, Brian Norris, Vinod Koul,
	Neil Armstrong, linux-phy, Linux-Renesas
In-Reply-To: <2556645.jE0xQCEvom@rafael.j.wysocki>

Hi Rafael,

On Mon, 22 Dec 2025 at 21:40, Rafael J. Wysocki <rafael@kernel.org> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The PHY core defines phy_pm_runtime_put() to return an int, but that
> return value is never used.  It also passes the return value of
> pm_runtime_put() to the caller which is not very useful.
>
> Returning an error code from pm_runtime_put() merely means that it has
> not queued up a work item to check whether or not the device can be
> suspended and there are many perfectly valid situations in which that
> can happen, like after writing "on" to the devices' runtime PM "control"
> attribute in sysfs for one example.
>
> Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
> value and change its return type to void.  Also drop the redundant
> pm_runtime_enabled() call from there.
>
> No intentional functional impact.
>
> This will facilitate a planned change of the pm_runtime_put() return
> type to void in the future.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Thanks for your patch, which is now commit caad07ae07e3fb17 ("phy:
core: Discard pm_runtime_put() return values") in phy/next.

This is causing several messages like

    phy phy-e6590100.usb-phy-controller.2: Runtime PM usage count underflow!

during boot, and s2ram on Koelsch (R-Car M2-W).

Reverting this commit fixes the issue.

> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -190,15 +190,12 @@ int phy_pm_runtime_get_sync(struct phy *
>  }
>  EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
>
> -int phy_pm_runtime_put(struct phy *phy)
> +void phy_pm_runtime_put(struct phy *phy)
>  {
>         if (!phy)
> -               return 0;
> +               return;
>
> -       if (!pm_runtime_enabled(&phy->dev))
> -               return -ENOTSUPP;

Adding some instrumentation shows that this branch was taken before,
thus skipping the call to pm_runtime_put().

Can I just put the check back, or is there an underlying problem that
should be fixed instead?
Thanks!

> -
> -       return pm_runtime_put(&phy->dev);
> +       pm_runtime_put(&phy->dev);
>  }
>  EXPORT_SYMBOL_GPL(phy_pm_runtime_put);
>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

^ permalink raw reply

* Re: [PATCH V1 1/4] scsi: ufs: phy: dt-bindings: Add QMP UFS PHY compatible for Hamoa
From: Krzysztof Kozlowski @ 2025-12-30  9:38 UTC (permalink / raw)
  To: Pradeep Pragallapati, vkoul, neil.armstrong, robh, krzk+dt,
	conor+dt, martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <86c649c8-7529-45c0-be13-93ff8f05aa44@oss.qualcomm.com>

On 30/12/2025 10:05, Pradeep Pragallapati wrote:
> 
> On 12/29/2025 12:41 PM, Krzysztof Kozlowski wrote:
>> On 29/12/2025 07:06, Pradeep P V K wrote:
>>> Document the QMP UFS PHY compatible for Qualcomm Hamoa to support
>>> physical layer functionality for UFS found on the SoC. Use fallback to
>>> indicate the compatibility of the QMP UFS PHY on the Hamoa with that
>>> on the SM8550.
>> Last sentence is pointless. You keep explaining what you did, but you
>> did not say why. Why Hamoa is compatible with SM8550, but not with SM8650?
> i will update in my next patchset.

Actually the problem is that you introduced completely new SoC name -
Hamoa - so that's why I was wondering. If you used correct name, X1E, it
would be more logical as it is basically SM8550.

But then follow up question - why are you duplicating existing patches?

https://lore.kernel.org/linux-devicetree/20250814005904.39173-2-harrison.vanderbyl@gmail.com/

https://lore.kernel.org/linux-devicetree/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/

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/4] scsi: ufs: phy: dt-bindings: Add QMP UFS PHY compatible for Hamoa
From: Pradeep Pragallapati @ 2025-12-30  9:07 UTC (permalink / raw)
  To: Konrad Dybcio, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
	martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <5c97bac1-d796-4046-9450-65cc99ef7469@oss.qualcomm.com>


On 12/29/2025 5:56 PM, Konrad Dybcio wrote:
> On 12/29/25 7:06 AM, Pradeep P V K wrote:
>> Document the QMP UFS PHY compatible for Qualcomm Hamoa to support
>> physical layer functionality for UFS found on the SoC. Use fallback to
>> indicate the compatibility of the QMP UFS PHY on the Hamoa with that
>> on the SM8550.
>>
>> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
>> ---
>>   .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml    | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
>> index fba7b2549dde..b501f76d8c53 100644
>> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
>> @@ -28,6 +28,10 @@ properties:
>>             - enum:
>>                 - qcom,kaanapali-qmp-ufs-phy
>>             - const: qcom,sm8750-qmp-ufs-phy
>> +      - items:
>> +          - enum:
>> +              - qcom,hamoa-qmp-ufs-phy
>> +          - const: qcom,sm8550-qmp-ufs-phy
> For platforms introduced before we were cleared to use chip codenames,
> let's stay with the numerical identifiers for consistency (i.e. all other
> compatibles in hamoa.dtsi say qcom,x1e80100-xyz)
sure, will update with x1e80100 accordingly.
>
> Konrad

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

^ permalink raw reply

* Re: [PATCH V1 1/4] scsi: ufs: phy: dt-bindings: Add QMP UFS PHY compatible for Hamoa
From: Pradeep Pragallapati @ 2025-12-30  9:05 UTC (permalink / raw)
  To: Krzysztof Kozlowski, vkoul, neil.armstrong, robh, krzk+dt,
	conor+dt, martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <f87a8caf-6c65-48b8-a372-1ebff95cb6f8@kernel.org>


On 12/29/2025 12:41 PM, Krzysztof Kozlowski wrote:
> On 29/12/2025 07:06, Pradeep P V K wrote:
>> Document the QMP UFS PHY compatible for Qualcomm Hamoa to support
>> physical layer functionality for UFS found on the SoC. Use fallback to
>> indicate the compatibility of the QMP UFS PHY on the Hamoa with that
>> on the SM8550.
> Last sentence is pointless. You keep explaining what you did, but you
> did not say why. Why Hamoa is compatible with SM8550, but not with SM8650?
i will update in my next patchset.
>
>
> 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/5] dt-bindings: phy: Add Canaan K230 USB2.0 PHY DT schema
From: Jiayu Du @ 2025-12-30  9:04 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: conor, vkoul, gregkh, pjw, palmer, aou, alex, neil.armstrong,
	krzk+dt, linux-riscv, devicetree, linux-kernel, linux-phy,
	linux-usb
In-Reply-To: <20251230-tricky-hasty-koala-2fc9f0@quoll>

On Tue, Dec 30, 2025 at 08:36:06AM +0100, Krzysztof Kozlowski wrote:
> On Tue, Dec 30, 2025 at 10:37:20AM +0800, Jiayu Du wrote:
> > k230-usb-phy driver supports USB 2.0 phys integrated in Canaan
> 
> Describe hardware, not driver.
> 
> > K230 SoC. Add YAML schema for its binding.
> 
> There is no such stuff as YAML schema for a binding. Look at other
> commits how they phrase it.
> 
> > 
> > Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
I'm truly sorry for taking up your time. Thank you for your patience.
I will carefully revise and test it.

Regards,
Jiayu Du


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

^ permalink raw reply

* Re: [PATCH V1 3/4] arm64: dts: qcom: hamoa: Add UFS nodes for hamoa SoC
From: Pradeep Pragallapati @ 2025-12-30  9:03 UTC (permalink / raw)
  To: Konrad Dybcio, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
	martin.petersen, andersson, konradybcio, taniya.das,
	dmitry.baryshkov
  Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
	nitin.rawat
In-Reply-To: <986facd7-92e7-4d29-a196-d49cd9f3d35f@oss.qualcomm.com>


On 12/29/2025 5:45 PM, Konrad Dybcio wrote:
> On 12/29/25 7:06 AM, Pradeep P V K wrote:
>> Add UFS host controller and PHY nodes for hamoa SoC.
>>
>> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/hamoa.dtsi | 119 +++++++++++++++++++++++++++-
>>   1 file changed, 118 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> index bb7c14d473c9..340b907657be 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -834,7 +834,10 @@ gcc: clock-controller@100000 {
>>   				 <0>,
>>   				 <0>,
>>   				 <0>,
>> -				 <0>;
>> +				 <0>,
>> +				 <&ufs_mem_phy 0>,
>> +				 <&ufs_mem_phy 1>,
>> +				 <&ufs_mem_phy 2>;
> This patch cannot be applied as-is (needs GCC bindings changes first)
> which you didn't mention in the cover letter.
>
> If it were picked up, we'd get DTB valdation errors.
ok, i will mention the link to GCC postings in my cover letter in my 
next patchset.
>
>>   
>>   			power-domains = <&rpmhpd RPMHPD_CX>;
>>   			#clock-cells = <1>;
>> @@ -3845,6 +3848,120 @@ pcie4_phy: phy@1c0e000 {
>>   			status = "disabled";
>>   		};
>>   
>> +		ufs_mem_phy: phy@1d80000 {
>> +			compatible = "qcom,hamoa-qmp-ufs-phy", "qcom,sm8550-qmp-ufs-phy";
>> +			reg = <0x0 0x1d80000 0x0 0x2000>;
> Please pad the address part to 8 hex digits, so 0x1d80000 -> 0x01d80000
>
> [...]
ack. i will update in my next patchset.
>
>> +		ufs_mem_hc: ufs@1d84000 {
>> +			compatible = "qcom,hamoa-ufshc", "qcom,sm8550-ufshc", "qcom,ufshc",
>> +				     "jedec,ufs-2.0";
> 1 a line would be neater, perhaps in the node above too
sure, will update in my next patchset.
>
>> +			reg = <0x0 0x1d84000 0x0 0x3000>;
> Similar case as before
ack. will update in my next patchset.
>
> lgtm otherwise
>
> Konrad

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