* [PATCH 2/3] phy: k1-usb: add disconnect function support
From: Yixun Lan @ 2026-02-12 1:38 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260212-11-k3-usb2-phy-v1-0-43578592405d@kernel.org>
A disconnect status BIT of USB2 PHY need to be cleared, otherwise
it will fail to work properly during next connection when devices
connect to roothub directly.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
drivers/phy/spacemit/phy-k1-usb2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 342061380012..959bf79c7a72 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -48,6 +48,9 @@
#define PHY_CLK_HSTXP_EN BIT(3) /* clock hstxp enable */
#define PHY_HSTXP_MODE BIT(4) /* 0: force en_txp to be 1; 1: no force */
+#define PHY_K1_HS_HOST_DISC 0x40
+#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
+
#define PHY_PLL_DIV_CFG 0x98
#define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
#define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
@@ -142,9 +145,20 @@ static int spacemit_usb2phy_exit(struct phy *phy)
return 0;
}
+static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ regmap_update_bits(sphy->regmap_base, PHY_K1_HS_HOST_DISC,
+ PHY_K1_HS_HOST_DISC_CLR, PHY_K1_HS_HOST_DISC_CLR);
+
+ return 0;
+}
+
static const struct phy_ops spacemit_usb2phy_ops = {
.init = spacemit_usb2phy_init,
.exit = spacemit_usb2phy_exit,
+ .disconnect = spacemit_usb2phy_disconnect,
.owner = THIS_MODULE,
};
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: phy: spacemit: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-12 1:38 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260212-11-k3-usb2-phy-v1-0-43578592405d@kernel.org>
Introduce a compatible string for the USB2 PHY in SpacemiT K3 SoC. The IP
of USB2 PHY mostly shares the same functionalities with K1 SoC, while has
some register layout changes.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
index 43eaca90d88c..18025e5f60d6 100644
--- a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
@@ -4,14 +4,16 @@
$id: http://devicetree.org/schemas/phy/spacemit,usb2-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SpacemiT K1 SoC USB 2.0 PHY
+title: SpacemiT K1/K3 SoC USB 2.0 PHY
maintainers:
- Ze Huang <huang.ze@linux.dev>
properties:
compatible:
- const: spacemit,k1-usb2-phy
+ enum:
+ - spacemit,k1-usb2-phy
+ - spacemit,k3-usb2-phy
reg:
maxItems: 1
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 0/3] phy: spacemit: Add USB2 PHY support for K3 SoC
From: Yixun Lan @ 2026-02-12 1:38 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
The series trys to add USB2 PHY support for SpacemiT K3 SoC,
while patch [2/3] implement a disconnect function which is
needed during next connection.
No DTS part has been inclueded in this series, instead I plan
to submit while adding USB host support.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Yixun Lan (3):
dt-bindings: phy: spacemit: k3: add USB2 PHY support
phy: k1-usb: add disconnect function support
phy: k1-usb: k3: add USB2 PHY support
.../devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++-
drivers/phy/spacemit/phy-k1-usb2.c | 52 +++++++++++++++++++++-
2 files changed, 55 insertions(+), 3 deletions(-)
---
base-commit: dd39930f3d9c1d74a40b79d368e1f3d1555e919c
change-id: 20260124-11-k3-usb2-phy-c4630b990b1f
Best regards,
--
Yixun Lan <dlan@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: kernel test robot @ 2026-02-12 0:39 UTC (permalink / raw)
To: Geert Uytterhoeven, Yoshihiro Shimoda, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Wolfram Sang, Tommaso Merciai
Cc: oe-kbuild-all, linux-phy, linux-mmc, linux-renesas-soc,
linux-next, linux-kernel, Geert Uytterhoeven
In-Reply-To: <67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert+renesas@glider.be>
Hi Geert,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260209]
url: https://github.com/intel-lab-lkp/linux/commits/Geert-Uytterhoeven/phy-renesas-rcar-gen3-usb2-Drop-local-devm_mux_state_get_optional/20260210-185437
base: next-20260209
patch link: https://lore.kernel.org/r/67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert%2Brenesas%40glider.be
patch subject: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20260212/202602120804.JhBk63IH-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260212/202602120804.JhBk63IH-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602120804.JhBk63IH-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/phy/renesas/phy-rcar-gen3-usb2.c: In function 'rcar_gen3_phy_usb2_probe':
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:21: error: implicit declaration of function 'devm_mux_state_get_optional'; did you mean 'devm_regulator_get_optional'? [-Wimplicit-function-declaration]
1029 | mux_state = devm_mux_state_get_optional(dev, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| devm_regulator_get_optional
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:19: error: assignment to 'struct mux_state *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
1029 | mux_state = devm_mux_state_get_optional(dev, NULL);
| ^
vim +1029 drivers/phy/renesas/phy-rcar-gen3-usb2.c
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 946
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 947 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 948 {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 949 struct device *dev = &pdev->dev;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 950 struct rcar_gen3_chan *channel;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 951 struct phy_provider *provider;
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 952 struct mux_state *mux_state;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 953 int ret = 0, i, irq;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 954
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 955 if (!dev->of_node) {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 956 dev_err(dev, "This driver needs device tree\n");
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 957 return -EINVAL;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 958 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 959
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 960 channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 961 if (!channel)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 962 return -ENOMEM;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 963
0b5604affbec02 drivers/phy/renesas/phy-rcar-gen3-usb2.c Chunfeng Yun 2020-11-06 964 channel->base = devm_platform_ioremap_resource(pdev, 0);
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 965 if (IS_ERR(channel->base))
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 966 return PTR_ERR(channel->base);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 967
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 968 channel->dr_mode = rcar_gen3_get_dr_mode(dev->of_node);
73801b90a38ff1 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 969 if (channel->dr_mode != USB_DR_MODE_UNKNOWN) {
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 970 channel->is_otg_channel = true;
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 971 channel->uses_otg_pins = !of_property_read_bool(dev->of_node,
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 972 "renesas,no-otg-pins");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 973 channel->extcon = devm_extcon_dev_allocate(dev,
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 974 rcar_gen3_phy_cable);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 975 if (IS_ERR(channel->extcon))
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 976 return PTR_ERR(channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 977
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 978 ret = devm_extcon_dev_register(dev, channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 979 if (ret < 0) {
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 980 dev_err(dev, "Failed to register extcon\n");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 981 return ret;
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 982 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 983 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 984
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 985 channel->rstc = devm_reset_control_array_get_optional_shared(dev);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 986 if (IS_ERR(channel->rstc))
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 987 return PTR_ERR(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 988
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 989 ret = reset_control_deassert(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 990 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 991 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 992
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 993 ret = devm_add_action_or_reset(dev, rcar_gen3_reset_assert, channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 994 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 995 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 996
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 997 /*
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 998 * devm_phy_create() will call pm_runtime_enable(&phy->dev);
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 999 * And then, phy-core will manage runtime pm for this device.
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1000 */
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1001 ret = devm_pm_runtime_enable(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1002 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1003 return dev_err_probe(dev, ret, "Failed to enable pm_runtime\n");
b0512a6ec0cd6d drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2021-07-27 1004
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1005 channel->phy_data = of_device_get_match_data(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1006 if (!channel->phy_data)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1007 return -EINVAL;
5d8042e95fd471 drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2019-04-10 1008
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1009 platform_set_drvdata(pdev, channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1010 channel->dev = dev;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1011
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1012 ret = rcar_gen3_phy_usb2_init_bus(channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1013 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1014 return ret;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1015
55a387ebb9219c drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1016 spin_lock_init(&channel->lock);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1017 for (i = 0; i < NUM_OF_PHYS; i++) {
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1018 channel->rphys[i].phy = devm_phy_create(dev, NULL,
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1019 channel->phy_data->phy_usb2_ops);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1020 if (IS_ERR(channel->rphys[i].phy))
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1021 return dev_err_probe(dev, PTR_ERR(channel->rphys[i].phy),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1022 "Failed to create USB2 PHY\n");
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1023
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1024 channel->rphys[i].ch = channel;
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1025 channel->rphys[i].int_enable_bits = rcar_gen3_int_enable[i];
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1026 phy_set_drvdata(channel->rphys[i].phy, &channel->rphys[i]);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1027 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1028
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 @1029 mux_state = devm_mux_state_get_optional(dev, NULL);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1030 if (IS_ERR(mux_state))
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1031 return PTR_ERR(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1032 if (mux_state) {
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1033 ret = mux_state_select(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1034 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1035 return dev_err_probe(dev, ret, "Failed to select USB mux\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1036
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1037 ret = devm_add_action_or_reset(dev, rcar_gen3_phy_mux_state_deselect,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1038 mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1039 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1040 return dev_err_probe(dev, ret,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1041 "Failed to register USB mux state deselect\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1042 }
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1043
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1044 if (channel->phy_data->no_adp_ctrl && channel->is_otg_channel) {
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1045 ret = rcar_gen3_phy_usb2_vbus_regulator_register(channel);
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1046 if (ret)
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1047 return ret;
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1048 } else {
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1049 channel->vbus = devm_regulator_get_optional(dev, "vbus");
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1050 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1051 if (IS_ERR(channel->vbus)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1052 if (PTR_ERR(channel->vbus) == -EPROBE_DEFER)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1053 return PTR_ERR(channel->vbus);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1054
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1055 channel->vbus = NULL;
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1056 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1057
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1058 irq = platform_get_irq_optional(pdev, 0);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1059 if (irq < 0 && irq != -ENXIO) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1060 return irq;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1061 } else if (irq > 0) {
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1062 INIT_WORK(&channel->work, rcar_gen3_phy_usb2_work);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1063 ret = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1064 IRQF_SHARED, dev_name(dev), channel);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1065 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1066 return dev_err_probe(dev, ret,
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1067 "Failed to request irq (%d)\n",
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1068 irq);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1069 }
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1070
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1071 provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1072 if (IS_ERR(provider)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1073 return dev_err_probe(dev, PTR_ERR(provider),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1074 "Failed to register PHY provider\n");
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 1075 } else if (channel->is_otg_channel) {
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1076 ret = device_create_file(dev, &dev_attr_role);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1077 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1078 return ret;
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1079 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1080
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1081 return 0;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1082 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1083
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Russell King (Oracle) @ 2026-02-11 20:31 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260211193006.ad2piivyoqhvg22r@skbuf>
On Wed, Feb 11, 2026 at 09:30:06PM +0200, Vladimir Oltean wrote:
> On Wed, Feb 11, 2026 at 06:15:11PM +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> > > My 2 cents: I would actually remove any reference to any sort of preferred
> > > call order. There's nothing in the framework to back up such a concept.
> > > Just say that it is recommended for PHY provider drivers to not rely on
> > > a particular calling order, such that PHY consumers have the freedom to
> > > choose depending on what suits them best.
> >
> > Sending out this patch was a last ditch attempt to get a response to
> > improve the "generic" PHY subsystem, However, as the issue is now
> > almost two weeks old, and the current patch series causes a regression
> > according to Mohd's testing, I've rewritten the series to be a finer
> > set of smaller incremental changes.
> >
> > This has meant dropping the idea of using the "generic" PHY subsystem
> > in generic code, because as "generic" PHY drivers are currently
> > written, that's just impossible given the current state of "generic"
> > PHY.
> >
> > There are "generic" PHY drivers that require to be powered up for
> > any of the phy_set_*() functions to not error out. There are also
> > "generic" PHY drivers that require the PHY to be powered down
> > before calling phy_set_*() before the new setting taking effect
> > at PHY power up time. In this group there are drivers that error
> > out if phy_set_*() is called while the PHY is powered, and there
> > are drivers that silently accept the call, returning success, but
> > do not change the PHY mode.
>
> Are we talking about PHY_MODE_ETHERNET generic PHYs here, or in general?
PHY_MODE_ETHERNET PHYs.
> > This makes it pretty much impossible for platform independent code to
> > know the correct order to call the functions, and what to do if an
> > error or success is returned from any particular API call.
> >
> > In other words, it's a trainwreck as currently implemented, and this
> > was my attempt to try and get some consistency.
>
> Do you have a list of such PHYs relevant to phylink? We can still
> document the expectation, and modify them.
These are the generic PHYs used for ethernet, so they are potential
cases for phylink to drive. They were found via:
grep ETHERNET drivers/phy -rl | xargs grep -l power_on
r8a779f0-ether-serdes: r8a779f0_eth_serdes_set_mode() records the
state, returning success, with no hardware programming. All hardware
programming for the desired mode is done via phy_power_on() call.
This driver requires the PHY to be powered down before phy_set_mode*()
otherwise it will accept the new mode but not reconfigure the hardware.
phy-mvebu-cp110-comphy: mvebu_comphy_set_mode() records the state in
struct members and does nothing more, returning success. This
requires the PHY to be powered down before phy_set_mode().
This driver requires the PHY to be powered down before phy_set_mode*()
otherwise it will accept the new mode but not reconfigure the hardware.
phy-mvebu-a3700-comphy: mvebu_a3700_comphy_set_mode() errors out if
mode is changed with PHY powered up:
/* Mode cannot be changed while the PHY is powered on */
if (phy->power_count &&
(lane->mode != mode || lane->submode != submode))
return -EBUSY;
This driver requires the PHY to be powered down before phy_set_mode*()
otherwise it will error out.
phy-fsl-lynx-28g: lynx_28g_set_mode() powers down the PHY if necessary,
sets the mode, before powering it back up.
This is the only driver that will tolerate phy_power_*() vs
phy_set_mode*() in any order.
phy-qcom-sgmii-eth: doesn't implement phy_set_mode*() but instead
implements phy_set_speed() and phy_calibrate(). phy_set_speed()
sets the mode and immediately calibrates, which presumably requires
the clocks enabled by qcom_dwmac_sgmii_phy_power_on(). No check
for PHY being powered, so my guess is that calling phy_set_speed()
with the PHY powered down will cause the status polling in
qcom_dwmac_sgmii_phy_calibrate() to time out.
This driver requires phy_power_on() before phy_set_speed().
sparx5_serdes: phy_power_*() controls power down mode, no check
in sparx5_serdes_set_mode() whether powered up, but config function
checks for e.g. PLL lock, which probably won't be locked if powered
down. Failures aren't propagated to the API caller.
This driver requires phy_power_on() before phy_set_mode*().
phy-mtk-xfi-tphy: while phy_power_*() controls clocks, it isn't
obvious whether these are required before mtk_xfi_tphy_setup() is
invoked. There are calls to usleep() implying a need to wait for
things to happen before the next register write, which presumably
require the clock to be running.
My guess is, this driver requires phy_power_on() before phy_set_mode*().
Categorisation of drivers:
drivers requiring powered down PHY before phy_set_mode*(), but are
silent if not: 2
drivers requiring powered down PHY before phy_set_mode*(), but error
out if not: 1
drivers that allow any power state before phy_set_mode*(): 1
drivers that do not implement .power_*() methods, allowing any
power state, but presumably require the phy_set_mode*() call to
setup the hardware: 5
drivers requiring powered up PHY before phy_set_mode*(): 3
So, the summary is... only _one_ driver allows the calls in any order.
The other 11 drivers are... stick a pin in the donkey and depending
on where the pin ends up determines the appropriate order that the
generic PHY APIs must be called for the driver to work correctly.
I think you'll agree that this is a very sorry state of affairs.
This is exactly why I think there needs to be better documentation.
I'm not sure that some kind of test code to validate the API would
work, because you'd need some way to test whether the PHY were in a
functional state, and that's difficult without the help of the
ethernet MAC.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-11 19:45 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260211193006.ad2piivyoqhvg22r@skbuf>
On Wed, Feb 11, 2026 at 09:30:06PM +0200, Vladimir Oltean wrote:
> On Wed, Feb 11, 2026 at 06:15:11PM +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> > > My 2 cents: I would actually remove any reference to any sort of preferred
> > > call order. There's nothing in the framework to back up such a concept.
> > > Just say that it is recommended for PHY provider drivers to not rely on
> > > a particular calling order, such that PHY consumers have the freedom to
> > > choose depending on what suits them best.
> >
> > Sending out this patch was a last ditch attempt to get a response to
> > improve the "generic" PHY subsystem, However, as the issue is now
> > almost two weeks old, and the current patch series causes a regression
> > according to Mohd's testing, I've rewritten the series to be a finer
> > set of smaller incremental changes.
> >
> > This has meant dropping the idea of using the "generic" PHY subsystem
> > in generic code, because as "generic" PHY drivers are currently
> > written, that's just impossible given the current state of "generic"
> > PHY.
> >
> > There are "generic" PHY drivers that require to be powered up for
> > any of the phy_set_*() functions to not error out. There are also
> > "generic" PHY drivers that require the PHY to be powered down
> > before calling phy_set_*() before the new setting taking effect
> > at PHY power up time. In this group there are drivers that error
> > out if phy_set_*() is called while the PHY is powered, and there
> > are drivers that silently accept the call, returning success, but
> > do not change the PHY mode.
>
> Are we talking about PHY_MODE_ETHERNET generic PHYs here, or in general?
>
> > This makes it pretty much impossible for platform independent code to
> > know the correct order to call the functions, and what to do if an
> > error or success is returned from any particular API call.
> >
> > In other words, it's a trainwreck as currently implemented, and this
> > was my attempt to try and get some consistency.
>
> Do you have a list of such PHYs relevant to phylink? We can still
> document the expectation, and modify them.
To (partially) answer my own question, here is what I found so far:
commit 5cb630925b49dd13bf3aa43f299b11615c8fe9cd
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed Feb 1 22:14:53 2023 +0900
net: renesas: rswitch: Add phy_power_{on,off}() calling
Some Ethernet PHYs (like marvell10g) will decide the host interface
mode by the media-side speed. So, the rswitch driver needs to
initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports
after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has
.init() for initializing all ports and .power_on() for initializing
each port. So, add phy_power_{on,off} calling for it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This needs to be changed, for sure.
I'll take a closer look tomorrow at the rest and see how bad the
situation is overall.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-11 19:30 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <aYzHL1qwew5p-xoq@shell.armlinux.org.uk>
On Wed, Feb 11, 2026 at 06:15:11PM +0000, Russell King (Oracle) wrote:
> On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> > My 2 cents: I would actually remove any reference to any sort of preferred
> > call order. There's nothing in the framework to back up such a concept.
> > Just say that it is recommended for PHY provider drivers to not rely on
> > a particular calling order, such that PHY consumers have the freedom to
> > choose depending on what suits them best.
>
> Sending out this patch was a last ditch attempt to get a response to
> improve the "generic" PHY subsystem, However, as the issue is now
> almost two weeks old, and the current patch series causes a regression
> according to Mohd's testing, I've rewritten the series to be a finer
> set of smaller incremental changes.
>
> This has meant dropping the idea of using the "generic" PHY subsystem
> in generic code, because as "generic" PHY drivers are currently
> written, that's just impossible given the current state of "generic"
> PHY.
>
> There are "generic" PHY drivers that require to be powered up for
> any of the phy_set_*() functions to not error out. There are also
> "generic" PHY drivers that require the PHY to be powered down
> before calling phy_set_*() before the new setting taking effect
> at PHY power up time. In this group there are drivers that error
> out if phy_set_*() is called while the PHY is powered, and there
> are drivers that silently accept the call, returning success, but
> do not change the PHY mode.
Are we talking about PHY_MODE_ETHERNET generic PHYs here, or in general?
> This makes it pretty much impossible for platform independent code to
> know the correct order to call the functions, and what to do if an
> error or success is returned from any particular API call.
>
> In other words, it's a trainwreck as currently implemented, and this
> was my attempt to try and get some consistency.
Do you have a list of such PHYs relevant to phylink? We can still
document the expectation, and modify them.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types()
From: Felix Gu @ 2026-02-11 18:47 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
linux-phy, linux-kernel
In-Reply-To: <20260210203018.dr6dwj55aob3phsd@skbuf>
On Wed, Feb 11, 2026 at 4:30 AM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Hi Felix,
>
> On Wed, Feb 11, 2026 at 02:14:11AM +0800, Felix Gu wrote:
> > The 'serdes' device_node is obtained using of_get_child_by_name(),
> > which increments the reference count. However, it is never put,
> > leading to a memory leak.
> >
> > Use the __free(device_node) attribute to automatically decrement
> > the reference count when the 'serdes' variable goes out of scope.
> >
> > Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
> > Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> > ---
> > drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> > index 12a19bf2875c..904541e9138e 100644
> > --- a/drivers/phy/ti/phy-j721e-wiz.c
> > +++ b/drivers/phy/ti/phy-j721e-wiz.c
> > @@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
> >
> > static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
> > {
> > - struct device_node *serdes;
> > -
> > - serdes = of_get_child_by_name(dev->of_node, "serdes");
> > + struct device_node *serdes __free(device_node) =
> > + of_get_child_by_name(dev->of_node, "serdes");
> > if (!serdes) {
> > dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__);
> > return -EINVAL;
> >
> > ---
> > base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
> > change-id: 20260204-wiz-9a67604a034f
> >
> > Best regards,
> > --
> > Felix Gu <ustc.gu@gmail.com>
> >
> >
>
> You are fixing a bug from 2020 (v5.8) with functionality introduced in 2023,
> creating avoidable headache for backporters (the oldest supported LTS is
> 5.10, where the cleanup API does not exist). Could we reimplement this
> the "normal" of_node_put() way?
>
> I realize this is not netdev, but this piece of advice from
> Documentation/process/maintainer-netdev.rst regarding use in drivers
> seems common sense and relevant here:
>
> Low level cleanup constructs (such as ``__free()``) can be used when building
> APIs and helpers, especially scoped iterators. However, direct use of
> ``__free()`` within networking core and drivers is discouraged.
> Similar guidance applies to declaring variables mid-function.
Hi Vladimir,
I will fix it in V2.
Thanks,
Felix
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Russell King (Oracle) @ 2026-02-11 18:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260211154839.lbh4uovxr5b5s4nv@skbuf>
On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> My 2 cents: I would actually remove any reference to any sort of preferred
> call order. There's nothing in the framework to back up such a concept.
> Just say that it is recommended for PHY provider drivers to not rely on
> a particular calling order, such that PHY consumers have the freedom to
> choose depending on what suits them best.
Sending out this patch was a last ditch attempt to get a response to
improve the "generic" PHY subsystem, However, as the issue is now
almost two weeks old, and the current patch series causes a regression
according to Mohd's testing, I've rewritten the series to be a finer
set of smaller incremental changes.
This has meant dropping the idea of using the "generic" PHY subsystem
in generic code, because as "generic" PHY drivers are currently
written, that's just impossible given the current state of "generic"
PHY.
There are "generic" PHY drivers that require to be powered up for
any of the phy_set_*() functions to not error out. There are also
"generic" PHY drivers that require the PHY to be powered down
before calling phy_set_*() before the new setting taking effect
at PHY power up time. In this group there are drivers that error
out if phy_set_*() is called while the PHY is powered, and there
are drivers that silently accept the call, returning success, but
do not change the PHY mode.
This makes it pretty much impossible for platform independent code to
know the correct order to call the functions, and what to do if an
error or success is returned from any particular API call.
In other words, it's a trainwreck as currently implemented, and this
was my attempt to try and get some consistency.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: Geert Uytterhoeven @ 2026-02-11 16:30 UTC (permalink / raw)
To: Vinod Koul
Cc: Ulf Hansson, Vladimir Oltean, Yoshihiro Shimoda, Neil Armstrong,
Josua Mayer, Wolfram Sang, Tommaso Merciai, linux-phy, linux-mmc,
linux-renesas-soc, linux-next, linux-kernel
In-Reply-To: <aYyrsPTH1923jV7y@vaman>
Hi Vinod,
On Wed, 11 Feb 2026 at 17:17, Vinod Koul <vkoul@kernel.org> wrote:
> On 10-02-26, 14:34, Ulf Hansson wrote:
> > On Tue, 10 Feb 2026 at 11:53, Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> > > Now the mux core provides devm_mux_state_get_optional():
> > >
> > > drivers/phy/renesas/phy-rcar-gen3-usb2.c:944:1: error: static declaration of ‘devm_mux_state_get_optional’ follows non-static
> > > declaration
> > > 944 | devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > In file included from drivers/phy/renesas/phy-rcar-gen3-usb2.c:20:
> > > include/linux/mux/consumer.h:64:19: note: previous declaration of ‘devm_mux_state_get_optional’ with type ‘struct mux_state *(struct device *, const char *)’
> > > 64 | struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Fix this by dropping the temporary local wrapper.
> > >
> > > Fixes: ad314348ceb4fe1f ("mux: Add helper functions for getting optional and selected mux-state")
> > > Fixes: 8bb92fd7a0407792 ("phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management")
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks Geert for helping out!
> >
> > > ---
> > > - ad314348ceb4fe1f is in mmc/next, and a PR has already been sent
> > > https://lore.kernel.org/20260209133441.556464-1-ulf.hansson@linaro.org
> > > - 8bb92fd7a0407792 is in phy/next
> >
> > Vinod, do you want to pick up the $subject patch as a fix for 7.0-rc1
> > or do you prefer me to handle it?
>
> Should I drop the 8bb92fd7a0407792 and it makes things easier for
> everyone and then we can pick fixed commit for 7.1 cycle..
>
> Does that work for everyone. I was about to send PR, will hold off for a
> bit.
Alternatively, you can mention the semantic conflict in your PR to Linus,
and ask him to fold my patch into the merge commit.
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 next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: kernel test robot @ 2026-02-11 16:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Yoshihiro Shimoda, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Wolfram Sang, Tommaso Merciai
Cc: llvm, oe-kbuild-all, linux-phy, linux-mmc, linux-renesas-soc,
linux-next, linux-kernel, Geert Uytterhoeven
In-Reply-To: <67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert+renesas@glider.be>
Hi Geert,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260209]
url: https://github.com/intel-lab-lkp/linux/commits/Geert-Uytterhoeven/phy-renesas-rcar-gen3-usb2-Drop-local-devm_mux_state_get_optional/20260210-185437
base: next-20260209
patch link: https://lore.kernel.org/r/67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert%2Brenesas%40glider.be
patch subject: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260212/202602120031.iupmQxdk-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260212/202602120031.iupmQxdk-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602120031.iupmQxdk-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:14: error: call to undeclared function 'devm_mux_state_get_optional'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
mux_state = devm_mux_state_get_optional(dev, NULL);
^
drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:14: note: did you mean 'devm_regulator_get_optional'?
include/linux/regulator/consumer.h:163:32: note: 'devm_regulator_get_optional' declared here
struct regulator *__must_check devm_regulator_get_optional(struct device *dev,
^
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:12: error: incompatible integer to pointer conversion assigning to 'struct mux_state *' from 'int' [-Wint-conversion]
mux_state = devm_mux_state_get_optional(dev, NULL);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
vim +/devm_mux_state_get_optional +1029 drivers/phy/renesas/phy-rcar-gen3-usb2.c
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 946
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 947 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 948 {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 949 struct device *dev = &pdev->dev;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 950 struct rcar_gen3_chan *channel;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 951 struct phy_provider *provider;
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 952 struct mux_state *mux_state;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 953 int ret = 0, i, irq;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 954
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 955 if (!dev->of_node) {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 956 dev_err(dev, "This driver needs device tree\n");
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 957 return -EINVAL;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 958 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 959
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 960 channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 961 if (!channel)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 962 return -ENOMEM;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 963
0b5604affbec02 drivers/phy/renesas/phy-rcar-gen3-usb2.c Chunfeng Yun 2020-11-06 964 channel->base = devm_platform_ioremap_resource(pdev, 0);
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 965 if (IS_ERR(channel->base))
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 966 return PTR_ERR(channel->base);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 967
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 968 channel->dr_mode = rcar_gen3_get_dr_mode(dev->of_node);
73801b90a38ff1 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 969 if (channel->dr_mode != USB_DR_MODE_UNKNOWN) {
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 970 channel->is_otg_channel = true;
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 971 channel->uses_otg_pins = !of_property_read_bool(dev->of_node,
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 972 "renesas,no-otg-pins");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 973 channel->extcon = devm_extcon_dev_allocate(dev,
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 974 rcar_gen3_phy_cable);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 975 if (IS_ERR(channel->extcon))
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 976 return PTR_ERR(channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 977
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 978 ret = devm_extcon_dev_register(dev, channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 979 if (ret < 0) {
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 980 dev_err(dev, "Failed to register extcon\n");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 981 return ret;
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 982 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 983 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 984
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 985 channel->rstc = devm_reset_control_array_get_optional_shared(dev);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 986 if (IS_ERR(channel->rstc))
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 987 return PTR_ERR(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 988
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 989 ret = reset_control_deassert(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 990 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 991 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 992
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 993 ret = devm_add_action_or_reset(dev, rcar_gen3_reset_assert, channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 994 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 995 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 996
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 997 /*
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 998 * devm_phy_create() will call pm_runtime_enable(&phy->dev);
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 999 * And then, phy-core will manage runtime pm for this device.
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1000 */
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1001 ret = devm_pm_runtime_enable(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1002 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1003 return dev_err_probe(dev, ret, "Failed to enable pm_runtime\n");
b0512a6ec0cd6d drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2021-07-27 1004
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1005 channel->phy_data = of_device_get_match_data(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1006 if (!channel->phy_data)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1007 return -EINVAL;
5d8042e95fd471 drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2019-04-10 1008
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1009 platform_set_drvdata(pdev, channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1010 channel->dev = dev;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1011
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1012 ret = rcar_gen3_phy_usb2_init_bus(channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1013 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1014 return ret;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1015
55a387ebb9219c drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1016 spin_lock_init(&channel->lock);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1017 for (i = 0; i < NUM_OF_PHYS; i++) {
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1018 channel->rphys[i].phy = devm_phy_create(dev, NULL,
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1019 channel->phy_data->phy_usb2_ops);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1020 if (IS_ERR(channel->rphys[i].phy))
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1021 return dev_err_probe(dev, PTR_ERR(channel->rphys[i].phy),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1022 "Failed to create USB2 PHY\n");
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1023
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1024 channel->rphys[i].ch = channel;
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1025 channel->rphys[i].int_enable_bits = rcar_gen3_int_enable[i];
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1026 phy_set_drvdata(channel->rphys[i].phy, &channel->rphys[i]);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1027 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1028
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 @1029 mux_state = devm_mux_state_get_optional(dev, NULL);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1030 if (IS_ERR(mux_state))
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1031 return PTR_ERR(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1032 if (mux_state) {
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1033 ret = mux_state_select(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1034 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1035 return dev_err_probe(dev, ret, "Failed to select USB mux\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1036
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1037 ret = devm_add_action_or_reset(dev, rcar_gen3_phy_mux_state_deselect,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1038 mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1039 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1040 return dev_err_probe(dev, ret,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1041 "Failed to register USB mux state deselect\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1042 }
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1043
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1044 if (channel->phy_data->no_adp_ctrl && channel->is_otg_channel) {
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1045 ret = rcar_gen3_phy_usb2_vbus_regulator_register(channel);
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1046 if (ret)
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1047 return ret;
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1048 } else {
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1049 channel->vbus = devm_regulator_get_optional(dev, "vbus");
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1050 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1051 if (IS_ERR(channel->vbus)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1052 if (PTR_ERR(channel->vbus) == -EPROBE_DEFER)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1053 return PTR_ERR(channel->vbus);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1054
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1055 channel->vbus = NULL;
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1056 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1057
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1058 irq = platform_get_irq_optional(pdev, 0);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1059 if (irq < 0 && irq != -ENXIO) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1060 return irq;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1061 } else if (irq > 0) {
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1062 INIT_WORK(&channel->work, rcar_gen3_phy_usb2_work);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1063 ret = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1064 IRQF_SHARED, dev_name(dev), channel);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1065 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1066 return dev_err_probe(dev, ret,
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1067 "Failed to request irq (%d)\n",
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1068 irq);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1069 }
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1070
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1071 provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1072 if (IS_ERR(provider)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1073 return dev_err_probe(dev, PTR_ERR(provider),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1074 "Failed to register PHY provider\n");
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 1075 } else if (channel->is_otg_channel) {
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1076 ret = device_create_file(dev, &dev_attr_role);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1077 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1078 return ret;
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1079 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1080
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1081 return 0;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1082 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1083
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: Vinod Koul @ 2026-02-11 16:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Geert Uytterhoeven, Vladimir Oltean, Yoshihiro Shimoda,
Neil Armstrong, Josua Mayer, Wolfram Sang, Tommaso Merciai,
linux-phy, linux-mmc, linux-renesas-soc, linux-next, linux-kernel
In-Reply-To: <CAPDyKFpY2X8hephSfHq7rj_DaKX76ZSkWSCYXrGTEBUFHkvOzg@mail.gmail.com>
On 10-02-26, 14:34, Ulf Hansson wrote:
> On Tue, 10 Feb 2026 at 11:53, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> >
> > Now the mux core provides devm_mux_state_get_optional():
> >
> > drivers/phy/renesas/phy-rcar-gen3-usb2.c:944:1: error: static declaration of ‘devm_mux_state_get_optional’ follows non-static
> > declaration
> > 944 | devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from drivers/phy/renesas/phy-rcar-gen3-usb2.c:20:
> > include/linux/mux/consumer.h:64:19: note: previous declaration of ‘devm_mux_state_get_optional’ with type ‘struct mux_state *(struct device *, const char *)’
> > 64 | struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Fix this by dropping the temporary local wrapper.
> >
> > Fixes: ad314348ceb4fe1f ("mux: Add helper functions for getting optional and selected mux-state")
> > Fixes: 8bb92fd7a0407792 ("phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks Geert for helping out!
>
> > ---
> > - ad314348ceb4fe1f is in mmc/next, and a PR has already been sent
> > https://lore.kernel.org/20260209133441.556464-1-ulf.hansson@linaro.org
> > - 8bb92fd7a0407792 is in phy/next
>
> Vinod, do you want to pick up the $subject patch as a fix for 7.0-rc1
> or do you prefer me to handle it?
Should I drop the 8bb92fd7a0407792 and it makes things easier for
everyone and then we can pick fixed commit for 7.1 cycle..
Does that work for everyone. I was about to send PR, will hold off for a
bit.
Thanks
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-11 15:48 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <E1vo0mF-00000007kbg-1OeA@rmk-PC.armlinux.org.uk>
On Thu, Feb 05, 2026 at 02:56:15PM +0000, Russell King (Oracle) wrote:
> Update the generic PHY documentation as a result of the discussion for
> the s32g submission.
>
> Link: https://lore.kernel.org/r/aXtvDn_-pCuKPrnf@vaman
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> I didn't get any replies to my follow-up question to Vinod:
>
> Please also indicate in the documentation whether changing the submode
> of the serdes (particularly for ethernet) is permitted without doing a
> phy_power_down()..phy_power_up() dance around the phy_set_mode_ext()
> call.
There's certainly nothing *not* permitting that call sequence.
> I also didn't get any response to:
>
> For drivers such as stmmac, it will be important that details such as
> whether phy_est_mode*() can be called with the PHY powered on are
> riveted down and not left up to the generic PHY driver author - without
> that, generic PHYs basically aren't usable from SoC/platform
> independent code, and stmmac has bazillions of platform specific glue
> already because of (a) bad code structuring and (b) lack of
> generalisation through standardised interfaces that abstract platform
> differences.
>
> I want to be able for core stmmac code, or even phylink code (which
> is even more platform generic) to be able to make use of generic PHY
> stuff, but if the calls that can be made into generic PHY are platform
> dependent, that is a blocking issue against that, and makes me question
> why we have the generic PHY subsystem... it's not very generic if it
> exposes the differences of each implementation to users of its
> interfaces.
It may well be that the "one consumer, multiple PHY providers, requiring
unified behaviour" situation you bring up is sufficiently unique here,
with stmmac/phylink, that local conventions are not sufficient.
I'm not sure that precise answers exist for your questions. Rather,
it's best if you could lay out common sense requirements, and generic
PHY reviewers will make sure they are followed.
As far as the framework is concerned, power and mode are fundamentally
decoupled, so I think the documentation is actually muddying the waters,
more than anything, by talking about a preferred calling order.
If there's any connection between power and mode, it should be handled
internally by the PHY provider driver.
> Documentation/driver-api/phy/phy.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
> index 719a2b3fd2ab..cf73e4fb0951 100644
> --- a/Documentation/driver-api/phy/phy.rst
> +++ b/Documentation/driver-api/phy/phy.rst
> @@ -142,6 +142,7 @@ Order of API calls
>
> [devm_][of_]phy_get()
> phy_init()
> + [phy_set_mode[_ext]()]
> phy_power_on()
> [phy_set_mode[_ext]()]
> ...
> @@ -154,7 +155,7 @@ but controllers should always call these functions to be compatible with other
> PHYs. Some PHYs may require :c:func:`phy_set_mode <phy_set_mode_ext>`, while
> others may use a default mode (typically configured via devicetree or other
> firmware). For compatibility, you should always call this function if you know
> -what mode you will be using. Generally, this function should be called after
> +what mode you will be using. Generally, this function should be called before
> :c:func:`phy_power_on`, although some PHY drivers may allow it at any time.
My 2 cents: I would actually remove any reference to any sort of preferred
call order. There's nothing in the framework to back up such a concept.
Just say that it is recommended for PHY provider drivers to not rely on
a particular calling order, such that PHY consumers have the freedom to
choose depending on what suits them best.
>
> Releasing a reference to the PHY
> --
> 2.47.3
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RESEND 1/1] phy: freescale: imx8qm-hsio: provide regmap names
From: Frank Li @ 2026-02-11 15:31 UTC (permalink / raw)
To: Alexander Stein
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260211144949.1128122-1-alexander.stein@ew.tq-group.com>
On Wed, Feb 11, 2026 at 03:49:48PM +0100, Alexander Stein wrote:
> This driver uses multiple regmaps, which will causes name conflicts
> in debugfs like:
> debugfs: '5f1a0000.phy' already exists in 'regmap'
> Fix this by using a dedicated regmap config for each resource, each
> having a dedicated regmap name.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Same as the one sent in December but with an updated CC list.
>
> drivers/phy/freescale/phy-fsl-imx8qm-hsio.c | 23 +++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> index 279b8ac7822df..4ab45c9f53dff 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> @@ -107,7 +107,22 @@ static const char * const lan2_pcieb_clks[] = {"apb_pclk2", "pclk2", "ctl1_crr",
> static const char * const lan2_sata_clks[] = {"pclk2", "epcs_tx", "epcs_rx",
> "phy1_crr", "misc_crr"};
>
> -static const struct regmap_config regmap_config = {
> +static const struct regmap_config regmap_phy_config = {
> + .name = "phy",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config regmap_ctrl_config = {
> + .name = "ctrl",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config regmap_misc_config = {
> + .name = "misc",
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = 4,
> @@ -562,19 +577,19 @@ static int imx_hsio_probe(struct platform_device *pdev)
> return PTR_ERR(priv->base);
>
> off = devm_platform_ioremap_resource_byname(pdev, "phy");
> - priv->phy = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->phy = devm_regmap_init_mmio(dev, off, ®map_phy_config);
> if (IS_ERR(priv->phy))
> return dev_err_probe(dev, PTR_ERR(priv->phy),
> "unable to find phy csr registers\n");
>
> off = devm_platform_ioremap_resource_byname(pdev, "ctrl");
> - priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_ctrl_config);
> if (IS_ERR(priv->ctrl))
> return dev_err_probe(dev, PTR_ERR(priv->ctrl),
> "unable to find ctrl csr registers\n");
>
> off = devm_platform_ioremap_resource_byname(pdev, "misc");
> - priv->misc = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->misc = devm_regmap_init_mmio(dev, off, ®map_misc_config);
> if (IS_ERR(priv->misc))
> return dev_err_probe(dev, PTR_ERR(priv->misc),
> "unable to find misc csr registers\n");
> --
> 2.43.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [RESEND 1/1] phy: freescale: imx8qm-hsio: provide regmap names
From: Alexander Stein @ 2026-02-11 14:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux-phy, imx, linux-arm-kernel, linux-kernel
This driver uses multiple regmaps, which will causes name conflicts
in debugfs like:
debugfs: '5f1a0000.phy' already exists in 'regmap'
Fix this by using a dedicated regmap config for each resource, each
having a dedicated regmap name.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Same as the one sent in December but with an updated CC list.
drivers/phy/freescale/phy-fsl-imx8qm-hsio.c | 23 +++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
index 279b8ac7822df..4ab45c9f53dff 100644
--- a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
+++ b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
@@ -107,7 +107,22 @@ static const char * const lan2_pcieb_clks[] = {"apb_pclk2", "pclk2", "ctl1_crr",
static const char * const lan2_sata_clks[] = {"pclk2", "epcs_tx", "epcs_rx",
"phy1_crr", "misc_crr"};
-static const struct regmap_config regmap_config = {
+static const struct regmap_config regmap_phy_config = {
+ .name = "phy",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static const struct regmap_config regmap_ctrl_config = {
+ .name = "ctrl",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static const struct regmap_config regmap_misc_config = {
+ .name = "misc",
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
@@ -562,19 +577,19 @@ static int imx_hsio_probe(struct platform_device *pdev)
return PTR_ERR(priv->base);
off = devm_platform_ioremap_resource_byname(pdev, "phy");
- priv->phy = devm_regmap_init_mmio(dev, off, ®map_config);
+ priv->phy = devm_regmap_init_mmio(dev, off, ®map_phy_config);
if (IS_ERR(priv->phy))
return dev_err_probe(dev, PTR_ERR(priv->phy),
"unable to find phy csr registers\n");
off = devm_platform_ioremap_resource_byname(pdev, "ctrl");
- priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_config);
+ priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_ctrl_config);
if (IS_ERR(priv->ctrl))
return dev_err_probe(dev, PTR_ERR(priv->ctrl),
"unable to find ctrl csr registers\n");
off = devm_platform_ioremap_resource_byname(pdev, "misc");
- priv->misc = devm_regmap_init_mmio(dev, off, ®map_config);
+ priv->misc = devm_regmap_init_mmio(dev, off, ®map_misc_config);
if (IS_ERR(priv->misc))
return dev_err_probe(dev, PTR_ERR(priv->misc),
"unable to find misc csr registers\n");
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH V5 3/3] arm64: dts: qcom: hamoa-iot-evk: Enable UFS
From: Pradeep P V K @ 2026-02-11 13:29 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, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Enable UFS for HAMOA-IOT-EVK board.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
index 2390648a248f..fccf1d1bdc60 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -1461,6 +1461,24 @@ &uart21 {
status = "okay";
};
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l3i_0p8>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l2i_1p2>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
&usb_1_ss0_dwc3_hs {
remote-endpoint = <&pmic_glink_ss0_hs_in>;
};
--
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 V5 2/3] arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
From: Pradeep P V K @ 2026-02-11 13:29 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, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Add UFS host controller and PHY nodes for x1e80100 SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 122 +++++++++++++++++++++++++++-
1 file changed, 119 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index db65c392e618..5bffff1046e2 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>;
@@ -3869,6 +3869,122 @@ 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: ufshc@1d84000 {
+ compatible = "qcom,x1e80100-ufshc",
+ "qcom,sm8550-ufshc",
+ "qcom,ufshc";
+ 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 V5 1/3] dt-bindings: ufs: qcom,sc7180-ufshc: Add UFSHC compatible for x1e80100
From: Pradeep P V K @ 2026-02-11 13:29 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, Manivannan Sadhasivam,
Krzysztof Kozlowski
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Add UFS Host Controller (UFSHC) compatible for x1e80100 SoC. Use
SM8550 as a fallback since x1e80100 is fully compatible with it.
Qualcomm UFSHC is no longer compatible with JEDEC UFS-2.0 binding.
Avoid using the "jedec,ufs-2.0" string in the compatible property.
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
.../bindings/ufs/qcom,sc7180-ufshc.yaml | 36 +++++++++++--------
1 file changed, 21 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..fe18e41ebac7 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
@@ -31,21 +31,27 @@ select:
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
+ - 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 V5 0/3] Add UFS support for x1e80100 SoC
From: Pradeep P V K @ 2026-02-11 13:29 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 V5:
- Rebased on linux-next (next-20260210) to resolve merge conflicts.
- Add RB-by for UFSHC dt-binding [Krzysztof]
- Add AB-by for UFSHC dt-binding [Mani]
- Add RB-by for SoC dtsi [Konrad, Abel, Taniya, Mani]
- Add RB-by for board dts [Konrad, Mani]
- Link to V4:
https://lore.kernel.org/all/20260106154207.1871487-1-pradeep.pragallapati@oss.qualcomm.com
Changes in V4:
- Update ufs@ with ufshc@ in SoC dtsi [Mani]
- Retain complete change history in cover letter [Dmitry]
- Remove "jedec,ufs-2.0" compatible from ufshc dt-bindings
and SoC dtsi files [Krzysztof, Mani]
- Remove RB-by tag from Krzysztof and AB-by tag from Mani on
UFSHC dt-binding file as it has changes and needs re-review.
- Add RB-by for QMP UFS PHY dt-binding [Krzysztof]
- Add RB-by for SoC dtsi [Konrad, Abel, Taniya, Mani]
- Add RB-by for board dts [Konrad]
- Link to V3:
https://lore.kernel.org/all/0689ae93-0684-4bf8-9bce-f9f32e56fe06@oss.qualcomm.com
Changes in V3:
- Update all dt-bindings commit messages with concise and informative
statements [Krzysztof]
- keep the QMP UFS PHY order by last compatible in numerical ascending
order [Krzysztof]
- Remove qcom,x1e80100-ufshc from select: enum: list of
qcom,sc7180-ufshc.yaml file [Krzysztof]
- Update subject prefix for all dt-bindings [Krzysztof]
- Add RB-by for SoC dtsi [Konrad, Abel, Taniya]
- Add RB-by for board dts [Konrad]
- Link to V2:
https://lore.kernel.org/all/20251231101951.1026163-1-pradeep.pragallapati@oss.qualcomm.com
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 (3):
dt-bindings: ufs: qcom,sc7180-ufshc: Add UFSHC compatible for x1e80100
arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
arm64: dts: qcom: hamoa-iot-evk: Enable UFS
.../bindings/ufs/qcom,sc7180-ufshc.yaml | 36 +++---
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 18 +++
arch/arm64/boot/dts/qcom/hamoa.dtsi | 122 +++++++++++++++++-
3 files changed, 158 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 0/2] phy: microchip: lan966x: Allow to invert N and P signals
From: Vladimir Oltean @ 2026-02-11 12:22 UTC (permalink / raw)
To: Horatiu Vultur
Cc: Vladimir Oltean, vkoul, kishon, robh, krzk+dt, conor+dt,
linux-phy, devicetree, linux-kernel, Daniel Golle
In-Reply-To: <20251119192326.4bflaqkh4zvz2rib@skbuf>
Hi Horatiu,
On Wed, Nov 19, 2025 at 09:23:26PM +0200, Vladimir Oltean wrote:
> > Anyway I can wait with this patch series until you get your changes in.
>
> I will keep you copied to the patch set which I hope to send later today.
The generic description I was talking about has been merged as commit
e7556b59ba65 ("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()").
This set should be dropped from Patchwork. You can send a new version
after the merge window closes, or an RFC at any time.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next] phy: apple: apple: Check the actual ioremap return value
From: Vladimir Oltean @ 2026-02-10 20:48 UTC (permalink / raw)
To: Janne Grunau
Cc: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel,
asahi, linux-phy, linux-kernel, Dan Carpenter
In-Reply-To: <20260207-phy-apple-resource-err-ptr-v1-1-78735b07ed2d@jannau.net>
Hello Janne,
On Sat, Feb 07, 2026 at 05:40:34PM +0100, Janne Grunau wrote:
> The address where the devm_ioremap_resource() return value is stored is
> always a valid pointer. Check the actual return value instead as that
> that might be an error value.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
> Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> drivers/phy/apple/atc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> index dc867f368b68748ea953e594ad998d7f965d8d1d..c144e273a555a741b49adfccbe046df83d193e03 100644
> --- a/drivers/phy/apple/atc.c
> +++ b/drivers/phy/apple/atc.c
> @@ -2206,7 +2206,7 @@ static int atcphy_map_resources(struct platform_device *pdev, struct apple_atcph
> for (int i = 0; i < ARRAY_SIZE(resources); i++) {
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resources[i].name);
> *resources[i].addr = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(resources[i].addr))
> + if (IS_ERR(*resources[i].addr))
> return dev_err_probe(atcphy->dev, PTR_ERR(resources[i].addr),
> "Unable to map %s regs", resources[i].name);
This does not seem correct - every call site that tests a pointer for
IS_ERR() also decodes the error using PTR_ERR(). Whereas you are here
creating the pattern "if (IS_ERR(*a)) return PTR_ERR(a)".
Proven practice seems to tell us that insisting to save the
devm_ioremap_resource() return code directly in *resources[i].addr
is too complex here.
Would you consider creating a temporary "void __iomem *addr" local
variable, and set "*resources[i].addr = addr" only once it's validated?
This would make the code obviously correct upon review.
>
>
> ---
> base-commit: dbeea86fecef7cf2b93aded4525d74f6277376ef
> change-id: 20260207-phy-apple-resource-err-ptr-5923d1130465
>
> Best regards,
> --
> Janne Grunau <j@jannau.net>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types()
From: Vladimir Oltean @ 2026-02-10 20:30 UTC (permalink / raw)
To: Felix Gu
Cc: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
linux-phy, linux-kernel
In-Reply-To: <20260211-wiz-v1-1-fdd018d02f33@gmail.com>
Hi Felix,
On Wed, Feb 11, 2026 at 02:14:11AM +0800, Felix Gu wrote:
> The 'serdes' device_node is obtained using of_get_child_by_name(),
> which increments the reference count. However, it is never put,
> leading to a memory leak.
>
> Use the __free(device_node) attribute to automatically decrement
> the reference count when the 'serdes' variable goes out of scope.
>
> Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index 12a19bf2875c..904541e9138e 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
>
> static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
> {
> - struct device_node *serdes;
> -
> - serdes = of_get_child_by_name(dev->of_node, "serdes");
> + struct device_node *serdes __free(device_node) =
> + of_get_child_by_name(dev->of_node, "serdes");
> if (!serdes) {
> dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__);
> return -EINVAL;
>
> ---
> base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
> change-id: 20260204-wiz-9a67604a034f
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
>
You are fixing a bug from 2020 (v5.8) with functionality introduced in 2023,
creating avoidable headache for backporters (the oldest supported LTS is
5.10, where the cleanup API does not exist). Could we reimplement this
the "normal" of_node_put() way?
I realize this is not netdev, but this piece of advice from
Documentation/process/maintainer-netdev.rst regarding use in drivers
seems common sense and relevant here:
Low level cleanup constructs (such as ``__free()``) can be used when building
APIs and helpers, especially scoped iterators. However, direct use of
``__free()`` within networking core and drivers is discouraged.
Similar guidance applies to declaring variables mid-function.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 2/8] phy: sort Kconfig and Makefile
From: Vladimir Oltean @ 2026-02-10 19:37 UTC (permalink / raw)
To: Théo Lebrun
Cc: Grégory Clement, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Kishon Vijay Abraham I,
Michael Turquette, Stephen Boyd, Philipp Zabel,
Thomas Bogendoerfer, Neil Armstrong, linux-mips, devicetree,
linux-kernel, linux-phy, linux-clk, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260127-macb-phy-v6-2-cdd840588188@bootlin.com>
Hi Theo,
On Tue, Jan 27, 2026 at 06:09:30PM +0100, Théo Lebrun wrote:
> Neither Kconfig nor Makefile are sorted; reorder them.
>
> $ diff -U100 <(grep ^config drivers/phy/Kconfig) \
> <(grep ^config drivers/phy/Kconfig | sort)
>
> $ diff -U100 <(grep ^obj-\\$ drivers/phy/Makefile) \
> <(grep ^obj-\\$ drivers/phy/Makefile | sort)
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
This patch is appreciated, however it no longer applies on top of
current linux-phy/next.
Since we are in the merge window currently, would you mind reposting in
2 weeks (or as RFC in the meantime)?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 3/8] phy: Add driver for EyeQ5 Ethernet PHY wrapper
From: Vladimir Oltean @ 2026-02-10 19:35 UTC (permalink / raw)
To: Théo Lebrun
Cc: Vladimir Kondratiev, Grégory Clement, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Michael Turquette, Stephen Boyd,
Philipp Zabel, Thomas Bogendoerfer, Neil Armstrong, linux-mips,
devicetree, linux-kernel, linux-phy, linux-clk, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260127-macb-phy-v6-3-cdd840588188@bootlin.com>
Hi Theo,
On Tue, Jan 27, 2026 at 06:09:31PM +0100, Théo Lebrun wrote:
> +static int eq5_phy_init(struct phy *phy)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> + struct eq5_phy_private *priv = inst->priv;
> + struct device *dev = priv->dev;
> + u32 reg;
> +
> + dev_dbg(dev, "phy_init(inst=%td)\n", inst - priv->phys);
Nitpick: can you please remove the debugging prints and maybe add some
trace points to the PHY core if you feel strongly about having some
introspection?
> +
> + writel(0, inst->gp);
> + writel(0, inst->sgmii);
> +
> + udelay(5);
Could you please add a macro or comment hinting at the origin of the
magic number 5 here? You could also place these 3 lines in a common
helper, also called from eq5_phy_exit(), to avoid minor code
duplication.
> +
> + reg = readl(inst->gp) | EQ5_GP_TX_SWRST_DIS | EQ5_GP_TX_M_CLKE |
When you write 0 to inst->gp and then read it back, do you expect to
(a) get back 0 or
(b) are some fields non-resetting?
I see both as inconsistent, since if (a), you can remove the
readl(inst->gp) and expect the same result. And if (b), it also
shouldn't matter if you write zeroes a second time, if it was fine the
first time?
Shortly said, is readl(inst->gp) really needed?
> + EQ5_GP_SYS_SWRST_DIS | EQ5_GP_SYS_M_CLKE |
> + FIELD_PREP(EQ5_GP_RGMII_DRV, 0x9);
Quick sanity check on your proposal to use #phy-cells = <1>. This is not
a request to change anything.
What if you need to customize the RGMII drive strength (or some other
setting, maybe SGMII polarity if that is available) per lane, for a
particular board? How would you do that if each PHY does not have its
own OF node?
> + writel(reg, inst->gp);
> +
> + return 0;
> +}
> +
> +static int eq5_phy_exit(struct phy *phy)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> + struct eq5_phy_private *priv = inst->priv;
> + struct device *dev = priv->dev;
> +
> + dev_dbg(dev, "phy_exit(inst=%td)\n", inst - priv->phys);
> +
> + writel(0, inst->gp);
> + writel(0, inst->sgmii);
> + udelay(5);
> +
> + return 0;
> +}
> +
> +static int eq5_phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> + struct eq5_phy_private *priv = inst->priv;
> + struct device *dev = priv->dev;
> +
> + dev_dbg(dev, "phy_set_mode(inst=%td, mode=%d, submode=%d)\n",
> + inst - priv->phys, mode, submode);
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EOPNOTSUPP;
> +
> + if (!phy_interface_mode_is_rgmii(submode) &&
> + submode != PHY_INTERFACE_MODE_SGMII)
> + return -EOPNOTSUPP;
Both PHYs are equal in capabilities, and support both RGMII and SGMII,
correct? I see the driver is implemented as if they were, but it doesn't
hurt to ask.
> +
> + inst->phy_interface = submode;
Short story: don't rely on the phy_set_mode_ext() -> phy_power_on() order.
Implement the driver so that it works the other way around too.
Long story:
https://lore.kernel.org/netdev/aXzFH09AeIRawCwU@shell.armlinux.org.uk/
> + return 0;
> +}
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types()
From: Felix Gu @ 2026-02-10 18:14 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha
Cc: linux-phy, linux-kernel, Felix Gu
The 'serdes' device_node is obtained using of_get_child_by_name(),
which increments the reference count. However, it is never put,
leading to a memory leak.
Use the __free(device_node) attribute to automatically decrement
the reference count when the 'serdes' variable goes out of scope.
Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 12a19bf2875c..904541e9138e 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
{
- struct device_node *serdes;
-
- serdes = of_get_child_by_name(dev->of_node, "serdes");
+ struct device_node *serdes __free(device_node) =
+ of_get_child_by_name(dev->of_node, "serdes");
if (!serdes) {
dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__);
return -EINVAL;
---
base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
change-id: 20260204-wiz-9a67604a034f
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
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