* Re: [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Brian Masney @ 2026-01-21 22:53 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-kernel, Chen Wang, Inochi Amaoto, sophgo,
Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Samuel Holland,
linux-arm-kernel, linux-sunxi, Alexandre Belloni, linux-rtc,
Andreas Färber, Manivannan Sadhasivam, linux-actions,
Keguang Zhang, linux-mips, Taichi Sugaya, Takao Orito,
Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Bjorn Andersson, linux-arm-msm, Orson Zhai,
Baolin Wang, Chunyan Zhang, Maxime Coquelin, Alexandre Torgue,
linux-stm32, Michal Simek, Rob Clark, Dmitry Baryshkov,
David Airlie, Simona Vetter, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, dri-devel, freedreno, Vinod Koul,
Neil Armstrong, linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>
Hi Stephen,
On Thu, Jan 08, 2026 at 04:16:18PM -0500, Brian Masney wrote:
> Here's a series that gets rid of the deprecated APIs
> divider_round_rate(), divider_round_rate_parent(), and
> divider_ro_round_rate_parent() since these functions are just wrappers
> for the determine_rate variant.
I sent you a GIT PULL for what can go to Linus for the upcoming merge
window from this series:
https://lore.kernel.org/linux-clk/aXFYU324yQ6uBmk0@redhat.com/T/#u
Thanks,
Brian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Marek Vasut @ 2026-01-21 17:38 UTC (permalink / raw)
To: Geert Uytterhoeven, Mark Brown
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Neil Armstrong, Rob Herring,
Vinod Koul, Yoshihiro Shimoda, devicetree, linux-phy,
linux-renesas-soc
In-Reply-To: <CAMuHMdWfkHMQFvUzaHpso-fMFAS5u8ABHpEA9ZXq1fxcR-oN6Q@mail.gmail.com>
On 1/21/26 2:48 PM, Geert Uytterhoeven wrote:
Hello Geert,
>> @@ -439,6 +445,13 @@ adv7511_out: endpoint {
>> };
>> };
>>
>> + pcie_usb_clk: clk@68 {
>> + compatible = "renesas,9fgv0841";
>> + reg = <0x68>;
>> + clocks = <&pcie_usb_refclk>;
>> + #clock-cells = <1>;
>> + };
>
> During boot, the rs9 prints a warning:
>
> clk-renesas-pcie-9series 0-0068: No cache defaults, reading back from HW
>
> which probably shouldn't be printed at the warning level?
+CC Mark . Reading the (default) register values from hardware on first
boot is the valid/right thing to do, so this could be demoted to
dev_dbg() . Or is there some specific usecase where this should be a
warning ?
>> +
>> video-receiver@70 {
>> compatible = "adi,adv7482";
>> reg = <0x70>;
>
>> @@ -871,7 +902,19 @@ &usb2_phy0 {
>> status = "okay";
>> };
>>
>> +&usb3_phy0 {
>> + clocks = <&pcie_usb_clk 6>;
>> + status = "okay";
>> +};
>
> This does not work, probing fails with:
>
> usb_phy_generic usb-phy: dummy supplies not allowed for exclusive
> requests (id=vbus)
>
> Adding a fixed regulator that serves as vbus-supply like in commit
> fec2d8fcdedaeeb0 ("arm64: dts: freescale: imx93-phyboard-nash: Add USB
> vbus regulators") fixes that issue (and my USB3.0 FLASH driver is
> detected, yeah!), but a more accurate description would be better.
This piece of code in drivers/usb/phy/phy-generic.c [1] shouldn't fail
the probe if "vbus-supply" property is not present in DT. If
"vbus-supply" property is not present in DT, then
PTR_ERR(nop->vbus_draw) == -ENODEV is true, nop->vbus_draw will be set
to NULL, but won't encode error, so the dev_err_probe() won't trigger.
"
259 nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
260 if (PTR_ERR(nop->vbus_draw) == -ENODEV)
261 nop->vbus_draw = NULL;
262 if (IS_ERR(nop->vbus_draw))
263 return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
264 "could not get vbus regulator\n");
"
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy-generic.c#n259
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: Roy Luo @ 2026-01-21 22:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Peter Griffin, André Draszik,
Tudor Ambarus, Joy Chakraborty, Naveen Kumar
Cc: linux-phy, linux-kernel, linux-arm-kernel, linux-samsung-soc,
kernel test robot, Roy Luo
The Google Tensor USB PHY driver uses the Type-C switch framework to
handle orientation changes. However, the Kconfig did not specify a
dependency on the TYPEC framework, leading to undefined reference
errors when building for architectures or configurations where
CONFIG_TYPEC is disabled or configured as a module.
Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
required symbols are available during linking.
Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
Signed-off-by: Roy Luo <royluo@google.com>
---
drivers/phy/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
config PHY_GOOGLE_USB
tristate "Google Tensor SoC USB PHY driver"
+ depends on TYPEC
select GENERIC_PHY
help
Enable support for the USB PHY on Google Tensor SoCs, starting with
---
base-commit: 8bb92fd7a04077925c8330f46a6ab44c80ca59f4
change-id: 20260121-next-b949189cacf4
Best regards,
--
Roy Luo <royluo@google.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-21 17:33 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <20260121162345.4jpzvwqhfqxd7tl7@skbuf>
On Wed, Jan 21, 2026 at 06:23:45PM +0200, Vladimir Oltean wrote:
> On Wed, Jan 21, 2026 at 02:46:42PM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> > > On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > > > First, I'll say I'm on a very short fuse today; no dinner last night,
> > > > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > > > bell at 10am this morning. Just fucking our luck.
> > >
> > > Sorry to hear that.
> > >
> > > > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > > > after calling pcs_disable(), though?
> > > >
> > > > No. We've already called mac_prepare(), pcs_pre_config(),
> > > > pcs_post_config() by this time, we're past the point of being able to
> > > > unwind.
> > >
> > > I'm set out to resolve a much smaller problem.
> > >
> > > Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> > > and pcs_post_config() don't have unwinding equivalents, unlike how
> > > pcs_enable() has pcs_disable(). I don't see what API convention would be
> > > violated if phylink decided to drop a PCS whose enable() returned an error.
> >
> > While pcs_pre_config() and pcs_post_config() do not have unwinding
> > equivalents (what would they be?) the issue here is that these could
> > have changed any state that isn't simply undone by calling
> > pcs_disable().
> >
> > For example, pcs_pre_config() could have reprogrammed signal routing,
> > clocking, or power supplies to blocks.
> >
> > This already applies to Marvell DSA pcs-639x.c, where the pre/post
> > config hooks change the power state of the PCS block (for errata
> > handling), and the only way that gets undone is via a call to
> > pcs_disable() which explicitly disables IRQs and power for the PCS. Its
> > pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
> >
> > We already declare the interface to be dead on pcs_post_config()
> > failure, but we don't do that for pcs_enable() failure.
> >
> > Maybe I need to explicitly state that pcs_disable() does not directly
> > balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
> > and pcs_post_config(). However, that itself will add to the problems.
> > What if pcs_pre_config() and pcs_post_config() succeed but not
> > pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
> > require pcs_disable() to be balanced with a successful call to
> > pcs_enable(), that messes up that driver, and pretty much makes it
> > impossible to work around the errata.
>
> What if we reordered phylink_major_config() such that phylink_pcs_enable()
> comes first, followed by phylink_pcs_pre_config() -> phylink_mac_config() ->
> phylink_pcs_post_config()? Superficially looking at pcs-639x, I don't
> think it would break.
I'm sorry, but I don't have time to continue this discussion today. I
woke late, we're trying to cram in the meals (in the middle of delayed
lunch-time dinner right now), work wants a quick call to discuss a
project that I missed the meeting for yesterday (which I haven't yet
had time for...)
Sorry, but while you may wish to get this sorted, for me this is a very
low priority issue that can be addressed later. Don't think I will have
time to review anything you send - and that's not a personal attack,
it's because I'm barely managing to hold everything together at my
end, and I don't have the time.
--
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
* [PATCH] phy: ti: phy-omap-usb2: Fix a reference leak in omap_usb2_probe()
From: Felix Gu @ 2026-01-21 17:18 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Greg Kroah-Hartman, Roger Quadros
Cc: linux-phy, linux-kernel, Felix Gu
In omap_usb2_probe(), control_node is obtained via of_parse_phandle(),
which increments the refcount.
Add a missing of_node_put() after of_find_device_by_node() to prevent
a reference leak.
Fixes: 478b6c7436c2 ("usb: phy: omap-usb2: Don't use omap_get_control_dev()")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/ti/phy-omap-usb2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/ti/phy-omap-usb2.c b/drivers/phy/ti/phy-omap-usb2.c
index 1eb252604441..660df3181e4f 100644
--- a/drivers/phy/ti/phy-omap-usb2.c
+++ b/drivers/phy/ti/phy-omap-usb2.c
@@ -426,6 +426,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
control_pdev = of_find_device_by_node(control_node);
+ of_node_put(control_node);
if (!control_pdev) {
dev_err(&pdev->dev, "Failed to get control device\n");
return -EINVAL;
---
base-commit: 053966c344dbd346e71305f530e91ea77916189f
change-id: 20260122-phy-omap-usb2-0dff7b055d41
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
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-21 16:23 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <aXDm0jVOYOZ9l6Wu@shell.armlinux.org.uk>
On Wed, Jan 21, 2026 at 02:46:42PM +0000, Russell King (Oracle) wrote:
> On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> > On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > > First, I'll say I'm on a very short fuse today; no dinner last night,
> > > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > > bell at 10am this morning. Just fucking our luck.
> >
> > Sorry to hear that.
> >
> > > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > > after calling pcs_disable(), though?
> > >
> > > No. We've already called mac_prepare(), pcs_pre_config(),
> > > pcs_post_config() by this time, we're past the point of being able to
> > > unwind.
> >
> > I'm set out to resolve a much smaller problem.
> >
> > Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> > and pcs_post_config() don't have unwinding equivalents, unlike how
> > pcs_enable() has pcs_disable(). I don't see what API convention would be
> > violated if phylink decided to drop a PCS whose enable() returned an error.
>
> While pcs_pre_config() and pcs_post_config() do not have unwinding
> equivalents (what would they be?) the issue here is that these could
> have changed any state that isn't simply undone by calling
> pcs_disable().
>
> For example, pcs_pre_config() could have reprogrammed signal routing,
> clocking, or power supplies to blocks.
>
> This already applies to Marvell DSA pcs-639x.c, where the pre/post
> config hooks change the power state of the PCS block (for errata
> handling), and the only way that gets undone is via a call to
> pcs_disable() which explicitly disables IRQs and power for the PCS. Its
> pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
>
> We already declare the interface to be dead on pcs_post_config()
> failure, but we don't do that for pcs_enable() failure.
>
> Maybe I need to explicitly state that pcs_disable() does not directly
> balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
> and pcs_post_config(). However, that itself will add to the problems.
> What if pcs_pre_config() and pcs_post_config() succeed but not
> pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
> require pcs_disable() to be balanced with a successful call to
> pcs_enable(), that messes up that driver, and pretty much makes it
> impossible to work around the errata.
What if we reordered phylink_major_config() such that phylink_pcs_enable()
comes first, followed by phylink_pcs_pre_config() -> phylink_mac_config() ->
phylink_pcs_post_config()? Superficially looking at pcs-639x, I don't
think it would break.
If we did that, we'd effectively have to also call pcs_disable() when
pcs_post_config() fails, and that is semantically compatible with saying
that pcs_disable() is balanced with pcs_enable(). It also gives the
ability for drivers such as pcs-639x to unwind in pcs_disable() any
actions done in pcs_enable(), pcs_pre_config() or pcs_post_config().
Plus, it's more natural/useful from an API perspective to say
"the PCS has to be enabled in order for anything to be done with it",
rather than the current "first mac_config cycle runs with the PCS not
enabled; subsequent mac_config cycles run with the PCS enabled".
> If you feel strongly about this, then the only thing I can think of
> doing is to move this SerDes support out of stmmac and into phylink
> (which is a point I already raised in the cover message) so that
> its failure can be dealt with at the higher level, where we can
> ensure that phy_power_off() is balaced with phy_power_on(). However,
> that means pushing even more of the stmmac specific "we need the
> clocks running to access registers XYZ or reset" weirdness into
> phylink.
I think core phylink support for generic PHYs eventually makes sense,
but at this stage it's perhaps too early, there's too much we don't yet
know. I would wait at least until it's clear, with an upstream example,
that multiple generic PHYs per phylink instance are needed: 1 SerDes PHY
per lane (for 40GBase-R etc), plus 1 retimer PHY per lane direction.
Also how do those retimers differ from SerDes PHYs. At the very least,
the phy_validate() of SerDes PHYs should be additive w.r.t.
supported_interfaces, whereas the phy_validate() of retimers should be
subtractive.
Also, moving SerDes PHY into phylink only avoids the problem, but if the
PCS driver needs to allocate memory, it will return. I have downstream
patches for a software backplane AN/LT state machine in phylink_pcs,
which is allocated in pcs_enable() and freed in pcs_disable().
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 4/4] riscv: dts: canaan: Add syscon and USB nodes for K230
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
Add top syscon and USB PHY subdevice nodes, USB0/USB1 dwc2 controller
to K230 DTSI, and enable UART0 and USB0/USB1 in DshanPI DT.
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
.../boot/dts/canaan/k230-canmv-dshanpi.dts | 17 +++++++++
arch/riscv/boot/dts/canaan/k230.dtsi | 35 +++++++++++++++++++
2 files changed, 52 insertions(+)
diff --git a/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts b/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts
index 4f95b534ee87..55197cfc25b4 100644
--- a/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts
+++ b/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts
@@ -80,3 +80,20 @@ &uart0 {
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
+
+&usb0 {
+ vusb_d-supply = <&vdd_3v3>;
+ vusb_a-supply = <&vdd_1v8>;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ vusb_d-supply = <&vdd_3v3>;
+ vusb_a-supply = <&vdd_1v8>;
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
index 8ca5c7dee427..b369b7d8dc83 100644
--- a/arch/riscv/boot/dts/canaan/k230.dtsi
+++ b/arch/riscv/boot/dts/canaan/k230.dtsi
@@ -148,5 +148,40 @@ uart4: serial@91404000 {
reg-shift = <2>;
status = "disabled";
};
+
+ usb0: usb@91500000 {
+ compatible = "canaan,k230-usb", "snps,dwc2";
+ reg = <0x0 0x91500000 0x0 0x40000>;
+ interrupts = <173 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysclk K230_HS_USB0_AHB_GATE>;
+ clock-names = "otg";
+ g-rx-fifo-size = <512>;
+ g-np-tx-fifo-size = <64>;
+ g-tx-fifo-size = <512 1024 64 64 64 64>;
+ phys = <&usbphy 0>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usb1: usb@91540000 {
+ compatible = "canaan,k230-usb", "snps,dwc2";
+ reg = <0x0 0x91540000 0x0 0x40000>;
+ interrupts = <174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysclk K230_HS_USB1_AHB_GATE>;
+ clock-names = "otg";
+ g-rx-fifo-size = <512>;
+ g-np-tx-fifo-size = <64>;
+ g-tx-fifo-size = <512 1024 64 64 64 64>;
+ phys = <&usbphy 1>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usbphy: usb-phy@91585000 {
+ compatible = "canaan,k230-usb-phy";
+ reg = <0x0 0x91585000 0x0 0x400>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
};
};
--
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 v5 2/4] dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
Add 'canaan,k230-usb' compatible string with 'snps,dwc2' as fallback
for the DWC2 IP which is used by Canaan K230.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
Documentation/devicetree/bindings/usb/dwc2.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index 6c3a10991b8b..352487c6392a 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
oneOf:
- const: brcm,bcm2835-usb
+ - items:
+ - const: canaan,k230-usb
+ - const: snps,dwc2
- const: hisilicon,hi6220-usb
- const: ingenic,jz4775-otg
- const: ingenic,jz4780-otg
--
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 v5 3/4] phy: usb: Add driver for Canaan K230 USB 2.0 PHY
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
Add driver for the USB 2.0 PHY in Canaan K230 SoC, which supports PHY
initialization and power management.
Add Kconfig/Makefile under drivers/phy/canaan/.
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/canaan/Kconfig | 14 ++
drivers/phy/canaan/Makefile | 2 +
drivers/phy/canaan/phy-k230-usb.c | 284 ++++++++++++++++++++++++++++++
5 files changed, 302 insertions(+)
create mode 100644 drivers/phy/canaan/Kconfig
create mode 100644 drivers/phy/canaan/Makefile
create mode 100644 drivers/phy/canaan/phy-k230-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 142e7b0ef2ef..e37bcceef65a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -150,6 +150,7 @@ source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
+source "drivers/phy/canaan/Kconfig"
source "drivers/phy/freescale/Kconfig"
source "drivers/phy/hisilicon/Kconfig"
source "drivers/phy/ingenic/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index dcbb060c8207..8cef0a447986 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -22,6 +22,7 @@ obj-y += allwinner/ \
apple/ \
broadcom/ \
cadence/ \
+ canaan/ \
freescale/ \
hisilicon/ \
ingenic/ \
diff --git a/drivers/phy/canaan/Kconfig b/drivers/phy/canaan/Kconfig
new file mode 100644
index 000000000000..1ff8831846d5
--- /dev/null
+++ b/drivers/phy/canaan/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Phy drivers for Canaan platforms
+#
+config PHY_CANAAN_USB
+ tristate "Canaan USB2 PHY Driver"
+ depends on (ARCH_CANAAN || COMPILE_TEST) && OF
+ select GENERIC_PHY
+ help
+ Enable this driver to support the USB 2.0 PHY controller
+ on Canaan K230 RISC-V SoCs. This PHY controller
+ provides physical layer functionality for USB 2.0 devices.
+ If you have a Canaan K230 board and need USB 2.0 support,
+ say Y or M here.
diff --git a/drivers/phy/canaan/Makefile b/drivers/phy/canaan/Makefile
new file mode 100644
index 000000000000..d73857ba284e
--- /dev/null
+++ b/drivers/phy/canaan/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_CANAAN_USB) += phy-k230-usb.o
diff --git a/drivers/phy/canaan/phy-k230-usb.c b/drivers/phy/canaan/phy-k230-usb.c
new file mode 100644
index 000000000000..52dad35fc6cf
--- /dev/null
+++ b/drivers/phy/canaan/phy-k230-usb.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Canaan usb PHY driver
+ *
+ * Copyright (C) 2026 Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+#define MAX_PHYS 2
+
+/* Register offsets within the HiSysConfig system controller */
+#define K230_USB0_TEST_REG_BASE 0x70
+#define K230_USB0_CTL_REG_BASE 0xb0
+#define K230_USB1_TEST_REG_BASE 0x90
+#define K230_USB1_CTL_REG_BASE 0xb8
+
+/* Relative offsets within each PHY's control/test block */
+#define CTL0_OFFSET 0x00
+#define CTL1_OFFSET 0x04
+#define TEST_CTL3_OFFSET 0x0c
+
+/* Bit definitions for TEST_CTL3 */
+#define USB_IDPULLUP0 BIT(4)
+#define USB_DMPULLDOWN0 BIT(8)
+#define USB_DPPULLDOWN0 BIT(9)
+
+/* USB control register 0 in HiSysConfig system controller */
+/* PLL Integral Path Tune */
+#define USB_CTL0_PLLITUNE_MASK GENMASK(23, 22)
+
+/* PLL Proportional Path Tune */
+#define USB_CTL0_PLLPTUNE_MASK GENMASK(21, 18)
+
+/* PLL Bandwidth Adjustment */
+#define USB_CTL0_PLLBTUNE_MASK GENMASK(17, 17)
+
+/* VReg18 Bypass Control */
+#define USB_CTL0_VREGBYPASS_MASK GENMASK(16, 16)
+
+/* Retention Mode Enable */
+#define USB_CTL0_RETENABLEN_MASK GENMASK(15, 15)
+
+/* Reserved Request Input */
+#define USB_CTL0_RESREQIN_MASK GENMASK(14, 14)
+
+/* External VBUS Valid Select */
+#define USB_CTL0_VBUSVLDEXTSEL0_MASK GENMASK(13, 13)
+
+/* OTG Block Disable Control */
+#define USB_CTL0_OTGDISABLE0_MASK GENMASK(12, 12)
+
+/* Drive VBUS Enable */
+#define USB_CTL0_DRVVBUS0_MASK GENMASK(11, 11)
+
+/* Autoresume Mode Enable */
+#define USB_CTL0_AUTORSMENB0_MASK GENMASK(10, 10)
+
+/* HS Transceiver Asynchronous Control */
+#define USB_CTL0_HSXCVREXTCTL0_MASK GENMASK(9, 9)
+
+/* USB 1.1 Transmit Data */
+#define USB_CTL0_FSDATAEXT0_MASK GENMASK(8, 8)
+
+/* USB 1.1 SE0 Generation */
+#define USB_CTL0_FSSE0EXT0_MASK GENMASK(7, 7)
+
+/* USB 1.1 Data Enable */
+#define USB_CTL0_TXENABLEN0_MASK GENMASK(6, 6)
+
+/* Disconnect Threshold */
+#define USB_CTL0_COMPDISTUNE0_MASK GENMASK(5, 3)
+
+/* Squelch Threshold */
+#define USB_CTL0_SQRXTUNE0_MASK GENMASK(2, 0)
+
+/* USB control register 1 in HiSysConfig system controller */
+/* Data Detect Voltage */
+#define USB_CTL1_VDATREFTUNE0_MASK GENMASK(23, 22)
+
+/* VBUS Valid Threshold */
+#define USB_CTL1_OTGTUNE0_MASK GENMASK(21, 19)
+
+/* Transmitter High-Speed Crossover */
+#define USB_CTL1_TXHSXVTUNE0_MASK GENMASK(18, 17)
+
+/* FS/LS Source Impedance */
+#define USB_CTL1_TXFSLSTUNE0_MASK GENMASK(16, 13)
+
+/* HS DC Voltage Level */
+#define USB_CTL1_TXVREFTUNE0_MASK GENMASK(12, 9)
+
+/* HS Transmitter Rise/Fall Time */
+#define USB_CTL1_TXRISETUNE0_MASK GENMASK(8, 7)
+
+/* USB Source Impedance */
+#define USB_CTL1_TXRESTUNE0_MASK GENMASK(6, 5)
+
+/* HS Transmitter Pre-Emphasis Current Control */
+#define USB_CTL1_TXPREEMPAMPTUNE0_MASK GENMASK(4, 3)
+
+/* HS Transmitter Pre-Emphasis Duration Control */
+#define USB_CTL1_TXPREEMPPULSETUNE0_MASK GENMASK(2, 2)
+
+/* charging detection */
+#define USB_CTL1_CHRGSRCPUENB0_MASK GENMASK(1, 0)
+
+#define K230_PHY_CTL0_VAL \
+( \
+ FIELD_PREP(USB_CTL0_PLLITUNE_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_PLLPTUNE_MASK, 0xc) | \
+ FIELD_PREP(USB_CTL0_PLLBTUNE_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_VREGBYPASS_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_RETENABLEN_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_RESREQIN_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_VBUSVLDEXTSEL0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_OTGDISABLE0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_DRVVBUS0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_AUTORSMENB0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_HSXCVREXTCTL0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_FSDATAEXT0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_FSSE0EXT0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_TXENABLEN0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_COMPDISTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL0_SQRXTUNE0_MASK, 0x3) \
+)
+
+#define K230_PHY_CTL1_VAL \
+( \
+ FIELD_PREP(USB_CTL1_VDATREFTUNE0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL1_OTGTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXHSXVTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXFSLSTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXVREFTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXRISETUNE0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL1_TXRESTUNE0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL1_TXPREEMPAMPTUNE0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL1_TXPREEMPPULSETUNE0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL1_CHRGSRCPUENB0_MASK, 0x0) \
+)
+
+struct k230_usb_phy_instance {
+ struct k230_usb_phy_global *global;
+ struct phy *phy;
+ u32 test_offset;
+ u32 ctl_offset;
+ int index;
+};
+
+struct k230_usb_phy_global {
+ struct k230_usb_phy_instance phys[MAX_PHYS];
+ void __iomem *base;
+};
+
+static int k230_usb_phy_power_on(struct phy *phy)
+{
+ struct k230_usb_phy_instance *inst = phy_get_drvdata(phy);
+ struct k230_usb_phy_global *global = inst->global;
+ void __iomem *base = global->base;
+ u32 val;
+
+ /* Apply recommended settings */
+ writel(K230_PHY_CTL0_VAL, base + inst->ctl_offset + CTL0_OFFSET);
+ writel(K230_PHY_CTL1_VAL, base + inst->ctl_offset + CTL1_OFFSET);
+
+ /* Configure test register (pull-ups/pull-downs) */
+ val = readl(base + inst->test_offset + TEST_CTL3_OFFSET);
+ val |= USB_IDPULLUP0;
+
+ if (inst->index == 1)
+ val |= (USB_DMPULLDOWN0 | USB_DPPULLDOWN0);
+ else
+ val &= ~(USB_DMPULLDOWN0 | USB_DPPULLDOWN0);
+
+ writel(val, base + inst->test_offset + TEST_CTL3_OFFSET);
+
+ return 0;
+}
+
+static int k230_usb_phy_power_off(struct phy *phy)
+{
+ struct k230_usb_phy_instance *inst = phy_get_drvdata(phy);
+ struct k230_usb_phy_global *global = inst->global;
+ void __iomem *base = global->base;
+ u32 val;
+
+ val = readl(base + inst->test_offset + TEST_CTL3_OFFSET);
+ val &= ~(USB_DMPULLDOWN0 | USB_DPPULLDOWN0);
+ writel(val, base + inst->test_offset + TEST_CTL3_OFFSET);
+
+ return 0;
+}
+
+static const struct phy_ops k230_usb_phy_ops = {
+ .power_on = k230_usb_phy_power_on,
+ .power_off = k230_usb_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static struct phy *k230_usb_phy_xlate(struct device *dev,
+ const struct of_phandle_args *args)
+{
+ struct k230_usb_phy_global *global = dev_get_drvdata(dev);
+ unsigned int idx = args->args[0];
+
+ if (idx >= MAX_PHYS)
+ return ERR_PTR(-EINVAL);
+
+ return global->phys[idx].phy;
+}
+
+static int k230_usb_phy_probe(struct platform_device *pdev)
+{
+ struct k230_usb_phy_global *global;
+ struct device *dev = &pdev->dev;
+ struct phy_provider *provider;
+ int i;
+
+ global = devm_kzalloc(dev, sizeof(*global), GFP_KERNEL);
+ if (!global)
+ return -ENOMEM;
+ dev_set_drvdata(dev, global);
+
+ global->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(global->base))
+ return dev_err_probe(dev, PTR_ERR(global->base),
+ "failed to map registers\n");
+
+ static const struct {
+ u32 test_offset;
+ u32 ctl_offset;
+ } phy_reg_info[MAX_PHYS] = {
+ [0] = { K230_USB0_TEST_REG_BASE, K230_USB0_CTL_REG_BASE },
+ [1] = { K230_USB1_TEST_REG_BASE, K230_USB1_CTL_REG_BASE },
+ };
+
+ for (i = 0; i < MAX_PHYS; i++) {
+ struct k230_usb_phy_instance *inst = &global->phys[i];
+ struct phy *phy;
+
+ inst->global = global;
+ inst->index = i;
+ inst->test_offset = phy_reg_info[i].test_offset;
+ inst->ctl_offset = phy_reg_info[i].ctl_offset;
+
+ phy = devm_phy_create(dev, NULL, &k230_usb_phy_ops);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create phy%d\n", i);
+ return PTR_ERR(phy);
+ }
+
+ phy_set_drvdata(phy, inst);
+ inst->phy = phy;
+ }
+
+ provider = devm_of_phy_provider_register(dev, k230_usb_phy_xlate);
+ if (IS_ERR(provider))
+ return PTR_ERR(provider);
+
+ return 0;
+}
+
+static const struct of_device_id k230_usb_phy_of_match[] = {
+ { .compatible = "canaan,k230-usb-phy" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, k230_usb_phy_of_match);
+
+static struct platform_driver k230_usb_phy_driver = {
+ .probe = k230_usb_phy_probe,
+ .driver = {
+ .name = "k230-usb-phy",
+ .of_match_table = k230_usb_phy_of_match,
+ },
+};
+module_platform_driver(k230_usb_phy_driver);
+
+MODULE_DESCRIPTION("Canaan Kendryte K230 USB 2.0 PHY driver");
+MODULE_AUTHOR("Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>");
+MODULE_LICENSE("GPL");
--
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 v5 1/4] dt-bindings: phy: Add Canaan K230 USB PHY
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
K230 SoC USB PHY requires configuring registers for control and
configuration. Add USB phy bindings for K230 SoC.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
.../bindings/phy/canaan,k230-usb-phy.yaml | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml b/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
new file mode 100644
index 000000000000..b959b381c44c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/canaan,k230-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan K230 USB2.0 PHY
+
+maintainers:
+ - Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
+
+properties:
+ compatible:
+ const: canaan,k230-usb-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ usbphy: usb-phy@91585000 {
+ compatible = "canaan,k230-usb-phy";
+ reg = <0x91585000 0x400>;
+ #phy-cells = <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 v5 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
Add support for the USB PHY and DWC2 IP which is used by Canaan K230,
and made relevant changes to the DTS.
This series is based on the initial 100ask K230 DshanPi series [1] which
is based on the clock and pinctrl series. Check the details in the link.
Link: https://lore.kernel.org/all/20260115060801.16819-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
Changes in v5:
- Changed the year of Copyright to 2026.
- Add blank line after the declaration of variables
- Fix wrong alignment.
- Link to v4: https://lore.kernel.org/all/20260120143243.71937-1-jiayu.riscv@isrc.iscas.ac.cn/
Changes in v4:
- Shrink reg length to match the address/size-cells in k230-usb-phy yaml.
- Move all PHY instance creation and initialization from xlate to probe.
- Modify xlate function to only perform index lookup for PHY instances.
- Define all register base offsets macros at the top of file instead of
hard-coding magic numbers directly in probe.
- Link to v2: https://lore.kernel.org/all/20260115064223.21926-1-jiayu.riscv@isrc.iscas.ac.cn/
Changes in v3:
- Please ignore v3.
Changes in v2:
- Fold the child into the parent in dtsi.
- Define one usbphy with phy-cells=1.
- Delete the clock of the usbphy as it is not needed.
- Link to v1: https://lore.kernel.org/all/20251230023725.15966-1-jiayu.riscv@isrc.iscas.ac.cn/
Jiayu Du (4):
dt-bindings: phy: Add Canaan K230 USB PHY
dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
phy: usb: Add driver for Canaan K230 USB 2.0 PHY
riscv: dts: canaan: Add syscon and USB nodes for K230
.../bindings/phy/canaan,k230-usb-phy.yaml | 35 +++
.../devicetree/bindings/usb/dwc2.yaml | 3 +
.../boot/dts/canaan/k230-canmv-dshanpi.dts | 17 ++
arch/riscv/boot/dts/canaan/k230.dtsi | 35 +++
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/canaan/Kconfig | 14 +
drivers/phy/canaan/Makefile | 2 +
drivers/phy/canaan/phy-k230-usb.c | 284 ++++++++++++++++++
9 files changed, 392 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
create mode 100644 drivers/phy/canaan/Kconfig
create mode 100644 drivers/phy/canaan/Makefile
create mode 100644 drivers/phy/canaan/phy-k230-usb.c
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
From: kernel test robot @ 2026-01-21 14:49 UTC (permalink / raw)
To: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Peter Rosin, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: oe-kbuild-all, Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
linux-mmc, devicetree
In-Reply-To: <20260121-rz-sdio-mux-v6-2-38aa39527928@solid-run.com>
Hi Josua,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 8f0b4cce4481fb22653697cced8d0d04027cb1e8]
url: https://github.com/intel-lab-lkp/linux/commits/Josua-Mayer/phy-can-transceiver-rename-temporary-helper-function-to-avoid-conflict/20260121-173607
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20260121-rz-sdio-mux-v6-2-38aa39527928%40solid-run.com
patch subject: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
config: i386-randconfig-001-20260121 (https://download.01.org/0day-ci/archive/20260121/202601212215.qNGA0wVh-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260121/202601212215.qNGA0wVh-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/202601212215.qNGA0wVh-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/mux/core.c:56 struct member 'mstate' not described in 'devm_mux_state_state'
>> Warning: drivers/mux/core.c:56 struct member 'mstate' not described in 'devm_mux_state_state'
--
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: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-21 14:46 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <20260120121114.2aedgu42i2wax3yp@skbuf>
On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > First, I'll say I'm on a very short fuse today; no dinner last night,
> > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > bell at 10am this morning. Just fucking our luck.
>
> Sorry to hear that.
>
> > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > after calling pcs_disable(), though?
> >
> > No. We've already called mac_prepare(), pcs_pre_config(),
> > pcs_post_config() by this time, we're past the point of being able to
> > unwind.
>
> I'm set out to resolve a much smaller problem.
>
> Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> and pcs_post_config() don't have unwinding equivalents, unlike how
> pcs_enable() has pcs_disable(). I don't see what API convention would be
> violated if phylink decided to drop a PCS whose enable() returned an error.
While pcs_pre_config() and pcs_post_config() do not have unwinding
equivalents (what would they be?) the issue here is that these could
have changed any state that isn't simply undone by calling
pcs_disable().
For example, pcs_pre_config() could have reprogrammed signal routing,
clocking, or power supplies to blocks.
This already applies to Marvell DSA pcs-639x.c, where the pre/post
config hooks change the power state of the PCS block (for errata
handling), and the only way that gets undone is via a call to
pcs_disable() which explicitly disables IRQs and power for the PCS. Its
pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
We already declare the interface to be dead on pcs_post_config()
failure, but we don't do that for pcs_enable() failure.
Maybe I need to explicitly state that pcs_disable() does not directly
balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
and pcs_post_config(). However, that itself will add to the problems.
What if pcs_pre_config() and pcs_post_config() succeed but not
pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
require pcs_disable() to be balanced with a successful call to
pcs_enable(), that messes up that driver, and pretty much makes it
impossible to work around the errata.
If you feel strongly about this, then the only thing I can think of
doing is to move this SerDes support out of stmmac and into phylink
(which is a point I already raised in the cover message) so that
its failure can be dealt with at the higher level, where we can
ensure that phy_power_off() is balaced with phy_power_on(). However,
that means pushing even more of the stmmac specific "we need the
clocks running to access registers XYZ or reset" weirdness into
phylink.
--
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
* [PATCH v2 6/6] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
Enabling runtime PM before attaching the hsphy instance as driver data
can lead to a NULL pointer dereference in runtime PM callbacks that
expect valid driver data. There is a small window where the suspend
callback may run after PM runtime enabling and before runtime forbid.
Attach the hsphy instance as driver data before enabling runtime PM to
prevent NULL pointer dereference in runtime PM callbacks.
Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a
short window where an unnecessary runtime suspend can occur.
Use the devres-managed version to ensure PM runtime is symmetrically
disabled during driver removal for proper cleanup.
Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index eb0b0f61d98e..d1288a6c202e 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -599,13 +599,17 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
return dev_err_probe(dev, ret,
"failed to get regulator supplies\n");
- pm_runtime_set_active(dev);
- pm_runtime_enable(dev);
+ dev_set_drvdata(dev, hsphy);
+
/*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
*/
+ pm_runtime_set_active(dev);
pm_runtime_forbid(dev);
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
generic_phy = devm_phy_create(dev, NULL, &qcom_snps_hsphy_gen_ops);
if (IS_ERR(generic_phy)) {
@@ -615,15 +619,12 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
}
hsphy->phy = generic_phy;
- dev_set_drvdata(dev, hsphy);
phy_set_drvdata(generic_phy, hsphy);
qcom_snps_hsphy_read_override_param_seq(dev);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (!IS_ERR(phy_provider))
dev_dbg(dev, "Registered Qcom-SNPS HS phy\n");
- else
- pm_runtime_disable(dev);
return PTR_ERR_OR_ZERO(phy_provider);
}
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 5/6] phy: qcom: qmp-usb-legacy: Prevent unnecessary PM runtime suspend at boot
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
There is a small window where the device can suspend after
pm_runtime_enable() and before pm_runtime_forbid(), causing an
unnecessary suspend/resume cycle while the PHY is not yet registered.
Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
this race.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
index 258e0e966a02..73439d223f1d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
@@ -1284,15 +1284,15 @@ static int qmp_usb_legacy_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = phy_pipe_clk_register(qmp, np);
if (ret)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/6] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
`if (!qmp->phy->init_count) {`
This can also happen if user re-enables runtime-pm via the sysfs
attribute before qmp phy is initialized.
Similarly to other qcom phy drivers, introduce a qmp->phy_initialized
variable that can be used to avoid relying on the possibly uninitialized
phy pointer.
Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
index 8bf951b0490c..258e0e966a02 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
@@ -541,6 +541,7 @@ struct qmp_usb {
struct regulator_bulk_data *vregs;
enum phy_mode mode;
+ bool phy_initialized;
struct phy *phy;
@@ -895,6 +896,7 @@ static int qmp_usb_legacy_power_off(struct phy *phy)
static int qmp_usb_legacy_enable(struct phy *phy)
{
+ struct qmp_usb *qmp = phy_get_drvdata(phy);
int ret;
ret = qmp_usb_legacy_init(phy);
@@ -904,14 +906,19 @@ static int qmp_usb_legacy_enable(struct phy *phy)
ret = qmp_usb_legacy_power_on(phy);
if (ret)
qmp_usb_legacy_exit(phy);
+ else
+ qmp->phy_initialized = true;
return ret;
}
static int qmp_usb_legacy_disable(struct phy *phy)
{
+ struct qmp_usb *qmp = phy_get_drvdata(phy);
int ret;
+ qmp->phy_initialized = false;
+
ret = qmp_usb_legacy_power_off(phy);
if (ret)
return ret;
@@ -988,7 +995,7 @@ static int __maybe_unused qmp_usb_legacy_runtime_suspend(struct device *dev)
dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->phy_initialized) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -1009,7 +1016,7 @@ static int __maybe_unused qmp_usb_legacy_runtime_resume(struct device *dev)
dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->phy_initialized) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/6] phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
`if (!qmp->phy->init_count) {`
This can also occur if user re-enables runtime-pm via the sysfs
attribute before qmp phy is initialized.
Use qmp->usb_init_count instead of qmp->phy->init_count to avoid
depending on the possibly uninitialized phy pointer.
Fixes: 19281571a4d5 ("phy: qcom: qmp-usb: split USB-C PHY driver")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index 5e7fcb26744a..edfaa14db967 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -690,7 +690,7 @@ static int __maybe_unused qmp_usbc_runtime_suspend(struct device *dev)
dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->usb_init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -710,7 +710,7 @@ static int __maybe_unused qmp_usbc_runtime_resume(struct device *dev)
dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->usb_init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/6] phy: qcom: qmp-usbc: Prevent unnecessary PM runtime suspend at boot
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
There is a small window where the device can suspend after
pm_runtime_enable() and before pm_runtime_forbid(), causing an
unnecessary suspend/resume cycle while the PHY is not yet registered.
Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
this race.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index edfaa14db967..05717ca85c5b 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -1083,15 +1083,15 @@ static int qmp_usbc_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = phy_pipe_clk_register(qmp, np);
if (ret)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/6] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
There is a small window where the device can suspend after
pm_runtime_enable() and before pm_runtime_forbid(), causing an
unnecessary suspend/resume cycle while the PHY is not yet registered.
Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
this race.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 7b5af30f1d02..cea0e9f7413d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -4175,15 +4175,15 @@ static int qmp_combo_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = qmp_combo_register_clocks(qmp, usb_np, dp_np);
if (ret)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/6] Fix possible NULL-deref and runtime PM race conditions
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1551 bytes --]
Address potential NULL pointer dereferences and race conditions related
to runtime PM in several Qualcomm PHY drivers. In all cases, enabling
runtime PM before the PHY instance is fully initialized can lead to
crashes during early runtime suspend callbacks.
- Attach driver data before enabling runtime PM.
- Introduce initialization flags where needed to avoid dereferencing
uninitialized pointers.
- Reorder pm_runtime_enable() and pm_runtime_forbid() calls to prevent
unnecessary suspend/resume cycles during driver probe.
- Use devres-managed PM runtime helpers for proper cleanup.
Changes in V2:
Split patches 2/4 and 3/4 so that the null‑pointer dereference fix and
the runtime‑PM enable/forbid reordering are logically separated.
Loic Poulain (6):
phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
phy: qcom: qmp-usbc: Prevent unnecessary PM runtime suspend at boot
phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime
suspend
phy: qcom: qmp-usb-legacy: Prevent unnecessary PM runtime suspend at
boot
phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime
suspend
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 10 ++++-----
.../phy/qualcomm/phy-qcom-qmp-usb-legacy.c | 21 ++++++++++++-------
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 14 ++++++-------
drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 15 ++++++-------
4 files changed, 34 insertions(+), 26 deletions(-)
--
2.34.1
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 0/3] Add PCIe3 and PCIe5 support for HAMOA-IOT-EVK board
From: Manivannan Sadhasivam @ 2026-01-21 14:24 UTC (permalink / raw)
To: Ziyue Zhang
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, jingoohan1,
lpieralisi, kwilczynski, bhelgaas, johan+linaro, vkoul, kishon,
neil.armstrong, abel.vesa, kw, linux-arm-msm, devicetree,
linux-kernel, linux-pci, linux-phy, qiang.yu, quic_krichai,
quic_vbadigan, Ziyue Zhang
In-Reply-To: <20260109104504.3147745-1-ziyue.zhang@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 06:45:01PM +0800, Ziyue Zhang wrote:
> From: Ziyue Zhang <quic_ziyuzhan@quicinc.com>
>
> This patch series adds support for PCIe3 and PCIe5 on the HAMOA-IOT-EVK
> board.
>
> PCIe3 is a Gen4 x8 slot intended for sata controller.
> PCIe5 is a Gen3 x2 slot designed for external modem connectivity.
>
> To enable these interfaces, the series introduces the necessary device
> tree nodes and associated regulator definitions to ensure proper power
> sequencing and functionality.
>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> Changes in v4:
> - Move PCIe reset/wake GPIOs to pcie_port node (Mani)
> - Move PCIe phy to pcie_port node for all Hamoa platform (Mani)
> - Remove output-high property (Konrad)
> - Modified the DT and patch format, and adjusted the commit message (Konrad)
> - Link to v3: https://lore.kernel.org/all/20251112090316.936187-1-ziyue.zhang@oss.qualcomm.com/
>
> Changes in v3:
> - Update commit message and DT format (Bjron)
> - Merge PCIe3 and PCIe5 changes into one patch
> - Link to v2: https://lore.kernel.org/all/20251030084804.1682744-1-ziyue.zhang@oss.qualcomm.com/
>
> Changes in v2:
> - Move PMIC gpio pins to patch set 4 (Krishna)
> - Link to v1: https://lore.kernel.org/all/20250922075509.3288419-1-ziyue.zhang@oss.qualcomm.com/
>
> Ziyue Zhang (3):
> arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port
> nodes and add port Nodes for all PCIe ports
> arm64: dts: qcom: Add PCIe3 and PCIe5 support for HAMOA-IOT-SOM
> platform
> arm64: dts: qcom: Add PCIe3 and PCIe5 regulators for HAMAO-IOT-EVK
> board
>
> arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 97 +++++++++++++++++++
> arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 80 +++++++++++++--
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 42 +++++---
> arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 24 +++--
> .../qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 24 +++--
> .../dts/qcom/x1e80100-asus-vivobook-s15.dts | 14 +--
> .../dts/qcom/x1e80100-asus-zenbook-a14.dts | 3 +
> .../dts/qcom/x1e80100-dell-xps13-9345.dts | 14 +--
> .../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 8 +-
> .../dts/qcom/x1e80100-microsoft-romulus.dtsi | 19 ++--
> arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 21 ++--
> 11 files changed, 279 insertions(+), 67 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 v4 3/4] phy: usb: Add driver for Canaan K230 USB 2.0 PHY
From: Jiayu Du @ 2026-01-21 13:55 UTC (permalink / raw)
To: Vinod Koul
Cc: gregkh, conor, neil.armstrong, robh, krzk+dt, pjw, palmer, aou,
alex, linux-phy, linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <aXB7GqQaxtgKReVa@vaman>
On Wed, Jan 21, 2026 at 12:37:06PM +0530, Vinod Koul wrote:
> On 20-01-26, 22:32, Jiayu Du wrote:
> > + * Copyright (C) 2025 Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
>
> 2026 now!
>
...
> > + void __iomem *base = global->base;
> > + u32 val;
>
> blank line here please
>
...
> > + /* Configure test register (pull-ups/pull-downs) */
>
> wrong alignment above, pls fix it
Thanks for pointing out these issues. I will fix them in v5.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-21 13:48 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Neil Armstrong, Rob Herring,
Vinod Koul, Yoshihiro Shimoda, devicetree, linux-phy,
linux-renesas-soc
In-Reply-To: <20260118135038.8033-10-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on Ebisu
> board. The clock generator supplies 100 MHz differential clock for both
> PCIe slot and BT/WLAN expansion port, as well as for the USB 3.0 PHY.
>
> This configuration is valid for SW49 in OFF position, which means the
> PCIe signals are routed to the PCIe slot and U11 9FGV0841 PCIe clock
> generator output 3 supplies clock to the PCIe slot.
>
> In case the SW49 is set to ON position, which means the PCIe signals
> are routed to the EX BT/WLAN expansion port, and U11 9FGV0841 PCIe
> clock generator output 4 supplies clock to the port and &pciec0_rp
> clocks should be changed to "clocks = <&pcie_usb_clk 4>;". Once the
> BT/WLAN port is tested, this can be implemented using a DTO. Until
> then, assume SW49 is set to OFF position.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/ebisu.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ebisu.dtsi
> @@ -53,6 +53,12 @@ backlight: backlight {
> power-supply = <®_12p0v>;
> };
>
> + pcie_usb_refclk: clk-x7 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> + };
> +
> cvbs-in {
> compatible = "composite-video-connector";
> label = "CVBS IN";
> @@ -439,6 +445,13 @@ adv7511_out: endpoint {
> };
> };
>
> + pcie_usb_clk: clk@68 {
> + compatible = "renesas,9fgv0841";
> + reg = <0x68>;
> + clocks = <&pcie_usb_refclk>;
> + #clock-cells = <1>;
> + };
During boot, the rs9 prints a warning:
clk-renesas-pcie-9series 0-0068: No cache defaults, reading back from HW
which probably shouldn't be printed at the warning level?
> +
> video-receiver@70 {
> compatible = "adi,adv7482";
> reg = <0x70>;
> @@ -871,7 +902,19 @@ &usb2_phy0 {
> status = "okay";
> };
>
> +&usb3_phy0 {
> + clocks = <&pcie_usb_clk 6>;
> + status = "okay";
> +};
This does not work, probing fails with:
usb_phy_generic usb-phy: dummy supplies not allowed for exclusive
requests (id=vbus)
Adding a fixed regulator that serves as vbus-supply like in commit
fec2d8fcdedaeeb0 ("arm64: dts: freescale: imx93-phyboard-nash: Add USB
vbus regulators") fixes that issue (and my USB3.0 FLASH driver is
detected, yeah!), but a more accurate description would be better.
> +
> +&usb3s0_clk {
> + clock-frequency = <100000000>;
> + status = "disabled";
> +};
> +
> &usb3_peri0 {
> + phys = <&usb3_phy0>;
> + phy-names = "usb";
> companion = <&xhci0>;
> status = "okay";
> };
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 25/27] phy: ti: phy-j721e-wiz: convert from divider_round_rate() to divider_determine_rate()
From: Brian Masney @ 2026-01-21 12:13 UTC (permalink / raw)
To: Vinod Koul
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
Neil Armstrong, linux-phy
In-Reply-To: <aXCGlW4lgIImN8Eb@vaman>
On Wed, Jan 21, 2026 at 01:26:05PM +0530, Vinod Koul wrote:
> On 15-01-26, 09:18, Brian Masney wrote:
> > Hi Vinod,
> >
> > On Wed, Jan 14, 2026 at 07:47:18PM +0530, Vinod Koul wrote:
> > > On 08-01-26, 16:16, Brian Masney wrote:
> > > > The divider_round_rate() function is now deprecated, so let's migrate
> > > > to divider_determine_rate() instead so that this deprecated API can be
> > > > removed.
> > > >
> > > > Note that when the main function itself was migrated to use
> > > > determine_rate, this was mistakenly converted to:
> > > >
> > > > req->rate = divider_round_rate(...)
> > > >
> > > > This is invalid in the case when an error occurs since it can set the
> > > > rate to a negative value.
> > >
> > > Acked-by: Vinod Koul <vkoul@kernel.org>
> >
> > Thanks for the Acked-by.
> >
> > However, this patch depends on this other series of mine that's merged
> > into your phy tree:
>
> Should I pick this one then..? If there are no other dependencies...
Yes, this patch stands on it's own, and it would be great if you could
pick up this patch in your tree this dev cycle.
Thanks,
Brian
> > https://lore.kernel.org/linux-clk/176661322399.4169.14248756511703978007@lazor/
> >
> > Stephen asked for an Acked-by for that series or an immutable branch.
> >
> > This will allow us to remove round_rate from the clk core.
> >
> > I also have a small series to post that's dependent on all of this that
> > lets us get rid of the noop determine_rate implementations that only
> > 'return 0'. I haven't posted that because of the dependencies.
> >
> > Brian
>
> --
> ~Vinod
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 00/10] SPMI: Implement sub-devices and migrate drivers
From: AngeloGioacchino Del Regno @ 2026-01-21 11:00 UTC (permalink / raw)
To: jic23, sboyd
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel
In-Reply-To: <20260114092742.13231-1-angelogioacchino.delregno@collabora.com>
Il 14/01/26 10:27, AngeloGioacchino Del Regno ha scritto:
> Changes in v8:
With this series being finally fully reviewed and having lots of acks, and
since I think that the main part of this is in SPMI subsystem rather than
others....
....Stephen or Jonathan, can you please pick at least the SPMI code so that
it goes in for this merge window and doesn't get forgotten again?
That also makes it easier for the other maintainers who didn't give an ack (and
that don't want their subsystem patches to go through SPMI) to apply the patches
in the next merge window, IMO.
Thanks,
Angelo
> - Renamed *res to *sub_sdev in devm_spmi_subdevice_remove() (Andy)
> - Changed kerneldoc wording to "error pointer" for function
> spmi_subdevice_alloc_and_add() (Andy)
> - Shuffled around some assignments in spmi_subdevice_alloc_and_add() (Andy)
> - Used device_property_read_u32() instead of of_property_read_u32()
> in all of the migrated drivers (Andy)
> - Changed .max_register field in all of the migrated drivers from
> 0x100 to 0xff (Andy)
> - Kept `sta1` declaration in reversed xmas tree order in function
> iadc_poll_wait_eoc() of qcom-spmi-iadc.c (Andy)
>
> Changes in v7:
> - Added commit to cleanup redundant dev_name() in the pre-existing
> spmi_device_add() function
> - Added commit removing unneeded goto and improving spmi_device_add()
> readability by returning error in error path, and explicitly zero
> for success at the end.
>
> Changes in v6:
> - Added commit to convert spmi.c to %pe error format and used
> %pe error format in spmi_subdevice code as wanted by Uwe Kleine-Konig
>
> Changes in v5:
> - Changed dev_err to dev_err_probe in qcom-spmi-sdam (and done
> that even though I disagree - because I wanted this series to
> *exclusively* introduce the minimum required changes to
> migrate to the new API, but okay, whatever....!);
> - Added missing REGMAP dependency in Kconfig for qcom-spmi-sdam,
> phy-qcom-eusb2-repeater and qcom-coincell to resolve build
> issues when the already allowed COMPILE_TEST is enabled
> as pointed out by the test robot's randconfig builds.
>
> Changes in v4:
> - Added selection of REGMAP_SPMI in Kconfig for qcom-coincell and
> for phy-qcom-eusb2-repeater to resolve undefined references when
> compiled with some randconfig
>
> Changes in v3:
> - Fixed importing "SPMI" namespace in spmi-devres.c
> - Removed all instances of defensive programming, as pointed out by
> jic23 and Sebastian
> - Removed explicit casting as pointed out by jic23
> - Moved ida_free call to spmi_subdev_release() and simplified error
> handling in spmi_subdevice_alloc_and_add() as pointed out by jic23
>
> Changes in v2:
> - Fixed missing `sparent` initialization in phy-qcom-eusb2-repeater
> - Changed val_bits to 8 in all Qualcomm drivers to ensure
> compatibility as suggested by Casey
> - Added struct device pointer in all conversion commits as suggested
> by Andy
> - Exported newly introduced functions with a new "SPMI" namespace
> and imported the same in all converted drivers as suggested by Andy
> - Added missing error checking for dev_set_name() call in spmi.c
> as suggested by Andy
> - Added comma to last entry of regmap_config as suggested by Andy
>
> While adding support for newer MediaTek platforms, featuring complex
> SPMI PMICs, I've seen that those SPMI-connected chips are internally
> divided in various IP blocks, reachable in specific contiguous address
> ranges... more or less like a MMIO, but over a slow SPMI bus instead.
>
> I recalled that Qualcomm had something similar... and upon checking a
> couple of devicetrees, yeah - indeed it's the same over there.
>
> What I've seen then is a common pattern of reading the "reg" property
> from devicetree in a struct member and then either
> A. Wrapping regmap_{read/write/etc}() calls in a function that adds
> the register base with "base + ..register", like it's done with
> writel()/readl() calls; or
> B. Doing the same as A. but without wrapper functions.
>
> Even though that works just fine, in my opinion it's wrong.
>
> The regmap API is way more complex than MMIO-only readl()/writel()
> functions for multiple reasons (including supporting multiple busses
> like SPMI, of course) - but everyone seemed to forget that regmap
> can manage register base offsets transparently and automatically in
> its API functions by simply adding a `reg_base` to the regmap_config
> structure, which is used for initializing a `struct regmap`.
>
> So, here we go: this series implements the software concept of an SPMI
> Sub-Device (which, well, also reflects how Qualcomm and MediaTek's
> actual hardware is laid out anyway).
>
> SPMI Controller
> | ______
> | / Sub-Device 1
> V /
> SPMI Device (PMIC) ----------- Sub-Device 2
> \
> \______ Sub-Device 3
>
> As per this implementation, an SPMI Sub-Device can be allocated/created
> and added in any driver that implements a... well.. subdevice (!) with
> an SPMI "main" device as its parent: this allows to create and finally
> to correctly configure a regmap that is specific to the sub-device,
> operating on its specific address range and reading, and writing, to
> its registers with the regmap API taking care of adding the base address
> of a sub-device's registers as per regmap API design.
>
> All of the SPMI Sub-Devices are therefore added as children of the SPMI
> Device (usually a PMIC), as communication depends on the PMIC's SPMI bus
> to be available (and the PMIC to be up and running, of course).
>
> Summarizing the dependency chain (which is obvious to whoever knows what
> is going on with Qualcomm and/or MediaTek SPMI PMICs):
> "SPMI Sub-Device x...N" are children "SPMI Device"
> "SPMI Device" is a child of "SPMI Controller"
>
> (that was just another way to say the same thing as the graph above anyway).
>
> Along with the new SPMI Sub-Device registration functions, I have also
> performed a conversion of some Qualcomm SPMI drivers and only where the
> actual conversion was trivial.
>
> I haven't included any conversion of more complex Qualcomm SPMI drivers
> because I don't have the required bandwidth to do so (and besides, I think,
> but haven't exactly verified, that some of those require SoCs that I don't
> have for testing anyway).
>
> AngeloGioacchino Del Regno (10):
> spmi: Remove redundant dev_name() print in spmi_device_add()
> spmi: Print error status with %pe format
> spmi: Remove unneeded goto in spmi_device_add() error path
> spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
> nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
> power: reset: qcom-pon: Migrate to devm_spmi_subdevice_alloc_and_add()
> phy: qualcomm: eusb2-repeater: Migrate to
> devm_spmi_subdevice_alloc_and_add()
> misc: qcom-coincell: Migrate to devm_spmi_subdevice_alloc_and_add()
> iio: adc: qcom-spmi-iadc: Migrate to
> devm_spmi_subdevice_alloc_and_add()
> iio: adc: qcom-spmi-iadc: Remove regmap R/W wrapper functions
>
> drivers/iio/adc/qcom-spmi-iadc.c | 109 ++++++++----------
> drivers/misc/Kconfig | 2 +
> drivers/misc/qcom-coincell.c | 38 ++++--
> drivers/nvmem/Kconfig | 1 +
> drivers/nvmem/qcom-spmi-sdam.c | 38 ++++--
> drivers/phy/qualcomm/Kconfig | 2 +
> .../phy/qualcomm/phy-qcom-eusb2-repeater.c | 55 +++++----
> drivers/power/reset/qcom-pon.c | 33 ++++--
> drivers/spmi/spmi-devres.c | 24 ++++
> drivers/spmi/spmi.c | 95 +++++++++++++--
> include/linux/spmi.h | 16 +++
> 11 files changed, 290 insertions(+), 123 deletions(-)
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox