* [PATCH v3 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..283e3eedc0f31 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,19 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - items:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 0/5] J722S SGMII support
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
For SGMII to actually work on the J722S, the am65-cpsw needs to be extended
as well, which has been submitted for net-next:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1075806
Fallback compatible strings allow for the patches to be applied in any
order and to go through different trees without breaking existing
functionality.
v3:
- Drop am65-cpsw changes from this series, they need to go through net-next
- Fix missing PHY_GMII_SEL_RGMII_ID_MODE and PHY_GMII_SEL_FIXED_TX_DELAY in
gmii-sel driver for RGMII delay mode configuration
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages
- Drop reference to AM64_CPSW_QUIRK_CUT_THRU flag, which only exists in the
TI vendor kernel
Nora Schiffer (5):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/phy/ti/phy-gmii-sel.c | 13 ++++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
5 files changed, 75 insertions(+), 18 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6e9ecb88dc8b7..99a80740cdc6b 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-04-01 12:25 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775045279.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..6e12a75100eb8 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,21 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - items:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH] dt-bindings: display/msm: move DSI PHY bindings to phy/ subdir
From: Vinod Koul @ 2026-04-01 11:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Krishna Manikandan, Jonathan Marek, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, linux-phy
In-Reply-To: <20260305-msm-dsi-phy-v1-1-0a99ac665995@oss.qualcomm.com>
On 05-03-26, 01:47, Dmitry Baryshkov wrote:
> Historically DSI PHY bindings landed to the display/msm subdir, however
> they describe PHYs and as such they should be in the phy/ subdir.
> Follow the example of other Qualcomm display-related PHYs (HDMI, eDP)
> and move bindings for the Qualcomm DSI PHYs to the correct subdir.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/6] drm/sun4i: Support LVDS on D1s/T113 combo D-PHY
From: Parthiban @ 2026-04-01 8:39 UTC (permalink / raw)
To: Kuba Szczodrzyński, Maxime Ripard, Samuel Holland,
Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: parthiban, David Airlie, Simona Vetter, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, linux-phy, devicetree,
dri-devel, paulk
In-Reply-To: <a5f6aeb1-b038-462e-8989-c4da65966134@linumiz.com>
Dear Kuba,
On 2/7/26 2:34 PM, Parthiban wrote:
> On 11/16/25 2:46 PM, Kuba Szczodrzyński wrote:
>> Some Allwinner chips (notably the D1s/T113 and the A100) have a "combo
>> MIPI DSI D-PHY" which is required when using single-link LVDS0. The same
>> PD0..PD9 pins are used for either DSI or LVDS.
>>
>> Other than having to use the combo D-PHY, LVDS output is configured in
>> the same way as on older chips.
>>
>> This series enables the sun6i MIPI D-PHY to also work in LVDS mode. It
>> is then configured by the LCD TCON, which allows connecting a
>> single-link LVDS display panel.
Now I also have the MIPI and LVDS working together on A133. Can I pick your
changes and post a combined series for the display support for A133? This will
also address D1s/T114 as well.
--
Thanks,
Parthiban
https://linumiz.com
https://www.linkedin.com/company/linumiz
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-fixes] phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access
From: Miquel Raynal @ 2026-04-01 8:10 UTC (permalink / raw)
To: Gabor Juhos
Cc: Vinod Koul, Neil Armstrong, Igal Liberman, Kishon Vijay Abraham I,
linux-phy, linux-kernel
In-Reply-To: <141b3528-f83a-4fc3-954f-630ce45e54df@gmail.com>
On 01/04/2026 at 09:13:57 +02, Gabor Juhos <j4g8y7@gmail.com> wrote:
> Hi Miquel,
>
>> Hi Gabor,
>>
>> On 21/03/2026 at 15:42:32 +01, Gabor Juhos <j4g8y7@gmail.com> wrote:
>>
>>> The mvebu_a3700_utmi_phy_power_off() function tries to modify the
>>> USB2_PHY_CTRL register by using the IO address of the PHY IP block along
>>> with the readl/writel IO accessors. However, the register exist in the
>>> USB miscellaneous register space, and as such it must be accessed via
>>> regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function.
>>>
>>> Change the code to use regmap_update_bits() for modífying the register
>>
>> Spurious accent here :-) ^
>>
>> Do you imply that the register access was not working? Or that it was
>> not using the correct API? ...
>
> It was using the wrong API with wrong base address.
>
> The USB2_PHY_CTRL(x) macro gives back an offset relative to the base address of
> the USB miscellaneous registers. However the current code uses that offset with
> the base address of the UTMI PHY registers.
>
> So, instead of modifying the 'USB2 Host PHY Control' register at 0xd005f804 it
> changes the 'USB2 UTMI PHY PLL Control 1' register at 0xd005f004.
Ok, that's what I was asking.
> Since the miscellaneous registers can be accessed only via the regmap obtained
> from a syscon node we have to use the regmap API instead of the generic IO
> accessors.
Yeah yeah, I was asking to clarify the problem, whether it was a
register access issue or an API mismatch in the first place.
>> ... (hence potential issues with locking might arise)
>
> The regmap API uses built-in locking so there should be no locking
> issues.
Yes, that's what I was implying, I was talking about the bare readl()
call here (aka the "incorrect" API).
Thanks,
Miquèl
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-fixes] phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access
From: Gabor Juhos @ 2026-04-01 7:13 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vinod Koul, Neil Armstrong, Igal Liberman, Kishon Vijay Abraham I,
linux-phy, linux-kernel
In-Reply-To: <87zf3o873b.fsf@bootlin.com>
Hi Miquel,
> Hi Gabor,
>
> On 21/03/2026 at 15:42:32 +01, Gabor Juhos <j4g8y7@gmail.com> wrote:
>
>> The mvebu_a3700_utmi_phy_power_off() function tries to modify the
>> USB2_PHY_CTRL register by using the IO address of the PHY IP block along
>> with the readl/writel IO accessors. However, the register exist in the
>> USB miscellaneous register space, and as such it must be accessed via
>> regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function.
>>
>> Change the code to use regmap_update_bits() for modífying the register
>
> Spurious accent here :-) ^
>
> Do you imply that the register access was not working? Or that it was
> not using the correct API? ...
It was using the wrong API with wrong base address.
The USB2_PHY_CTRL(x) macro gives back an offset relative to the base address of
the USB miscellaneous registers. However the current code uses that offset with
the base address of the UTMI PHY registers.
So, instead of modifying the 'USB2 Host PHY Control' register at 0xd005f804 it
changes the 'USB2 UTMI PHY PLL Control 1' register at 0xd005f004.
Since the miscellaneous registers can be accessed only via the regmap obtained
from a syscon node we have to use the regmap API instead of the generic IO
accessors.
> ... (hence potential issues with locking might arise)
The regmap API uses built-in locking so there should be no locking issues.
Regards,
Gabor
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v8 4/4] phy: qualcomm: add MSM8974 HDMI PHY support
From: Dmitry Baryshkov @ 2026-04-01 3:38 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260401-fd-hdmi-phy-v8-0-51b0e98edf6c@oss.qualcomm.com>
Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 282 +++++++++++++++++++++++++++++
1 file changed, 282 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
index 720757f8f393..801e304801b3 100644
--- a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
+++ b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
@@ -6,10 +6,13 @@
* Author: Rob Clark <robdclark@gmail.com>
*/
+#include <linux/bitfield.h>
#include <linux/delay.h>
#include <linux/iopoll.h>
+#include <linux/math64.h>
#include "phy-qcom-hdmi-preqmp.h"
+#include "phy-qcom-uniphy.h"
#define REG_HDMI_8x74_ANA_CFG0 0x00000000
#define REG_HDMI_8x74_ANA_CFG1 0x00000004
@@ -31,8 +34,282 @@
#define REG_HDMI_8x74_BIST_PATN3 0x00000048
#define REG_HDMI_8x74_STATUS 0x0000005c
+#define HDMI_8974_VCO_MAX_FREQ 1800000000UL
+#define HDMI_8974_VCO_MIN_FREQ 600000000UL
+
+#define HDMI_8974_COMMON_DIV 5
+
+static inline void write16(u16 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel(val >> 8, reg + 4);
+}
+
+static inline void write24(u32 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel((val >> 8) & 0xff, reg + 4);
+ writel(val >> 16, reg + 8);
+}
+
+static inline u32 read24(void __iomem *reg)
+{
+ u32 val = readl(reg);
+
+ val |= readl(reg + 4) << 8;
+ val |= readl(reg + 8) << 16;
+
+ return val;
+}
+
+static void qcom_uniphy_setup(void __iomem *base, unsigned int ref_freq,
+ bool sdm_mode,
+ bool ref_freq_mult_2,
+ bool dither,
+ unsigned int refclk_div,
+ unsigned int vco_freq)
+{
+ unsigned int int_ref_freq = ref_freq * (ref_freq_mult_2 ? 2 : 1);
+ unsigned int div_in_freq = vco_freq / refclk_div;
+ unsigned int dc_offset = div_in_freq / int_ref_freq - 1;
+ unsigned int sdm_freq_seed;
+ unsigned int val;
+ u64 tmp = div_in_freq % int_ref_freq;
+
+ tmp *= 0x10000;
+ sdm_freq_seed = div_u64(tmp, int_ref_freq);
+
+ val = FIELD_PREP(UNIPHY_PLL_REFCLK_DBLR, ref_freq_mult_2) |
+ FIELD_PREP(UNIPHY_PLL_REFCLK_DIV, refclk_div - 1);
+ writel(val, base + UNIPHY_PLL_REFCLK_CFG);
+
+ if (sdm_mode) {
+ writel(0, base + UNIPHY_PLL_SDM_CFG0);
+ writel(FIELD_PREP(UNIPHY_PLL_SDM_DITHER_EN, dither) | dc_offset,
+ base + UNIPHY_PLL_SDM_CFG1);
+ write24(sdm_freq_seed, base + UNIPHY_PLL_SDM_CFG2);
+ } else {
+ writel(UNIPHY_PLL_SDM_BYP | dc_offset, base + UNIPHY_PLL_SDM_CFG0);
+ writel(0, base + UNIPHY_PLL_SDM_CFG1);
+ write24(0, base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ write16(mult_frac(ref_freq, 5, 1000000), base + UNIPHY_PLL_CAL_CFG8);
+ write16(vco_freq / 16, base + UNIPHY_PLL_CAL_CFG10);
+}
+
+static unsigned long qcom_uniphy_recalc(void __iomem *base, unsigned long parent_rate)
+{
+ unsigned long rate;
+ u32 refclk_cfg;
+ u32 dc_offset;
+ u64 fraq_n;
+ u32 val;
+
+ refclk_cfg = readl(base + UNIPHY_PLL_REFCLK_CFG);
+ if (refclk_cfg & UNIPHY_PLL_REFCLK_DBLR)
+ parent_rate *= 2;
+
+ val = readl(base + UNIPHY_PLL_SDM_CFG0);
+ if (FIELD_GET(UNIPHY_PLL_SDM_BYP, val)) {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_BYP_DIV, val);
+ fraq_n = 0;
+ } else {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_DC_OFFSET,
+ readl(base + UNIPHY_PLL_SDM_CFG1));
+ fraq_n = read24(base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ rate = (dc_offset + 1) * parent_rate;
+ rate += div_u64(fraq_n * parent_rate, 0x10000);
+
+ rate *= FIELD_GET(UNIPHY_PLL_REFCLK_DIV, refclk_cfg) + 1;
+
+ return rate;
+}
+
+static const unsigned int qcom_hdmi_8974_divs[] = {1, 2, 4, 6};
+
+static unsigned long qcom_hdmi_8974_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct qcom_hdmi_preqmp_phy *hdmi_phy = hw_clk_to_phy(hw);
+ u32 div_idx = readl(hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+ unsigned long rate = qcom_uniphy_recalc(hdmi_phy->pll_reg, parent_rate);
+
+ return rate / HDMI_8974_COMMON_DIV / qcom_hdmi_8974_divs[div_idx & 0x3];
+}
+
+static int qcom_hdmi_8974_pll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ unsigned long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ unsigned long max_freq = HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV;
+
+ req->rate = clamp(req->rate, min_freq / 6, max_freq);
+
+ return 0;
+}
+
+static const struct clk_ops qcom_hdmi_8974_pll_ops = {
+ .recalc_rate = qcom_hdmi_8974_pll_recalc_rate,
+ .determine_rate = qcom_hdmi_8974_pll_determine_rate,
+};
+
+static int qcom_hdmi_msm8974_phy_find_div(unsigned long long pixclk)
+{
+ unsigned long long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ int i;
+
+ if (pixclk > HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(qcom_hdmi_8974_divs); i++) {
+ if (pixclk >= min_freq / qcom_hdmi_8974_divs[i])
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_set_rate(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ unsigned long long pixclk = hdmi_phy->hdmi_opts.tmds_char_rate;
+ unsigned long vco_rate;
+ unsigned int div;
+ int div_idx = 0;
+
+ div_idx = qcom_hdmi_msm8974_phy_find_div(pixclk);
+ if (WARN_ON(div_idx < 0))
+ return div_idx;
+
+ div = qcom_hdmi_8974_divs[div_idx];
+ vco_rate = pixclk * HDMI_8974_COMMON_DIV * div;
+
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ writel(0x19, hdmi_phy->pll_reg + UNIPHY_PLL_VCOLPF_CFG);
+ writel(0x0e, hdmi_phy->pll_reg + UNIPHY_PLL_LPFR_CFG);
+ writel(0x20, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC1_CFG);
+ writel(0x0d, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC2_CFG);
+
+ qcom_uniphy_setup(hdmi_phy->pll_reg, 19200000, true, true, true, 1, vco_rate);
+
+ writel(0x10, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG0);
+ writel(0x1a, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG1);
+ writel(0x05, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG2);
+
+ writel(div_idx, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV2_CFG);
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV3_CFG);
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_CAL_CFG2);
+
+ writel(0x1f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(50);
+
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL1);
+ writel(0x10, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0xdb, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
+ writel(0x43, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
+ if (pixclk == 297000000) {
+ writel(0x06, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x03, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else if (pixclk == 268500000) {
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else {
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ }
+
+ writel(0x04, hdmi_phy->pll_reg + UNIPHY_PLL_VREG_CFG);
+
+ writel(0xd0, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG0);
+ writel(0x1a, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG1);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG0);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG1);
+
+ if (pixclk == 268500000)
+ writel(0x11, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+ else
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG3);
+ udelay(200);
+
+ return 0;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_enable(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ int ret;
+ unsigned long status;
+
+ /* Global enable */
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ /* Power up power gen */
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+
+ /* Power up PLL LDO */
+ writel(0x03, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* Poll for PLL ready status */
+ ret = readl_poll_timeout(hdmi_phy->pll_reg + UNIPHY_PLL_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PLL not ready\n");
+ goto err;
+ }
+
+ udelay(350);
+
+ /* Poll for PHY ready status */
+ ret = readl_poll_timeout(hdmi_phy->phy_reg + REG_HDMI_8x74_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PHY not ready\n");
+ goto err;
+ }
+
+ return 0;
+
+err:
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ return ret;
+}
+
static int qcom_hdmi_msm8974_phy_power_on(struct qcom_hdmi_preqmp_phy *hdmi_phy)
{
+ int ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_set_rate(hdmi_phy);
+ if (ret)
+ return ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_enable(hdmi_phy);
+ if (ret)
+ return ret;
+
writel(0x1b, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
writel(0xf2, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_CFG0);
@@ -49,6 +326,10 @@ static int qcom_hdmi_msm8974_phy_power_off(struct qcom_hdmi_preqmp_phy *hdmi_phy
{
writel(0x7f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
return 0;
}
@@ -67,5 +348,6 @@ const struct qcom_hdmi_preqmp_cfg msm8974_hdmi_phy_cfg = {
.power_on = qcom_hdmi_msm8974_phy_power_on,
.power_off = qcom_hdmi_msm8974_phy_power_off,
+ .pll_ops = &qcom_hdmi_8974_pll_ops,
.pll_parent = &msm8974_hdmi_pll_parent,
};
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v8 3/4] phy: qcom-uniphy: add more registers from display PHYs
From: Dmitry Baryshkov @ 2026-04-01 3:38 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260401-fd-hdmi-phy-v8-0-51b0e98edf6c@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI
PHY registers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-uniphy.h | 42 ++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
index e5b79a4dc270..ba9d14aae682 100644
--- a/drivers/phy/qualcomm/phy-qcom-uniphy.h
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -8,10 +8,30 @@
/* PHY registers */
#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_REFCLK_DBLR BIT(0)
+#define UNIPHY_PLL_REFCLK_DIV GENMASK(3, 2)
+
+#define UNIPHY_PLL_POSTDIV1_CFG 0x004
+#define UNIPHY_PLL_CHGPUMP_CFG 0x008
+#define UNIPHY_PLL_VCOLPF_CFG 0x00c
+#define UNIPHY_PLL_VREG_CFG 0x010
#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_DMUX_CFG 0x018
+#define UNIPHY_PLL_AMUX_CFG 0x01c
#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_POSTDIV2_CFG 0x024
+#define UNIPHY_PLL_POSTDIV3_CFG 0x028
+#define UNIPHY_PLL_LPFR_CFG 0x02c
+#define UNIPHY_PLL_LPFC1_CFG 0x030
+#define UNIPHY_PLL_LPFC2_CFG 0x034
#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_BYP BIT(6)
+#define UNIPHY_PLL_SDM_BYP_DIV GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_DITHER_EN BIT(6)
+#define UNIPHY_PLL_SDM_DC_OFFSET GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG2 0x040
#define UNIPHY_PLL_SDM_CFG3 0x044
#define UNIPHY_PLL_SDM_CFG4 0x048
@@ -22,11 +42,33 @@
#define UNIPHY_PLL_LKDET_CFG0 0x05c
#define UNIPHY_PLL_LKDET_CFG1 0x060
#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_TEST_CFG 0x068
#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG1 0x070
+#define UNIPHY_PLL_CAL_CFG2 0x074
+#define UNIPHY_PLL_CAL_CFG3 0x078
+#define UNIPHY_PLL_CAL_CFG4 0x07c
+#define UNIPHY_PLL_CAL_CFG5 0x080
+#define UNIPHY_PLL_CAL_CFG6 0x084
+#define UNIPHY_PLL_CAL_CFG7 0x088
#define UNIPHY_PLL_CAL_CFG8 0x08c
#define UNIPHY_PLL_CAL_CFG9 0x090
#define UNIPHY_PLL_CAL_CFG10 0x094
#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_EFUSE_CFG 0x09c
+#define UNIPHY_PLL_DEBUG_BUS_SEL 0x0a0
+#define UNIPHY_PLL_CTRL_42 0x0a4
+#define UNIPHY_PLL_CTRL_43 0x0a8
+#define UNIPHY_PLL_CTRL_44 0x0ac
+#define UNIPHY_PLL_CTRL_45 0x0b0
+#define UNIPHY_PLL_CTRL_46 0x0b4
+#define UNIPHY_PLL_CTRL_47 0x0b8
+#define UNIPHY_PLL_CTRL_48 0x0bc
#define UNIPHY_PLL_STATUS 0x0c0
+#define UNIPHY_PLL_DEBUG_BUS0 0x0c4
+#define UNIPHY_PLL_DEBUG_BUS1 0x0c8
+#define UNIPHY_PLL_DEBUG_BUS2 0x0cc
+#define UNIPHY_PLL_DEBUG_BUS3 0x0d0
+#define UNIPHY_PLL_CTRL_54 0x0d4
#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v8 2/4] phy: qcom: apq8064-sata: extract UNI PLL register defines
From: Dmitry Baryshkov @ 2026-04-01 3:38 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260401-fd-hdmi-phy-v8-0-51b0e98edf6c@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The "uni" PLL is shared between several PHYS: APQ8064's SATA,
MSM8974/APQ8084 HDMI, MSM8916 DSI, MSM8974/APQ8084 DSI. Extract the
common register names to a separate header with the hope of later having
the common code to handle PLL in those PHYs.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-------------------
drivers/phy/qualcomm/phy-qcom-uniphy.h | 32 ++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
index cae290a6e19f..dd9929429f9a 100644
--- a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
+++ b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
@@ -15,28 +15,7 @@
#include <linux/platform_device.h>
#include <linux/phy/phy.h>
-/* PHY registers */
-#define UNIPHY_PLL_REFCLK_CFG 0x000
-#define UNIPHY_PLL_PWRGEN_CFG 0x014
-#define UNIPHY_PLL_GLB_CFG 0x020
-#define UNIPHY_PLL_SDM_CFG0 0x038
-#define UNIPHY_PLL_SDM_CFG1 0x03C
-#define UNIPHY_PLL_SDM_CFG2 0x040
-#define UNIPHY_PLL_SDM_CFG3 0x044
-#define UNIPHY_PLL_SDM_CFG4 0x048
-#define UNIPHY_PLL_SSC_CFG0 0x04C
-#define UNIPHY_PLL_SSC_CFG1 0x050
-#define UNIPHY_PLL_SSC_CFG2 0x054
-#define UNIPHY_PLL_SSC_CFG3 0x058
-#define UNIPHY_PLL_LKDET_CFG0 0x05C
-#define UNIPHY_PLL_LKDET_CFG1 0x060
-#define UNIPHY_PLL_LKDET_CFG2 0x064
-#define UNIPHY_PLL_CAL_CFG0 0x06C
-#define UNIPHY_PLL_CAL_CFG8 0x08C
-#define UNIPHY_PLL_CAL_CFG9 0x090
-#define UNIPHY_PLL_CAL_CFG10 0x094
-#define UNIPHY_PLL_CAL_CFG11 0x098
-#define UNIPHY_PLL_STATUS 0x0C0
+#include "phy-qcom-uniphy.h"
#define SATA_PHY_SER_CTRL 0x100
#define SATA_PHY_TX_DRIV_CTRL0 0x104
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
new file mode 100644
index 000000000000..e5b79a4dc270
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef PHY_QCOM_UNIPHY_H
+#define PHY_QCOM_UNIPHY_H
+
+/* PHY registers */
+#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_CFG2 0x040
+#define UNIPHY_PLL_SDM_CFG3 0x044
+#define UNIPHY_PLL_SDM_CFG4 0x048
+#define UNIPHY_PLL_SSC_CFG0 0x04c
+#define UNIPHY_PLL_SSC_CFG1 0x050
+#define UNIPHY_PLL_SSC_CFG2 0x054
+#define UNIPHY_PLL_SSC_CFG3 0x058
+#define UNIPHY_PLL_LKDET_CFG0 0x05c
+#define UNIPHY_PLL_LKDET_CFG1 0x060
+#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG8 0x08c
+#define UNIPHY_PLL_CAL_CFG9 0x090
+#define UNIPHY_PLL_CAL_CFG10 0x094
+#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_STATUS 0x0c0
+
+#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v8 0/4] drm/msm/hdmi & phy: use generic PHY framework
From: Dmitry Baryshkov @ 2026-04-01 3:38 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov, Konrad Dybcio, Konrad Dybcio
The MSM HDMI PHYs have been using the ad-hoc approach / API instead of
using the generic API framework. Move MSM HDMI PHY drivers to
drivers/phy/qualcomm and rework them to use generic PHY framework. This
way all the QMP-related code is kept at the same place.
Also MSM8974 HDMI PHY, 28nm DSI PHY and apq8964 SATA PHY now can use
common helpers for the UNI PLL.
This also causes some design changes. Currently on MSM8996 the HDMI PLL
implements clock's set_rate(), while other HDMI PHY drivers used the
ad-hoc PHY API for setting the PLL rate (this includes in-tree MSM8960
driver and posted, but not merged, MSM8974 driver). This might result in
the PLL being set to one rate, while the rest of the PHY being tuned to
work at another rate. Adopt the latter idea and always use
phy_configure() to tune the PHY and set the PLL rate.
Merge strategy: Merge the first patch (either through drm/msm or through
the PHY tree), merge the rest of the patches in the next cycle.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v8:
- Rebased on linux-next, fixing conflicts
- Added missing ids for APQ8084 and MSM8998 (Sashiko)
- Switched to pm_runtime_put() (Sashiko)
- Fixed several missed *1000 after pixclk -> tmds_char_rate conversion
(Sashiko)
- Fixed several math overflows (Sashiko)
- Link to v7: https://patch.msgid.link/20260324-fd-hdmi-phy-v7-0-b41dde8d83b8@oss.qualcomm.com
Changes in v7:
- Fixed the build issue between msm8974 patches.
- Dropped even more writel / readl wrappers (now from QMP PHYs)
- Link to v6: https://lore.kernel.org/r/20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com
Changes in v6:
- Changed MSM8974 HDMI PHY driver to use FIELD_PREP / FIELD_GET (Konrad)
- Fixed rate recalculation for MSM8974 HDMI PHY (Konrad)
- Dropped register read/write wrappers
- Link to v5: https://lore.kernel.org/r/20260314-fd-hdmi-phy-v5-0-58122ae96d3b@oss.qualcomm.com
Changes in v5:
- Kept only a single place which handles extp clk (after PHY power on,
before PHY power off) (Neil)
- Inlined pm_runtime calls in the HDMI TX driver, replaced
pm_runtime_resume_and_get() with pm_runtime_get_sync(), since
atomic_pre_enable() can not fail.
- Renamed registers defines to drop the REG_ prefix.
- Link to v4: https://lore.kernel.org/r/20250520-fd-hdmi-phy-v4-0-fcbaa652ad75@oss.qualcomm.com
Changes in v3-v4:
- Rebased on top of linux-next, solving conflicts
- Squashed add-and-remove patches into a single git mv patch
- Dropped HDMI PHY header patch (merged upstream)
Changes in v2:
- Changed msm8960 / apq8064 to calculate register data instead of using
fixed tables. This extends the list of supported modes.
(Implementation is based on mdss-hdmi-pll-28lpm.c from msm-4.14).
- Fixed the reprogramming of PLL rate on apq8064.
- Merged all non-QMP HDMI PHY drivers into a common PHY_QCOM_HDMI
driver (suggested by Rob Clark)
---
Dmitry Baryshkov (4):
drm/msm/hdmi: switch to generic PHY subsystem
phy: qcom: apq8064-sata: extract UNI PLL register defines
phy: qcom-uniphy: add more registers from display PHYs
phy: qualcomm: add MSM8974 HDMI PHY support
drivers/gpu/drm/msm/Makefile | 7 -
drivers/gpu/drm/msm/hdmi/hdmi.c | 59 +-
drivers/gpu/drm/msm/hdmi/hdmi.h | 80 +--
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 80 ++-
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 226 -------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 51 --
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 761 ----------------------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c | 765 -----------------------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 141 -----
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 44 --
drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 460 --------------
drivers/gpu/drm/msm/registers/display/hdmi.xml | 537 ----------------
drivers/phy/qualcomm/Kconfig | 24 +
drivers/phy/qualcomm/Makefile | 14 +
drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 353 +++++++++++
drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c | 478 ++++++++++++++
drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c | 186 ++++++
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 213 +++++++
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 59 ++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 187 ++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 440 +++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8998.c | 489 +++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 49 ++
drivers/phy/qualcomm/phy-qcom-uniphy.h | 74 +++
25 files changed, 2611 insertions(+), 3189 deletions(-)
---
base-commit: d894dddf2a144f0e1d1cd7a8225c744dc906cdd5
change-id: 20240109-fd-hdmi-phy-44b8319fbcc7
Best regards,
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] phy: realtek: usb2: add support for RTL9607C USB2 PHY
From: Vladimir Oltean @ 2026-03-31 19:36 UTC (permalink / raw)
To: Rustam Adilov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel,
Michael Zavertkin
In-Reply-To: <1884dee6134e1c069e9f68edb2fdcd7f@disroot.org>
On Tue, Mar 31, 2026 at 04:48:08PM +0000, Rustam Adilov wrote:
> I am personally fine with removing the "force_host_disconnect = false" and other
> falses in rtl9607_phy_cfg but i am debating because it wouldn't line up with the rest.
You can also remove the other unnecessary initializations.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 4/6] phy: qcom-qmp-usbc: Rename QCS615 DP PHY variables and functions
From: Dmitry Baryshkov @ 2026-03-31 18:52 UTC (permalink / raw)
To: Shawn Guo
Cc: Vinod Koul, Neil Armstrong, Abel Vesa, Konrad Dybcio, Xiangxu Yin,
Manivannan Sadhasivam, Luca Weiss, linux-kernel, linux-arm-msm,
linux-phy
In-Reply-To: <abVSJ2-mMFf-rsw1@QCOM-aGQu4IUr3Y>
On Sat, Mar 14, 2026 at 08:18:47PM +0800, Shawn Guo wrote:
> On Sat, Mar 14, 2026 at 11:14:56AM +0200, Dmitry Baryshkov wrote:
> > On Sat, Mar 14, 2026 at 01:13:23PM +0800, Shawn Guo wrote:
> > > Commit 81791c45c8e0 ("phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY config
> > > and DP mode support") chose to name QCS615 DP PHY variables/functions
> > > with qmp_v2 prefix, by assuming that QMP PHY registers are versioned
> > > as a whole. However, the reality is that the registers are versioned
> > > in sub-modules like QSERDES COM and QSERDES TXRX respectively, e.g.
> > > QCS615 DP PHY has registers of QSERDES COM v2 and QSERDES TXRX v3.
> > > Thus it may cause confusion that qmp_v2_xxx table and functions access
> > > QSERDES TXRX v3 registers.
> > >
> > > Rename QCS615 DP PHY variables and functions to be prefixed by qcs615
> > > instead of qmp_v2. This better aligns with how the driver names USB3 PHY
> > > variables for QCM2290 etc.
> >
> > Well... I'm a bit reluctant with this one. The driver needs to support
> > DP programming on three platforms: qcs615/sm6150, sdm660 and msm8998. As
> > far as I can see, most of the DP setup between SDM660 and QCS615 is
> > common.
>
> In that case, could we just reuse QCS615 DP tables/functions for SDM660,
> just like QCM2290 USB3 tables being reused for QCS615 and SDM660?
I think so. DP on SDM660 is not supported currently, but it's mostly
because we don't have PMIC support.
>
> Shawn
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] phy: realtek: usb2: introduce read and write functions to driver data
From: Michael Zavertkin @ 2026-03-31 16:51 UTC (permalink / raw)
To: linux-phy
In-Reply-To: <20260330213227.zujvcvsxdfknzltz@skbuf>
On Tue, Mar 31, 2026 at 12:32:27AM +0300, Vladimir Oltean wrote:
> On Tue, Mar 31, 2026 at 12:19:18AM +0300, Vladimir Oltean wrote:
> > On Fri, Mar 27, 2026 at 09:06:34PM +0500, Rustam Adilov wrote:
> > > +static inline u32 phy_read(void __iomem *reg)
> > > +{
> > > + return readl(reg);
> > > +}
> > > +
> > > +static inline u32 phy_read_le(void __iomem *reg)
> > > +{
> > > + return le32_to_cpu(readl(reg));
> > > +}
> > > +
> > > +static inline void phy_write(u32 val, void __iomem *reg)
> > > +{
> > > + writel(val, reg);
> > > +}
> > > +
> > > +static inline void phy_write_le(u32 val, void __iomem *reg)
> > > +{
> > > + writel(cpu_to_le32(val), reg);
> > > +}
> >
> > Please don't name driver-level functions phy_read() and phy_write().
> > That will collide with networking API functions of the same name and
> > will make grep-based code searching more difficult.
> >
> > Also, have you looked at regmap? It has native support for endianness;
> > it supports regmap_field_read()/regmap_field_write() for abstracting
> > registers which may be found at different places for different HW;
> > it offers regmap_read_poll_timeout() so you don't have to pass the
> > function pointer to utmi_wait_register(). It seems the result would be a
> > bit more elegant.
>
> Even if you decide not to use regmap. I thought I should let you know
> that LLM review says:
>
> Are these double byte-swaps intentional?
>
> Since readl() and writel() inherently perform little-endian memory accesses
> and handle byte-swapping on big-endian architectures automatically, won't
> wrapping them in le32_to_cpu() and cpu_to_le32() apply a second, redundant
> byte-swap?
>
> On big-endian systems, wouldn't these double swaps cancel each other out
> and result in a native big-endian access instead of the intended
> little-endian access? If the SoC bus bridge implicitly swaps and requires
> a native access, should __raw_readl() and __raw_writel() (or ioread32be /
> iowrite32be) be used instead to avoid obfuscating it with double-swaps?
>
> Also, does passing the __le32 restricted type returned by cpu_to_le32()
> into writel() (which expects a native u32) trigger Sparse static analysis
> warnings for an incorrect type in argument?
>
> For reference:
> https://elixir.bootlin.com/linux/v6.19.10/source/include/asm-generic/io.h#L184
> /*
> * {read,write}{b,w,l,q}() access little endian memory and return result in
> * native endianness.
> */
There is readl() (and family) function. For most hosts it returns native
endian value (because most systems LE nowadays).
I don't know all context, and don't know exactly why... but for MIPS readl()
returns value in native endianess.
Reference - https://elixir.bootlin.com/linux/v6.19.10/source/arch/mips/include/asm/io.h
So we are in interesting situation, when readl() returns native-endian values (BE in our case),
readl_be() returns BE too, because cpu_to_be32() does nothing on BE system, ioread32() returns BE,
but ioread32be() returns LE because of unconditional swab32(). Using *be
to get LE value... kinda weird. That's why we ended up with these two
functions.
Not a perfect solution, so it would be good to hear others opinions and
come to a more proper solution.
UPD. regmap looks like a pretty good solution for endianess stuff, but
it seems to interfere with current register handling (using struct
offsets as register addresses). So it has to be a big work.
For example, Realtek solves this issue that way -
https://github.com/jameywine/GPL-for-GP3000/blob/5090fbcb6ba743dd7b1314811ef557bad0460147/linux-5.10.x/drivers/usb/host/ehci.h#L742
>
> and yes, your patch does trigger sparse warnings:
> ../drivers/phy/realtek/phy-rtk-usb2.c:153:16: warning: cast to restricted __le32
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: warning: incorrect type in argument 1 (different base types)
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: expected unsigned int val
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: got restricted __le32 [usertype]
>
> Furthermore, please drop the 'inline' keyword from C files and let the
> compiler decide. Your use of this keyword has no value - you declare
> phy_read(), phy_read_le() etc as inline but then assign function
> pointers to them. How can the compiler inline the indirect calls?
Thanks for all other review comments, going to be fixed in next patch
series version.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] phy: realtek: usb2: introduce read and write functions to driver data
From: Michael Zavertkin @ 2026-03-31 16:34 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Rustam Adilov, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Stanley Chang, linux-phy,
devicetree, linux-kernel
In-Reply-To: <20260330213227.zujvcvsxdfknzltz@skbuf>
On Tue, Mar 31, 2026 at 12:32:27AM +0300, Vladimir Oltean wrote:
> On Tue, Mar 31, 2026 at 12:19:18AM +0300, Vladimir Oltean wrote:
> > On Fri, Mar 27, 2026 at 09:06:34PM +0500, Rustam Adilov wrote:
> > > +static inline u32 phy_read(void __iomem *reg)
> > > +{
> > > + return readl(reg);
> > > +}
> > > +
> > > +static inline u32 phy_read_le(void __iomem *reg)
> > > +{
> > > + return le32_to_cpu(readl(reg));
> > > +}
> > > +
> > > +static inline void phy_write(u32 val, void __iomem *reg)
> > > +{
> > > + writel(val, reg);
> > > +}
> > > +
> > > +static inline void phy_write_le(u32 val, void __iomem *reg)
> > > +{
> > > + writel(cpu_to_le32(val), reg);
> > > +}
> >
> > Please don't name driver-level functions phy_read() and phy_write().
> > That will collide with networking API functions of the same name and
> > will make grep-based code searching more difficult.
> >
> > Also, have you looked at regmap? It has native support for endianness;
> > it supports regmap_field_read()/regmap_field_write() for abstracting
> > registers which may be found at different places for different HW;
> > it offers regmap_read_poll_timeout() so you don't have to pass the
> > function pointer to utmi_wait_register(). It seems the result would be a
> > bit more elegant.
>
> Even if you decide not to use regmap. I thought I should let you know
> that LLM review says:
>
> Are these double byte-swaps intentional?
>
> Since readl() and writel() inherently perform little-endian memory accesses
> and handle byte-swapping on big-endian architectures automatically, won't
> wrapping them in le32_to_cpu() and cpu_to_le32() apply a second, redundant
> byte-swap?
>
> On big-endian systems, wouldn't these double swaps cancel each other out
> and result in a native big-endian access instead of the intended
> little-endian access? If the SoC bus bridge implicitly swaps and requires
> a native access, should __raw_readl() and __raw_writel() (or ioread32be /
> iowrite32be) be used instead to avoid obfuscating it with double-swaps?
>
> Also, does passing the __le32 restricted type returned by cpu_to_le32()
> into writel() (which expects a native u32) trigger Sparse static analysis
> warnings for an incorrect type in argument?
>
> For reference:
> https://elixir.bootlin.com/linux/v6.19.10/source/include/asm-generic/io.h#L184
> /*
> * {read,write}{b,w,l,q}() access little endian memory and return result in
> * native endianness.
> */
There is readl() (and family) function. For most hosts it returns native
endian value (because most systems LE nowadays).
I don't know all context, and don't know exactly why... but for MIPS readl()
returns value in native endianess.
Reference - https://elixir.bootlin.com/linux/v6.19.10/source/arch/mips/include/asm/io.h
So we are in interesting situation, when readl() returns native-endian values (BE in our case),
readl_be() returns BE too, because cpu_to_be32() does nothing on BE system, ioread32() returns BE,
but ioread32be() returns LE because of unconditional swab32(). Using *be
to get LE value... kinda weird. That's why we ended up with these two
functions.
Not a perfect solution, so it would be good to hear others opinions and
come to a more proper solution.
UPD. regmap looks like a pretty good solution for endianess stuff, but
it seems to interfere with current register handling (using struct
offsets as register addresses). So it has to be a big work.
For example, Realtek solves this issue that way -
https://github.com/jameywine/GPL-for-GP3000/blob/5090fbcb6ba743dd7b1314811ef557bad0460147/linux-5.10.x/drivers/usb/host/ehci.h#L742
>
> and yes, your patch does trigger sparse warnings:
> ../drivers/phy/realtek/phy-rtk-usb2.c:153:16: warning: cast to restricted __le32
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: warning: incorrect type in argument 1 (different base types)
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: expected unsigned int val
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: got restricted __le32 [usertype]
>
> Furthermore, please drop the 'inline' keyword from C files and let the
> compiler decide. Your use of this keyword has no value - you declare
> phy_read(), phy_read_le() etc as inline but then assign function
> pointers to them. How can the compiler inline the indirect calls?
Thanks for all other review comments, going to be fixed in next patch
series version.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: realtek: usb2: Make configs available for MACH_REALTEK_RTL
From: Rustam Adilov @ 2026-03-31 16:48 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260330215207.stx6qbjr7kctm4xt@skbuf>
On 2026-03-30 21:52, Vladimir Oltean wrote:
> On Fri, Mar 27, 2026 at 09:06:38PM +0500, Rustam Adilov wrote:
>> Add the MACH_REALTEK_RTL to the if statement to make the config
>> options available for Realtek RTL SoCs as well.
>>
>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>> ---
>> drivers/phy/realtek/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/realtek/Kconfig b/drivers/phy/realtek/Kconfig
>> index 75ac7e7c31ae..f9eadffacd18 100644
>> --- a/drivers/phy/realtek/Kconfig
>> +++ b/drivers/phy/realtek/Kconfig
>> @@ -3,7 +3,7 @@
>> # Phy drivers for Realtek platforms
>> #
>>
>> -if ARCH_REALTEK || COMPILE_TEST
>> +if ARCH_REALTEK || MACH_REALTEK_RTL || COMPILE_TEST
>>
>> config PHY_RTK_RTD_USB2PHY
>> tristate "Realtek RTD USB2 PHY Transceiver Driver"
>> --
>> 2.53.0
>>
>>
>
> The file now reads:
>
> if ARCH_REALTEK || MACH_REALTEK_RTL || COMPILE_TEST
>
> ...
>
> endif # ARCH_REALTEK || COMPILE_TEST
>
> Please update the end comment as well.
Good notice, will change it.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] phy: realtek: usb2: add support for RTL9607C USB2 PHY
From: Rustam Adilov @ 2026-03-31 16:48 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel,
Michael Zavertkin
In-Reply-To: <20260330215033.ven3bllyw3jverfg@skbuf>
On 2026-03-30 21:50, Vladimir Oltean wrote:
> On Fri, Mar 27, 2026 at 09:06:37PM +0500, Rustam Adilov wrote:
>> Add support for the usb2 phy of RTL9607C series based SoCs.
>> Add the macros and phy config struct for rtl9607.
>>
>> RTL9607C requires to clear a "force host disconnect" bit in the
>> specific register (which is at an offset from reg_wrap_vstatus)
>> before proceeding with phy parameter writes.
>>
>> Add the bool variable to the driver data struct and hide this whole
>> procedure under the if statement that checks this new variable.
>>
>> Co-developed-by: Michael Zavertkin <misha.zavertkin@mail.ru>
>> Signed-off-by: Michael Zavertkin <misha.zavertkin@mail.ru>
>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>> ---
>> drivers/phy/realtek/phy-rtk-usb2.c | 57 ++++++++++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>>
>> diff --git a/drivers/phy/realtek/phy-rtk-usb2.c b/drivers/phy/realtek/phy-rtk-usb2.c
>> index 070cba1e0e0a..bf22d12681dc 100644
>> --- a/drivers/phy/realtek/phy-rtk-usb2.c
>> +++ b/drivers/phy/realtek/phy-rtk-usb2.c
>> @@ -26,6 +26,12 @@
>> #define PHY_VCTRL_SHIFT 8
>> #define PHY_REG_DATA_MASK 0xff
>>
>> +#define PHY_9607_VSTS_BUSY BIT(17)
>> +#define PHY_9607_NEW_REG_REQ BIT(13)
>> +
>> +#define PHY_9607_FORCE_DISCONNECT_REG 0x10
>> +#define PHY_9607_FORCE_DISCONNECT_BIT BIT(5)
>> +
>> #define GET_LOW_NIBBLE(addr) ((addr) & 0x0f)
>> #define GET_HIGH_NIBBLE(addr) (((addr) & 0xf0) >> 4)
>>
>> @@ -109,6 +115,7 @@ struct phy_cfg {
>>
>> u32 (*read)(void __iomem *reg);
>> void (*write)(u32 val, void __iomem *reg);
>> + bool force_host_disconnect;
>> };
>>
>> struct phy_parameter {
>> @@ -614,6 +621,16 @@ static int do_rtk_phy_init(struct rtk_phy *rtk_phy, int index)
>> goto do_toggle;
>> }
>>
>> + if (phy_cfg->force_host_disconnect) {
>> + /* disable force-host-disconnect */
>> + u32 temp = readl(phy_reg->reg_wrap_vstatus + PHY_9607_FORCE_DISCONNECT_REG);
>> +
>> + temp &= ~PHY_9607_FORCE_DISCONNECT_BIT;
>> + writel(temp, phy_reg->reg_wrap_vstatus + PHY_9607_FORCE_DISCONNECT_REG);
>> +
>> + mdelay(10);
>
> LLM review:
>
> Could we use msleep(10) or usleep_range(10000, 11000) here instead of
> mdelay(10)?
> Since do_rtk_phy_init() executes as part of the phy_ops->init callback
> with a mutex held from a sleepable process context, spinning the CPU for
> 10ms wastes CPU resources and increases scheduling latency.
I can change it to msleep instead.
>> + }
>> +
>> /* Set page 0 */
>> phy_data_page = phy_cfg->page0;
>> rtk_phy_set_page(phy_reg, 0);
>> @@ -1141,6 +1158,7 @@ static const struct phy_cfg rtd1295_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>
> You don't need to initialize rodata struct fields with false/0/NULL.
From what i can see, it lines up with other phy_cfg structs, and thats how they
did it and it did get accepted. You can check the rtd1295_phy_cfg as an example.
I am personally fine with removing the "force_host_disconnect = false" and other
falses in rtl9607_phy_cfg but i am debating because it wouldn't line up with the rest.
>> };
>>
>> static const struct phy_cfg rtd1395_phy_cfg = {
>> @@ -1170,6 +1188,7 @@ static const struct phy_cfg rtd1395_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1395_phy_cfg_2port = {
>> @@ -1199,6 +1218,7 @@ static const struct phy_cfg rtd1395_phy_cfg_2port = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1619_phy_cfg = {
>> @@ -1226,6 +1246,7 @@ static const struct phy_cfg rtd1619_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1319_phy_cfg = {
>> @@ -1257,6 +1278,7 @@ static const struct phy_cfg rtd1319_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1312c_phy_cfg = {
>> @@ -1287,6 +1309,7 @@ static const struct phy_cfg rtd1312c_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1619b_phy_cfg = {
>> @@ -1317,6 +1340,7 @@ static const struct phy_cfg rtd1619b_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1319d_phy_cfg = {
>> @@ -1347,6 +1371,7 @@ static const struct phy_cfg rtd1319d_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> };
>>
>> static const struct phy_cfg rtd1315e_phy_cfg = {
>> @@ -1378,6 +1403,37 @@ static const struct phy_cfg rtd1315e_phy_cfg = {
>> .new_reg_req = PHY_NEW_REG_REQ,
>> .read = phy_read,
>> .write = phy_write,
>> + .force_host_disconnect = false,
>> +};
>> +
>> +static const struct phy_cfg rtl9607_phy_cfg = {
>> + .page0_size = MAX_USB_PHY_PAGE0_DATA_SIZE,
>> + .page0 = { [0] = {0xe0, 0x95},
>> + [4] = {0xe4, 0x6a},
>> + [12] = {0xf3, 0x31}, },
>> + .page1_size = MAX_USB_PHY_PAGE1_DATA_SIZE,
>> + .page1 = { [0] = {0xe0, 0x26}, },
>> + .page2_size = MAX_USB_PHY_PAGE2_DATA_SIZE,
>> + .page2 = { [7] = {0xe7, 0x33}, },
>> + .num_phy = 1,
>> + .check_efuse = false,
>
> Similar for these (+do_toggle_driving, use_default_parameter).
>
>> + .check_efuse_version = CHECK_EFUSE_V2,
>> + .efuse_dc_driving_rate = EFUS_USB_DC_CAL_RATE,
>> + .dc_driving_mask = 0x1f,
>> + .efuse_dc_disconnect_rate = EFUS_USB_DC_DIS_RATE,
>> + .dc_disconnect_mask = 0xf,
>> + .usb_dc_disconnect_at_page0 = true,
>> + .do_toggle = true,
>> + .do_toggle_driving = false,
>> + .driving_updated_for_dev_dis = 0x8,
>> + .use_default_parameter = false,
>> + .is_double_sensitivity_mode = true,
>> + .vstatus_offset = 0xc,
>> + .vstatus_busy = PHY_9607_VSTS_BUSY,
>> + .new_reg_req = PHY_9607_NEW_REG_REQ,
>> + .read = phy_read_le,
>> + .write = phy_write_le,
>> + .force_host_disconnect = true,
>> };
>>
>> static const struct of_device_id usbphy_rtk_dt_match[] = {
>> @@ -1390,6 +1446,7 @@ static const struct of_device_id usbphy_rtk_dt_match[] = {
>> { .compatible = "realtek,rtd1395-usb2phy-2port", .data = &rtd1395_phy_cfg_2port },
>> { .compatible = "realtek,rtd1619-usb2phy", .data = &rtd1619_phy_cfg },
>> { .compatible = "realtek,rtd1619b-usb2phy", .data = &rtd1619b_phy_cfg },
>> + { .compatible = "realtek,rtl9607-usb2phy", .data = &rtl9607_phy_cfg },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, usbphy_rtk_dt_match);
>> --
>> 2.53.0
>>
>>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/6] phy: realtek: usb2: introduce reset controller struct
From: Rustam Adilov @ 2026-03-31 16:35 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel,
Michael Zavertkin
In-Reply-To: <20260330213955.udqpa77ek7n4arsq@skbuf>
On 2026-03-30 21:39, Vladimir Oltean wrote:
> On Fri, Mar 27, 2026 at 09:06:36PM +0500, Rustam Adilov wrote:
>> In RTL9607C, there is so called "IP Enable Controller" which resemble
>> reset controller with reset lines and is used for various things like
>> USB, PCIE, GMAC and such.
>>
>> Introduce the reset_control struct to this driver to handle deasserting
>> usb2 phy reset line.
>>
>> Make use of the function devm_reset_control_array_get_optional_exclusive()
>> function to get the reset controller and since existing RTD SoCs don't
>> specify the resets we can have a cleaner code.
>>
>> Co-developed-by: Michael Zavertkin <misha.zavertkin@mail.ru>
>> Signed-off-by: Michael Zavertkin <misha.zavertkin@mail.ru>
>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>> ---
>> drivers/phy/realtek/phy-rtk-usb2.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/phy/realtek/phy-rtk-usb2.c b/drivers/phy/realtek/phy-rtk-usb2.c
>> index e65b8525b88b..070cba1e0e0a 100644
>> --- a/drivers/phy/realtek/phy-rtk-usb2.c
>> +++ b/drivers/phy/realtek/phy-rtk-usb2.c
>> @@ -17,6 +17,7 @@
>> #include <linux/sys_soc.h>
>> #include <linux/mfd/syscon.h>
>> #include <linux/phy/phy.h>
>> +#include <linux/reset.h>
>> #include <linux/usb.h>
>>
>> /* GUSB2PHYACCn register */
>> @@ -130,6 +131,7 @@ struct rtk_phy {
>> struct phy_cfg *phy_cfg;
>> int num_phy;
>> struct phy_parameter *phy_parameter;
>> + struct reset_control *phy_rst;
>>
>> struct dentry *debug_dir;
>> };
>> @@ -602,6 +604,10 @@ static int do_rtk_phy_init(struct rtk_phy *rtk_phy, int index)
>> phy_parameter = &((struct phy_parameter *)rtk_phy->phy_parameter)[index];
>> phy_reg = &phy_parameter->phy_reg;
>>
>> + reset_control_deassert(rtk_phy->phy_rst);
>
> LLM review says:
>
> (less important)
> Can reset_control_deassert() fail here? If there is a hardware communication
> error with the reset controller, should this check the return value and
> propagate the error up instead of proceeding to configure the PHY?
> Additionally, since the exclusive reset line is deasserted here, does this
> code need a corresponding reset_control_assert() in the driver's teardown
> or exit path? Leaving the IP block permanently enabled after shutdown could
> lead to power leaks and prevent proper hardware re-initialization.
It realistically shouldn't fail. But I can add the return error for this.
And no, it doesn't need the reset_control_assert.
>> +
>> + mdelay(5);
>
> (more important)
> This code unnecessarily penalizes existing platforms. If rtk_phy->phy_rst
> is NULL (as on older platforms where the optional reset is not defined), the
> delay still executes.
>
> Also, since PHY initialization callbacks run in a sleepable context, would it
> be better to use a sleep-based delay like usleep_range(5000, 6000) to yield
> the CPU instead of busy-waiting with mdelay(5)?
I can change mdelay to msleep and wrap it around something like if (rtk_phy->phy_rst).
>> +
>> if (phy_cfg->use_default_parameter) {
>> dev_dbg(rtk_phy->dev, "%s phy#%d use default parameter\n",
>> __func__, index);
>> @@ -1069,6 +1075,12 @@ static int rtk_usb2phy_probe(struct platform_device *pdev)
>>
>> rtk_phy->num_phy = phy_cfg->num_phy;
>>
>> + rtk_phy->phy_rst = devm_reset_control_array_get_optional_exclusive(dev);
>> + if (IS_ERR(rtk_phy->phy_rst)) {
>> + dev_err(dev, "usb2 phy resets are not working\n");
>> + return PTR_ERR(rtk_phy->phy_rst);
>> + }
>> +
>
> (still LLM review)
> If the reset controller driver is not yet ready, this will return
> -EPROBE_DEFER and print an error message to the kernel log.
> Should this use dev_err_probe() to silently handle probe deferral while
> correctly logging actual errors?
I can change it to dev_err_probe, no problem with that.
>> ret = parse_phy_data(rtk_phy);
>> if (ret)
>> goto err;
>> --
>> 2.53.0
>>
>>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] phy: realtek: usb2: introduce read and write functions to driver data
From: Rustam Adilov @ 2026-03-31 16:26 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel,
Michael Zavertkin
In-Reply-To: <20260330213227.zujvcvsxdfknzltz@skbuf>
On 2026-03-30 21:32, Vladimir Oltean wrote:
> On Tue, Mar 31, 2026 at 12:19:18AM +0300, Vladimir Oltean wrote:
>> On Fri, Mar 27, 2026 at 09:06:34PM +0500, Rustam Adilov wrote:
>> > +static inline u32 phy_read(void __iomem *reg)
>> > +{
>> > + return readl(reg);
>> > +}
>> > +
>> > +static inline u32 phy_read_le(void __iomem *reg)
>> > +{
>> > + return le32_to_cpu(readl(reg));
>> > +}
>> > +
>> > +static inline void phy_write(u32 val, void __iomem *reg)
>> > +{
>> > + writel(val, reg);
>> > +}
>> > +
>> > +static inline void phy_write_le(u32 val, void __iomem *reg)
>> > +{
>> > + writel(cpu_to_le32(val), reg);
>> > +}
>>
>> Please don't name driver-level functions phy_read() and phy_write().
>> That will collide with networking API functions of the same name and
>> will make grep-based code searching more difficult.
>>
>> Also, have you looked at regmap? It has native support for endianness;
>> it supports regmap_field_read()/regmap_field_write() for abstracting
>> registers which may be found at different places for different HW;
>> it offers regmap_read_poll_timeout() so you don't have to pass the
>> function pointer to utmi_wait_register(). It seems the result would be a
>> bit more elegant.
>
> Even if you decide not to use regmap. I thought I should let you know
> that LLM review says:
>
> Are these double byte-swaps intentional?
>
> Since readl() and writel() inherently perform little-endian memory accesses
> and handle byte-swapping on big-endian architectures automatically, won't
> wrapping them in le32_to_cpu() and cpu_to_le32() apply a second, redundant
> byte-swap?
From my experience (and also understanding), readl returns value in native endian
and doesn't do byte swapping. The same goes writel.
Thus wrapping le32_to_cpu() and cpu_to_le32() around them correctly swaps the
bytes from big endian to little endian, without the double byte-swaps.
The comment even mentions it "{read,write}{b,w,l,q}() access little endian memory
and return result in native endianness." which was provided for reference later on.
> On big-endian systems, wouldn't these double swaps cancel each other out
> and result in a native big-endian access instead of the intended
> little-endian access? If the SoC bus bridge implicitly swaps and requires
> a native access, should __raw_readl() and __raw_writel() (or ioread32be /
> iowrite32be) be used instead to avoid obfuscating it with double-swaps?
The __raw_readl() and __raw_writel() are indeed in native endian, and for
RTL9607C SoC it is in big endian.
The way Realtek did it is by using the volatile and wrapping them around
le32_to_cpu() and cpu_to_le32() respectively, which is certainly hacky.
static inline unsigned int ehci_readl(const struct ehci_hcd *ehci,
__u32 __iomem *regs)
{
+#if defined(CONFIG_RTK_MIPS_SOC)
+ return (le32_to_cpu((*(volatile unsigned long *)(regs))));
+#else
[...]
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
+#if defined(CONFIG_RTK_MIPS_SOC)
+ ((*(volatile unsigned long *)(regs))=cpu_to_le32(val));
+#else
We did a bit of debugging with usb some time ago and and printed the value
of the readl result from the base usb address and got this
[ 1.327473] ehci_setup:694 ehci caps: 0xb8021000, value: 0x10000001
[ 1.334478] ehci_setup:695 ehci regs: 0xb8021001
[ 1.339706] ehci_halt:187 ehci regs: 0xb8021001
"0x10000001" is supposed to be "0x01000010". Otherwise, it would take 0x01
for the cap length and result in immediate halt from timeout.
Even though it is for linux-usb and not the phy subsystem, it was worth
mentioning as it is very much related to this issue.
What is surprising, the ioread32be and iowrite32be functions actually do
swap bytes, thus resulting in little endian (ironic). But using it here
would be just incorrect as it is intended for accessing big endian mmio,
not for big endian CPU and its little endian USB phy/host.
So, that is a conundrum we have here. Let me know if what you think of it
and maybe even how to better solve it.
Will hold on posting v3 until this hopefully is more or less solved..
> Also, does passing the __le32 restricted type returned by cpu_to_le32()
> into writel() (which expects a native u32) trigger Sparse static analysis
> warnings for an incorrect type in argument?
>
> For reference:
> https://elixir.bootlin.com/linux/v6.19.10/source/include/asm-generic/io.h#L184
> /*
> * {read,write}{b,w,l,q}() access little endian memory and return result in
> * native endianness.
> */
>
> and yes, your patch does trigger sparse warnings:
> ../drivers/phy/realtek/phy-rtk-usb2.c:153:16: warning: cast to restricted __le32
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: warning: incorrect type in argument 1 (different base types)
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: expected unsigned int val
> ../drivers/phy/realtek/phy-rtk-usb2.c:163:16: got restricted __le32 [usertype]
I can alleviate it by creating a temp u32 variable to hold the cpu_to_le32() and then
using that temp variable for writel.
> Furthermore, please drop the 'inline' keyword from C files and let the
> compiler decide. Your use of this keyword has no value - you declare
> phy_read(), phy_read_le() etc as inline but then assign function
> pointers to them. How can the compiler inline the indirect calls?
Will drop these.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] phy: realtek: usb2: introduce read and write functions to driver data
From: Rustam Adilov @ 2026-03-31 15:45 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel,
Michael Zavertkin
In-Reply-To: <20260330211918.y7su36j47e3uelcv@skbuf>
Hello,
On 2026-03-30 21:19, Vladimir Oltean wrote:
> On Fri, Mar 27, 2026 at 09:06:34PM +0500, Rustam Adilov wrote:
>> +static inline u32 phy_read(void __iomem *reg)
>> +{
>> + return readl(reg);
>> +}
>> +
>> +static inline u32 phy_read_le(void __iomem *reg)
>> +{
>> + return le32_to_cpu(readl(reg));
>> +}
>> +
>> +static inline void phy_write(u32 val, void __iomem *reg)
>> +{
>> + writel(val, reg);
>> +}
>> +
>> +static inline void phy_write_le(u32 val, void __iomem *reg)
>> +{
>> + writel(cpu_to_le32(val), reg);
>> +}
>
> Please don't name driver-level functions phy_read() and phy_write().
> That will collide with networking API functions of the same name and
> will make grep-based code searching more difficult.
I can change it to something like "rtk_phy_read" or "usb2phy_read" then.
> Also, have you looked at regmap? It has native support for endianness;
> it supports regmap_field_read()/regmap_field_write() for abstracting
> registers which may be found at different places for different HW;
> it offers regmap_read_poll_timeout() so you don't have to pass the
> function pointer to utmi_wait_register(). It seems the result would be a
> bit more elegant.
In fact, I did not because it would involve in way more refactoring for patch
series that is supposed to simply add RTL9607C support. And unfortunately,
the regmap is not going to the solve the issue, which i will explain in the
later email to your LLM review on readl/writel.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-fixes] phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access
From: Miquel Raynal @ 2026-03-31 13:24 UTC (permalink / raw)
To: Gabor Juhos
Cc: Vinod Koul, Neil Armstrong, Igal Liberman, Kishon Vijay Abraham I,
linux-phy, linux-kernel
In-Reply-To: <20260321-a3700-utmi-fix-usb2_phy_ctrl-access-v1-1-6005ff4b5058@gmail.com>
Hi Gabor,
On 21/03/2026 at 15:42:32 +01, Gabor Juhos <j4g8y7@gmail.com> wrote:
> The mvebu_a3700_utmi_phy_power_off() function tries to modify the
> USB2_PHY_CTRL register by using the IO address of the PHY IP block along
> with the readl/writel IO accessors. However, the register exist in the
> USB miscellaneous register space, and as such it must be accessed via
> regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function.
>
> Change the code to use regmap_update_bits() for modífying the register
Spurious accent here :-) ^
Do you imply that the register access was not working? Or that it was
not using the correct API? (hence potential issues with locking might arise)
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Miquèl
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/6] phy: qcom-qmp: Clean up QSERDES COM and TXRX register headers
From: Shawn Guo @ 2026-03-31 11:24 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Dmitry Baryshkov, Abel Vesa, Konrad Dybcio,
Xiangxu Yin, Manivannan Sadhasivam, Luca Weiss, linux-kernel,
linux-arm-msm, linux-phy
In-Reply-To: <20260314051325.198137-1-shengchao.guo@oss.qualcomm.com>
On Sat, Mar 14, 2026 at 01:13:19PM +0800, Shawn Guo wrote:
> There are some duplications around QSERDES COM and TXRX v2/v3 register
> definitions. The series tries to clean them up, and also rename
> v2 registers/headers to make the version explicit, just like all other
> versions of the QSERDES registers.
>
> No functional changes is expected.
>
> Shawn Guo (6):
> phy: qcom-qmp: Add missing QSERDES COM v2 registers
> phy: qcom-qmp: Use explicit QSERDES COM v2 register definitions
> phy: qcom-qmp-usbc: Use register definitions in qserdes-txrx-v3
> phy: qcom-qmp-usbc: Rename QCS615 DP PHY variables and functions
> phy: qcom-qmp: Drop unused register headers
> phy: qcom-qmp: Make QSERDES TXRX v2 registers explicit
>
> .../phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c | 110 +++----
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 212 ++++++------
> .../qualcomm/phy-qcom-qmp-qserdes-com-v2.h | 3 +
> .../phy/qualcomm/phy-qcom-qmp-qserdes-com.h | 140 --------
> .../qualcomm/phy-qcom-qmp-qserdes-txrx-v2.h | 247 ++++++++++----
> .../phy/qualcomm/phy-qcom-qmp-qserdes-txrx.h | 205 ------------
> drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 254 +++++++-------
> drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 262 +++++++--------
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 310 +++++++++---------
> drivers/phy/qualcomm/phy-qcom-qmp.h | 3 -
> 10 files changed, 769 insertions(+), 977 deletions(-)
> delete mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com.h
> delete mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx.h
Hi Vinod,
Did you get a chance to look at this, or is there anything I need to do
on my end for this to be applied?
Shawn
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox