* Re: [PATCH 1/3] dt-bindings: phy: spacemit: k3: add USB2 PHY support
From: Krzysztof Kozlowski @ 2026-02-12 12:03 UTC (permalink / raw)
To: Yixun Lan
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang, Junzhong Pan, linux-phy, devicetree,
linux-riscv, spacemit, linux-kernel
In-Reply-To: <20260212-11-k3-usb2-phy-v1-1-43578592405d@kernel.org>
On Thu, Feb 12, 2026 at 09:38:54AM +0800, Yixun Lan wrote:
> 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(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Russell King (Oracle) @ 2026-02-12 11:55 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260212103803.xut4sjbypgb26mo4@skbuf>
On Thu, Feb 12, 2026 at 12:38:03PM +0200, Vladimir Oltean wrote:
> On Thu, Feb 12, 2026 at 10:01:57AM +0000, Russell King (Oracle) wrote:
> > I'm also going to point out that phy-core allows ->set_mode() to be
> > unimplemented, yet the phy_mode is stored. It looks to me like this is
> > intentional part of the API, which means that phy_set_mode*() is not
> > expected to always result in the hardware being programmed. That
> > brings up the obvious question: if phy_set_mode() is not expected to
> > always reprogram the hardware, then what phy API call should follow
> > this to ensure the hardware is reprogrammed.
> >
> > On the other hand, if the API intention was that ->set_mode() must be
> > implemented if phy_set_mode*() is to be accepted, then surely
> > phy_set_mode_ext() should be checking that phy->ops->set_mode exists,
> > and returning -EOPNOTSUPP if it doesn't.
>
> This is a relatively new development.
>
> commit d58c04e305afbaa9dda7969151f06c4efe2c98b0
> Author: Dmitry Baryshkov <lumag@kernel.org>
> Date: Sun Feb 9 14:31:45 2025 +0200
>
> phy: core: don't require set_mode() callback for phy_get_mode() to work
>
> As reported by Damon Ding, the phy_get_mode() call doesn't work as
> expected unless the PHY driver has a .set_mode() call. This prompts PHY
> drivers to have empty stubs for .set_mode() for the sake of being able
> to get the mode.
>
> Make .set_mode() callback truly optional and update PHY's mode even if
> it there is none.
>
> Cc: Damon Ding <damon.ding@rock-chips.com>
> Link: https://lore.kernel.org/r/96f8310f-93f1-4bcb-8637-137e1159ff83@rock-chips.com
> Tested-by: Damon Ding <damon.ding@rock-chips.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Link: https://lore.kernel.org/r/20250209-phy-fix-set-moe-v2-1-76e248503856@linaro.org
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
>
> If only lore.kernel.org wasn't down, so I could see the back story in
> the link...
Looking at the first link:
> On 2024/12/30 20:45, Dmitry Baryshkov wrote:
> > On Thu, Dec 26, 2024 at 02:33:03PM +0800, Damon Ding wrote:
> > No need for the stub, please drop it. The host controller driver can
> > still call phy_set_mode() / _ext(), the call will return 0.
>
> Without the &phy_ops.set_mode(), the phy driver can not get phy_mode to
> distinguish between HDMI and DP mode via the phy_get_mode(), even if the
> host driver calls phy_set_mode() / _ext(). Additionally, the previous
> discussion [0] also mentioned future considerations for dynamic
> switching. Indeed, I should add a related comment before the 'return 0;'
> to enhance understandability.
The first sentence makes me question the reasoning here - why would
a phy _driver_ call phy _consumer_ functions such as phy_get_mode().
We have drivers that directly access phy->attrs.mode.
It also adds to the question about the intended correct ordering of
PHY consumer calls, because it seems that the intention behind this
is to _not_ implement the ->set_mode() method, but to reconfigure the
PHY in some other generic PHY API call.
By "fixing" phy_set_mode*() in the above commit to allow this, that
action goes against the idea that generic PHY API calls can be made in
any order.
So my conclusion is that there is disagreement between generic PHY
reviewers about how the generic PHY API should be used and implemented,
leading to the mess I've highlighted where consumers need to know the
implementation details of the generic PHY driver to make the calls in
the correct order for that specific driver.
--
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 3/3] phy: k1-usb: k3: add USB2 PHY support
From: Yao Zi @ 2026-02-12 11:30 UTC (permalink / raw)
To: Yixun Lan, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel
In-Reply-To: <20260212-11-k3-usb2-phy-v1-3-43578592405d@kernel.org>
On Thu, Feb 12, 2026 at 09:38:56AM +0800, Yixun Lan wrote:
> Add USB2 PHY support for SpacemiT K3 SoC.
>
> Register layout of handling USB disconnect operation has been changed,
> So introducing a platform data to distinguish the different SoCs.
Would it be clearer and simpler if you define separate phy_ops for
k1 and k3, and point of_device_id.data directly to the corresponding
phy_ops? Then there's no need to introduce either spacemit_usb2phy_data
structure, or spacemit_usb2phy_disconnect wrapper.
Best regards,
Yao Zi
> Signed-off-by: Yixun Lan <dlan@kernel.org>
> ---
> drivers/phy/spacemit/phy-k1-usb2.c | 40 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
> index 959bf79c7a72..b0ce0a92861e 100644
> --- a/drivers/phy/spacemit/phy-k1-usb2.c
> +++ b/drivers/phy/spacemit/phy-k1-usb2.c
> @@ -51,6 +51,9 @@
> #define PHY_K1_HS_HOST_DISC 0x40
> #define PHY_K1_HS_HOST_DISC_CLR BIT(0)
>
> +#define PHY_K3_HS_HOST_DISC 0x20
> +#define PHY_K3_HS_HOST_DISC_CLR BIT(8)
> +
> #define PHY_PLL_DIV_CFG 0x98
> #define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
> #define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
> @@ -74,10 +77,15 @@
>
> #define K1_USB2PHY_RESET_TIME_MS 50
>
> +struct spacemit_usb2phy_data {
> + int (*disconnect)(struct phy *phy, int port);
> +};
> +
> struct spacemit_usb2phy {
> struct phy *phy;
> struct clk *clk;
> struct regmap *regmap_base;
> + const struct spacemit_usb2phy_data *data;
> };
>
> static const struct regmap_config phy_regmap_config = {
> @@ -145,7 +153,7 @@ static int spacemit_usb2phy_exit(struct phy *phy)
> return 0;
> }
>
> -static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
> +static int spacemit_k1_usb2phy_disconnect(struct phy *phy, int port)
> {
> struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
>
> @@ -155,6 +163,23 @@ static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
> return 0;
> }
>
> +static int spacemit_k3_usb2phy_disconnect(struct phy *phy, int port)
> +{
> + struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
> +
> + regmap_update_bits(sphy->regmap_base, PHY_K3_HS_HOST_DISC,
> + PHY_K3_HS_HOST_DISC_CLR, PHY_K3_HS_HOST_DISC_CLR);
> +
> + return 0;
> +}
> +
> +static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
> +{
> + struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
> +
> + return sphy->data->disconnect(phy, port);
> +}
> +
> static const struct phy_ops spacemit_usb2phy_ops = {
> .init = spacemit_usb2phy_init,
> .exit = spacemit_usb2phy_exit,
> @@ -173,6 +198,8 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
> if (!sphy)
> return -ENOMEM;
>
> + sphy->data = device_get_match_data(dev);
> +
> sphy->clk = devm_clk_get_prepared(&pdev->dev, NULL);
> if (IS_ERR(sphy->clk))
> return dev_err_probe(dev, PTR_ERR(sphy->clk), "Failed to get clock\n");
> @@ -195,8 +222,17 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(phy_provider);
> }
>
> +static const struct spacemit_usb2phy_data k1_usb2phy_data = {
> + .disconnect = spacemit_k1_usb2phy_disconnect,
> +};
> +
> +static const struct spacemit_usb2phy_data k3_usb2phy_data = {
> + .disconnect = spacemit_k3_usb2phy_disconnect,
> +};
> +
> static const struct of_device_id spacemit_usb2phy_dt_match[] = {
> - { .compatible = "spacemit,k1-usb2-phy", },
> + { .compatible = "spacemit,k1-usb2-phy", .data = &k1_usb2phy_data },
> + { .compatible = "spacemit,k3-usb2-phy", .data = &k3_usb2phy_data },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, spacemit_usb2phy_dt_match);
>
> --
> 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 2/3] phy: k1-usb: add disconnect function support
From: Yao Zi @ 2026-02-12 11:24 UTC (permalink / raw)
To: Yixun Lan, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel
In-Reply-To: <20260212-11-k3-usb2-phy-v1-2-43578592405d@kernel.org>
On Thu, Feb 12, 2026 at 09:38:55AM +0800, Yixun Lan wrote:
> 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.
This sounds like a bug. Does it affect K1 SoC as well? If so, I think
it deserves a Fixes tag and backporting.
> Signed-off-by: Yixun Lan <dlan@kernel.org>
Best regards,
Yao Zi
--
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-12 11: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: <CAPDyKFo92pOimvtGdN4yvFtFkc3vB+ex2OH10WmoKXcVSS+iAA@mail.gmail.com>
On 12-02-26, 11:39, Ulf Hansson wrote:
> On Wed, 11 Feb 2026 at 17:17, Vinod Koul <vkoul@kernel.org> wrote:
> > Should I drop the 8bb92fd7a0407792 and it makes things easier for
> > everyone and then we can pick fixed commit for 7.1 cycle..
>
> Well, my pull request for MMC was broken (the mux patches didn't get
> properly tested in linux-next, until it was too late), so Linus will
> not take it.
Yeah I saw that one, sorry for that
> At this point I would say that 8bb92fd7a0407792 is still a bit
> problematic as it uses the same name of the helper that the mux core
> intends to use. It would be better with a phy specific name for it, so
> it becomes easier to convert to the common mux helper, later on.
> Although, at this point it's still okay as is, as we will need to
> defer the mux core changes to v7.1 anyway.
>
> So up to you!
In that case, I can keep as is for now. We can rename the api as a fix
and proper changes can go in for 7.1
--
~Vinod
--
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: Vladimir Oltean @ 2026-02-12 9:31 UTC (permalink / raw)
To: Vinod Koul, Geert Uytterhoeven
Cc: Ulf Hansson, Yoshihiro Shimoda, Neil Armstrong, Josua Mayer,
Wolfram Sang, Tommaso Merciai, linux-phy, linux-mmc,
linux-renesas-soc, linux-next, linux-kernel
In-Reply-To: <aY1eIG_U_GBOFQGt@vaman>
On Thu, Feb 12, 2026 at 10:29:12AM +0530, Vinod Koul wrote:
> Hi Geert,
>
> On 11-02-26, 17:30, Geert Uytterhoeven wrote:
> > 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.
>
> Hmmm, that is also a good option but might leave Linus a bit grumpy so
> bit reluctant. Dropping and getting right implementation would be
> better. I think it was a mistake to pick or this all could have gone
> thru mux tree.
>
> Thanks
> --
> ~Vinod
I think with Linus' refusal of the mmc/next PR, there is no longer any
need either for this patch or for the revert of 8bb92fd7a040 ("phy:
renesas: rcar-gen3-usb2: Use mux-state for phyrst management").
http://lore.kernel.org/lkml/CAHk-=wgnRQiKqWVrO_uF1btYM2K8r8xL95RGdKU3QLe8B58nrw@mail.gmail.com
--
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: Ulf Hansson @ 2026-02-12 10:39 UTC (permalink / raw)
To: Vinod Koul
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: <aYyrsPTH1923jV7y@vaman>
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..
Well, my pull request for MMC was broken (the mux patches didn't get
properly tested in linux-next, until it was too late), so Linus will
not take it.
At this point I would say that 8bb92fd7a0407792 is still a bit
problematic as it uses the same name of the helper that the mux core
intends to use. It would be better with a phy specific name for it, so
it becomes easier to convert to the common mux helper, later on.
Although, at this point it's still okay as is, as we will need to
defer the mux core changes to v7.1 anyway.
So up to you!
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types()
From: Felix Gu @ 2026-02-12 10:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
Vladimir Oltean
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 reference leak.
Add the missing of_node_put() calls to ensure the reference count is
properly balanced.
Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
Suggested-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Changes in v2:
- Use of_node_put() suggested by Vladimir Oltean.
- Link to v1: https://lore.kernel.org/r/20260211-wiz-v1-1-fdd018d02f33@gmail.com
---
drivers/phy/ti/phy-j721e-wiz.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 12a19bf2875c..10110cc2115b 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -1428,6 +1428,7 @@ static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
dev_err(dev,
"%s: Reading \"reg\" from \"%s\" failed: %d\n",
__func__, subnode->name, ret);
+ of_node_put(serdes);
return ret;
}
of_property_read_u32(subnode, "cdns,num-lanes", &num_lanes);
@@ -1442,6 +1443,7 @@ static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
}
}
+ of_node_put(serdes);
return 0;
}
---
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
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-12 10:38 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <aY2lFTIALH7qEJmM@shell.armlinux.org.uk>
On Thu, Feb 12, 2026 at 10:01:57AM +0000, Russell King (Oracle) wrote:
> I'm also going to point out that phy-core allows ->set_mode() to be
> unimplemented, yet the phy_mode is stored. It looks to me like this is
> intentional part of the API, which means that phy_set_mode*() is not
> expected to always result in the hardware being programmed. That
> brings up the obvious question: if phy_set_mode() is not expected to
> always reprogram the hardware, then what phy API call should follow
> this to ensure the hardware is reprogrammed.
>
> On the other hand, if the API intention was that ->set_mode() must be
> implemented if phy_set_mode*() is to be accepted, then surely
> phy_set_mode_ext() should be checking that phy->ops->set_mode exists,
> and returning -EOPNOTSUPP if it doesn't.
This is a relatively new development.
commit d58c04e305afbaa9dda7969151f06c4efe2c98b0
Author: Dmitry Baryshkov <lumag@kernel.org>
Date: Sun Feb 9 14:31:45 2025 +0200
phy: core: don't require set_mode() callback for phy_get_mode() to work
As reported by Damon Ding, the phy_get_mode() call doesn't work as
expected unless the PHY driver has a .set_mode() call. This prompts PHY
drivers to have empty stubs for .set_mode() for the sake of being able
to get the mode.
Make .set_mode() callback truly optional and update PHY's mode even if
it there is none.
Cc: Damon Ding <damon.ding@rock-chips.com>
Link: https://lore.kernel.org/r/96f8310f-93f1-4bcb-8637-137e1159ff83@rock-chips.com
Tested-by: Damon Ding <damon.ding@rock-chips.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250209-phy-fix-set-moe-v2-1-76e248503856@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
If only lore.kernel.org wasn't down, so I could see the back story in
the link...
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4 v2] dt-bindings: serdes: s32g: Add NXP serdes subsystem
From: Russell King (Oracle) @ 2026-02-12 10:28 UTC (permalink / raw)
To: Vincent Guittot, Rob Herring
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, ghennadi.procopciuc, Ionut.Vicovan, linux-phy,
devicetree, linux-kernel, linux-arm-kernel, netdev, horms,
Frank.li
In-Reply-To: <20260210004011.GA2188625-robh@kernel.org>
On Mon, Feb 09, 2026 at 06:40:11PM -0600, Rob Herring wrote:
> On Tue, Feb 03, 2026 at 05:19:14PM +0100, Vincent Guittot wrote:
> > +description: |
> > + The SerDes subsystem on S32G SoC Family includes two types of PHYs:
> > + - One PCIe PHY: Supports various PCIe operation modes
> > + - Two Ethernet Physical Coding Sublayer (XPCS) controllers
> > +
> > + SerDes operation mode selects the enabled PHYs and speeds. Clock frequency
> > + must be adapted accordingly. Below table describes all possible operation
> > + modes.
> > +
> > + Mode PCIe XPCS0 XPCS1 PHY clock Description
> > + SGMII SGMII (MHz)
> > + -------------------------------------------------------------------------
> > + 0 Gen3 N/A N/A 100 Single PCIe
> > + 1 Gen2 1.25Gbps N/A 100 PCIe/SGMII
> > + 2 Gen2 N/A 1.25Gbps 100 PCIe/SGMII
> > + 3 N/A 1.25Gbps 1.25Gbps 100,125 SGMII
> > + 4 N/A 3.125/1.25Gbps 3.125/1.25Gbps 125 SGMII
> > + 5 Gen2 N/A 3.125Gbps 100 PCIe/SGMII
>
> Mixed tabs and spaces. Drop the tabs.
>
> What's not clear to me is do you have 2 or 4 lanes?
>
...
> > + nxp,sys-mode:
> > + $ref: /schemas/types.yaml#/definitions/uint32
>
> maximum: 5
>
> Though isn't this redundant with the child nodes? You could use the
> standard 'phy-mode' property in each child.
phy-mode is ethernet, but the above is more than just ethernet.
I've been wondering why a generic PHY driver needs to know this via DT
when the generic PHY API has:
phy_set_mode() / phy_set_mode_ext()
- sets the type of the PHY and its submode (e.g. ethernet interface
mode)
phy_set_speed()
phy_set_bus_width()
Surely these are sufficient to describe what mode is required from the
generic PHY, and the generic PHY driver can figure out whether the
mode is permitted from the above table, programming the PHY as
desired.
For Ethernet, we don't call the 3.125Gbps "SGMII" using that term. We
use SGMII strictly for Cisco SGMII, which runs at 1.25Gbps. 3.125Gbps
single-lane serdes ethernet is not able to use Cisco SGMII inband
signalling because running the underlying data rate with 10 or 100
symbol replications makes no sense. So we have decided to all this
2500BASE-X. If such a SerDes is connected to a SFP cage, then we
support switching between 1.25Gbps and 3.125Gbps mode depending on
the module inserted, which requires dynamic reconfiguration of the
SerDes.
What I'm saying is that describing a single mode covering several ports
could make things difficult in the future, so make sure you think
carefully.
--
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: Russell King (Oracle) @ 2026-02-12 10:05 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <aY2lFTIALH7qEJmM@shell.armlinux.org.uk>
On Thu, Feb 12, 2026 at 10:01:57AM +0000, Russell King (Oracle) wrote:
> On Thu, Feb 12, 2026 at 11:13:32AM +0200, Vladimir Oltean wrote:
> > Also thinking out loud, we could do something else - introduce something
> > similar in spirit to CONFIG_DEBUG_TEST_DRIVER_REMOVE, which would be a
> > debug option that sees what power state the PHY is in during the
> > phy_set_mode_ext() call, flips it before calling ->set_mode() (calling
> > either ->power_on() or ->power_off()), and restores it after the call.
> >
> > Having this option should also give PHY provider developers a quick way
> > of testing both calling orders without modifying the consumers.
>
> I don't think anyone would enable that option, beause clearly what
> happens is they develop their generic PHY driver, and also develop
> the consumer of that generic PHY driver. Once it works, they say
> "job done" and submit it.
>
> I was thinking that maybe some automated testing is needed, but
> that runs into other problems:
>
> 1. any test code doesn't have any way to determine what a PHY
> driver supports, because phy_validate() is optional. So it has
> no way to know whether e.g. PHY_MODE_ETHERNET is supported or
> not. Calling phy_set_mode() isn't sufficient, if ->set_mode()
> isn't implemented, this is effectively a no-op.
>
> 2. drivers that just return success for ->set_mode() irrespective
> of the PHY power state but don't program the hardware would be
> undetectable.
>
> I'm also going to point out that phy-core allows ->set_mode() to be
> unimplemented, yet the phy_mode is stored. It looks to me like this is
> intentional part of the API, which means that phy_set_mode*() is not
> expected to always result in the hardware being programmed. That
> brings up the obvious question: if phy_set_mode() is not expected to
> always reprogram the hardware, then what phy API call should follow
> this to ensure the hardware is reprogrammed.
>
> On the other hand, if the API intention was that ->set_mode() must be
> implemented if phy_set_mode*() is to be accepted, then surely
> phy_set_mode_ext() should be checking that phy->ops->set_mode exists,
> and returning -EOPNOTSUPP if it doesn't.
I'll also point out that other parts of the API don't even give the
driver the opportunity to program hardware. E.g.:
static inline void phy_set_bus_width(struct phy *phy, int bus_width)
{
phy->attrs.bus_width = bus_width;
}
So, in order for this hardware configuration to take effect, some other
PHY API call is necessary after calling this function.
(While not relevant for ethernet, I think this needs to be considered
in this discussion, since it's all related to how the generic PHY API
should be used.)
--
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: Russell King (Oracle) @ 2026-02-12 10:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260212091332.qcpi3qyynmdp4acv@skbuf>
On Thu, Feb 12, 2026 at 11:13:32AM +0200, Vladimir Oltean wrote:
> Also thinking out loud, we could do something else - introduce something
> similar in spirit to CONFIG_DEBUG_TEST_DRIVER_REMOVE, which would be a
> debug option that sees what power state the PHY is in during the
> phy_set_mode_ext() call, flips it before calling ->set_mode() (calling
> either ->power_on() or ->power_off()), and restores it after the call.
>
> Having this option should also give PHY provider developers a quick way
> of testing both calling orders without modifying the consumers.
I don't think anyone would enable that option, beause clearly what
happens is they develop their generic PHY driver, and also develop
the consumer of that generic PHY driver. Once it works, they say
"job done" and submit it.
I was thinking that maybe some automated testing is needed, but
that runs into other problems:
1. any test code doesn't have any way to determine what a PHY
driver supports, because phy_validate() is optional. So it has
no way to know whether e.g. PHY_MODE_ETHERNET is supported or
not. Calling phy_set_mode() isn't sufficient, if ->set_mode()
isn't implemented, this is effectively a no-op.
2. drivers that just return success for ->set_mode() irrespective
of the PHY power state but don't program the hardware would be
undetectable.
I'm also going to point out that phy-core allows ->set_mode() to be
unimplemented, yet the phy_mode is stored. It looks to me like this is
intentional part of the API, which means that phy_set_mode*() is not
expected to always result in the hardware being programmed. That
brings up the obvious question: if phy_set_mode() is not expected to
always reprogram the hardware, then what phy API call should follow
this to ensure the hardware is reprogrammed.
On the other hand, if the API intention was that ->set_mode() must be
implemented if phy_set_mode*() is to be accepted, then surely
phy_set_mode_ext() should be checking that phy->ops->set_mode exists,
and returning -EOPNOTSUPP if it doesn't.
--
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 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Konrad Dybcio @ 2026-02-12 9:23 UTC (permalink / raw)
To: Qiang Yu, Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aY1Jx5J8x/OALk5M@hu-qianyu-lv.qualcomm.com>
On 2/12/26 4:32 AM, Qiang Yu wrote:
> On Mon, Feb 09, 2026 at 09:06:23AM +0100, Krzysztof Kozlowski wrote:
>> On Sun, Feb 08, 2026 at 08:49:39PM -0800, Qiang Yu wrote:
>>> The PCIe QMP PHYs on Glymur require stable reference voltage provided by
>>> refgen. The refgen itself requires two separate power supplies:
>>> vdda-refgen0p9 and vdda-refgen1p2.
>>>
>>> Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
>>
>> How does the driver matter for the bindings? If I add dedicated driver
>> for refgen, then I change the bindings?
>
> Yeah, I know that dt-bindings should describe hardware, not software. But
> what I meant to say is that the refgen is different from qref which is
> controlled via TCSR registers and its LDOs are requested to vote in
> tcsrcc driver. The refgen doesn't required register setting and it doesn't
> have dedicated driver, so we vote its LDOs in phy driver. I will avoid
> this statement in next version.
>
>>
>> There is qcom,sc8280xp-refgen-regulator so why there cannot be
>> qcom,x1e-refgen-regulator?
>
> I think we can and it seems better because the refgen for pcie phy also
> supplies reference voltage to other modules like usb. But I checked the
> qcom-refgen-regulator.c, it contains some register settings and there is
> no LDOs voting. I'm not sure what does those register do, maybe Konrad
> can provide some backgroud. But on Glymur, we only need to vote LDOs. So
> what if we use a fixed regulator in the device tree to represent refgen?
> We could set refgen0p9 and refgen1p2 as its input supplies, then the PCIe
> PHY would just need one refgen supply reference.
That refgen on e.g. 8280 supplies display and camera PHYs. The latter have
some sideband interface to request a vote directly (on all but some single
old SoCs, IIUC), while the display ones need a manual vote.
It would stand to reason that perhaps this MMIO-controlled regulator would
have some sort of a voltage input.. so maybe that's the missing part in the
story? I'm trying to find some answers but it's not easy..
Konrad
--
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-12 9:13 UTC (permalink / raw)
To: Vinod Koul
Cc: Russell King (Oracle), Neil Armstrong, Jonathan Corbet, linux-doc,
linux-phy
In-Reply-To: <aY1hs4XKZSpvKd3B@vaman>
On Thu, Feb 12, 2026 at 10:44:27AM +0530, Vinod Koul wrote:
> Lets document that call order is immaterial and driver is expected to
> work both ways? As I said earlier logically people would set things up
> and power up, and on the fly mode changes can be handled internally in
> the driver by doing off-set-on dance.
FWIW, I already started telling people during review to not rely on call
order:
https://lore.kernel.org/linux-phy/20260210193516.temrg46yozxma7xb@skbuf
I don't mind continuing to scan for this in new submissions. Then, only
the topic of existing drivers remains to be resolved.
> Thinking out loud, we can also move this into framework and ensure when
> modes are set, we do off-set-on dance so that onus on providers is
> removed. Moving into fwk might expose some bugs in drivers though...
>
> One thing I agree is that we should have consistency. How we drive that
> can be agreed upon.
>
> Thanks
> --
> ~Vinod
I kind of like the fact that the framework doesn't have power vs mode
assumptions built in.
Also thinking out loud, we could do something else - introduce something
similar in spirit to CONFIG_DEBUG_TEST_DRIVER_REMOVE, which would be a
debug option that sees what power state the PHY is in during the
phy_set_mode_ext() call, flips it before calling ->set_mode() (calling
either ->power_on() or ->power_off()), and restores it after the call.
Having this option should also give PHY provider developers a quick way
of testing both calling orders without modifying the consumers.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: qcom: edp: Add per-version LDO configuration callback
From: Yongxing Mou @ 2026-02-12 9:04 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <200b055b-7221-45b5-aea1-2462e07a3c1c@oss.qualcomm.com>
On 2/6/2026 6:52 PM, Konrad Dybcio wrote:
> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>> Introduce the com_ldo_config callback to support per‑PHY LDO
>> configuration.
>>
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>
> [...]
>
>> +static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
>> +{
>> + const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
>> + u32 ldo_config;
>> +
>> + if (!edp->is_edp)
>> + ldo_config = 0x0;
>> + else if (dp_opts->link_rate <= 2700)
>> + ldo_config = 0xC1;
>
> lowercase hex, please
>
>> + else
>> + ldo_config = 0x81;
>> +
>> + writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
>> + writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
>
> tx1 should be dp_ops->lanes ? 2 : ldo_config : 0x00, in all cases,
> I believe
>
> Konrad
Hi, here i want to confirm again.. In the HPG main link brinup sequence,
it not say write TX0/TX1 ldo_config based on the lane count. Only when
we switch the lane mode, the LDO config will be updated according to
the lane count. so here do we really need this condition?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: Lynx 10G SerDes Driver on my kernel
From: Tanjeff Moos @ 2026-02-12 8:30 UTC (permalink / raw)
To: Vladimir Oltean; +Cc: Sean Anderson, linux-phy@lists.infradead.org
In-Reply-To: <20260208134211.3vsgebmvh7yhee5c@skbuf>
Am 08.02.26 um 14:42 schrieb Vladimir Oltean:
> In LF I've moved the phy_init()
> https://github.com/nxp-qoriq/linux/blob/lf-6.12.y/drivers/net/pcs/pcs-lynx.c#L563
> and phy_power_on()
> https://github.com/nxp-qoriq/linux/blob/lf-6.12.y/drivers/net/pcs/pcs-lynx.c#L435
> to the Lynx PCS driver to simplify MAC drivers a little bit, since they
> all have to go through the same steps (the Lynx PCS is present in dpaa1,
> dpaa2, enetc, felix switch).
Found it, thanks. I missed this code while porting.
Meanwhile I can confirm that all speeds work now, from 100M to 10G. The
lynx-10g driver switches between sgmii and 10-BaseR on my "fast"
devices. On my "slow" devices it properly switches between sgmii and
2500-BaseX. All works well, thank you for your extensive support on that!
Kind regards, Tanjeff
--
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: Horatiu Vultur @ 2026-02-12 8:02 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vladimir Oltean, vkoul, kishon, robh, krzk+dt, conor+dt,
linux-phy, devicetree, linux-kernel, Daniel Golle
In-Reply-To: <20260211122254.4mwzmi5auxddsm5k@skbuf>
The 02/11/2026 14:22, Vladimir Oltean wrote:
>
> Hi Horatiu,
Hi Vladimir,
>
> 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.
Thanks for doing this worked. Unfortunately I am currently stuck on some
other issue, when I get out of that I will try to update this patches.
--
/Horatiu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4 v2] dt-bindings: serdes: s32g: Add NXP serdes subsystem
From: Vincent Guittot @ 2026-02-12 7:17 UTC (permalink / raw)
To: Rob Herring
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, linux, ghennadi.procopciuc, Ionut.Vicovan,
linux-phy, devicetree, linux-kernel, linux-arm-kernel, netdev,
horms, Frank.li
In-Reply-To: <20260210004011.GA2188625-robh@kernel.org>
On Tue, 10 Feb 2026 at 01:40, Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Feb 03, 2026 at 05:19:14PM +0100, Vincent Guittot wrote:
> > Describe the serdes subsystem available on the S32G platforms.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> > ---
> > .../bindings/phy/nxp,s32g-serdes.yaml | 154 ++++++++++++++++++
> > 1 file changed, 154 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> > new file mode 100644
> > index 000000000000..fad34bee2a4f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> > @@ -0,0 +1,154 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/nxp,s32g-serdes.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP S32G2xxx/S32G3xxx SerDes PHY subsystem
> > +
> > +maintainers:
> > + - Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> > +
> > +description: |
> > + The SerDes subsystem on S32G SoC Family includes two types of PHYs:
> > + - One PCIe PHY: Supports various PCIe operation modes
> > + - Two Ethernet Physical Coding Sublayer (XPCS) controllers
> > +
> > + SerDes operation mode selects the enabled PHYs and speeds. Clock frequency
> > + must be adapted accordingly. Below table describes all possible operation
> > + modes.
> > +
> > + Mode PCIe XPCS0 XPCS1 PHY clock Description
> > + SGMII SGMII (MHz)
> > + -------------------------------------------------------------------------
> > + 0 Gen3 N/A N/A 100 Single PCIe
> > + 1 Gen2 1.25Gbps N/A 100 PCIe/SGMII
> > + 2 Gen2 N/A 1.25Gbps 100 PCIe/SGMII
> > + 3 N/A 1.25Gbps 1.25Gbps 100,125 SGMII
> > + 4 N/A 3.125/1.25Gbps 3.125/1.25Gbps 125 SGMII
> > + 5 Gen2 N/A 3.125Gbps 100 PCIe/SGMII
>
> Mixed tabs and spaces. Drop the tabs.
okay
>
> What's not clear to me is do you have 2 or 4 lanes?
2 lanes per serdes
as an example mode 0 is one PCIe x2 lane
and mode 1 is one PCIe x1 and one xpcs0/SGMII on lane 1
or mode 3 is one xpcs0/SGMII on lane 0 and one xpcs1/SGMII on lane 1
>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - nxp,s32g2-serdes
> > + - items:
> > + - const: nxp,s32g3-serdes
> > + - const: nxp,s32g2-serdes
> > +
> > + reg:
> > + maxItems: 4
> > +
> > + reg-names:
> > + items:
> > + - const: ss_pcie
> > + - const: pcie_phy
> > + - const: xpcs0
> > + - const: xpcs1
> > +
> > + clocks:
> > + minItems: 4
> > + maxItems: 5
> > +
> > + clock-names:
> > + items:
> > + - const: axi
> > + - const: aux
> > + - const: apb
> > + - const: ref
> > + - const: ext
> > + minItems: 4
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: serdes
> > + - const: pcie
> > +
> > + nxp,sys-mode:
> > + $ref: /schemas/types.yaml#/definitions/uint32
>
> maximum: 5
>
> Though isn't this redundant with the child nodes? You could use the
> standard 'phy-mode' property in each child.
not really because we can have mode 1 but only a node to describe
lane0 for PCIe x1 if the lane 1 is not used
>
> > + description: |
> > + SerDes operational mode. See above table for possible values.
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > +patternProperties:
> > + '^serdes[0,1]_lane@[0,1]$':
>
> Do you need to support serdes0_lane@0 and serdes1_lane@0 (or similar
> with "@1")? That's illegal as you have 2 nodes with the same address.
okay, we can find other naming
>
> > + description:
> > + Describe a serdes lane.
> > + type: object
> > +
> > + properties:
> > + compatible:
> > + enum:
> > + - nxp,s32g2-serdes-pcie-phy
> > + - nxp,s32g2-serdes-xpcs
>
> Seems like phy-mode would be sufficient. Are these separate blocks from
> the parent?
Isn't phy-mode only for ethernet phy ?
here we have either a PCIe phy or a xpcs instance which are referenced
with phandle
>
> > +
> > + reg:
> > + maxItems: 1
>
> Just 'maximum: 1' instead.
okay
>
> > +
> > + '#phy-cells':
> > + const: 0
> > +
> > + required:
> > + - reg
> > + - compatible
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - clocks
> > + - clock-names
> > + - resets
> > + - reset-names
> > + - nxp,sys-mode
> > + - '#address-cells'
> > + - '#size-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + bus {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + serdes0: serdes@40480000 {
> > + compatible = "nxp,s32g3-serdes", "nxp,s32g2-serdes";
> > + reg = <0x0 0x40480000 0x0 0x108>,
> > + <0x0 0x40483008 0x0 0x10>,
> > + <0x0 0x40482000 0x0 0x800>,
> > + <0x0 0x40482800 0x0 0x800>;
> > + reg-names = "ss_pcie", "pcie_phy", "xpcs0", "xpcs1";
> > + clocks = <&clks 1>,
> > + <&clks 2>,
> > + <&clks 3>,
> > + <&clks 4>,
> > + <&serdes_100_ext>;
> > + clock-names = "axi", "aux", "apb", "ref", "ext";
> > + resets = <&reset 9>,
> > + <&reset 8>;
> > + reset-names = "serdes", "pcie";
> > + nxp,sys-mode = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + phy_pcie0: serdes0_lane@0 {
> > + compatible = "nxp,s32g2-serdes-pcie-phy";
> > + #phy-cells = <0>;
> > + reg = <0>;
> > + };
> > + phy_xpcs0_0: serdes0_lane@1 {
> > + compatible = "nxp,s32g2-serdes-xpcs";
> > + reg = <0>;
> > + };
> > + };
> > + };
> > --
> > 2.43.0
> >
--
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: Vinod Koul @ 2026-02-12 5:14 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vladimir Oltean, Neil Armstrong, Jonathan Corbet, linux-doc,
linux-phy
In-Reply-To: <aYznE1FIbs_0OcPR@shell.armlinux.org.uk>
On 11-02-26, 20:31, Russell King (Oracle) wrote:
> 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.
Yes. It is lazy state from provider implementation. If hardware requires
you to power down and set mode, it could have been handled internally in
the driver. I think we should fix these providers.
> 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.
Lets document that call order is immaterial and driver is expected to
work both ways? As I said earlier logically people would set things up
and power up, and on the fly mode changes can be handled internally in
the driver by doing off-set-on dance.
Thinking out loud, we can also move this into framework and ensure when
modes are set, we do off-set-on dance so that onus on providers is
removed. Moving into fwk might expose some bugs in drivers though...
One thing I agree is that we should have consistency. How we drive that
can be agreed upon.
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: Vinod Koul @ 2026-02-12 5:06 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Russell King (Oracle), Neil Armstrong, Jonathan Corbet, linux-doc,
linux-phy
In-Reply-To: <20260211154839.lbh4uovxr5b5s4nv@skbuf>
On 11-02-26, 17:48, Vladimir Oltean wrote:
> 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:
Sorry to have missed that...
> > 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 agree on that. The documentation can be update to reflect that. Common
logic would say that we should set things up before powering up, that
should be the guidance here as well.
>
> > 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.
Agree, setting mode and powering up are not coupled anywhere in the API.
framework does not care about it. There might be provider limitations
which should be handled internally.
>
> > 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.
Yes but I would say rather than order, a guidance would help users and
providers. Set things up and power up would be a good logic to follow.
If the provider supports setting/switching mode up when running, we
should not limit that. I dont see a reason for limiting that from an
framework.
--
~Vinod
--
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-12 4:59 UTC (permalink / raw)
To: Geert Uytterhoeven
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: <CAMuHMdUHNRuMmHU2ACX84nsZdXn_-fSamnF+LMFvZS3vkHnEWA@mail.gmail.com>
Hi Geert,
On 11-02-26, 17:30, Geert Uytterhoeven wrote:
> 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.
Hmmm, that is also a good option but might leave Linus a bit grumpy so
bit reluctant. Dropping and getting right implementation would be
better. I think it was a mistake to pick or this all could have gone
thru mux tree.
Thanks
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add vdda-refgen supplies for Glymur
From: Qiang Yu @ 2026-02-12 3:33 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <jvitdcolh4naqjdahaajlzdctcmp3sy5odiheeqacps6pcbg5t@zx3jliileazg>
On Mon, Feb 09, 2026 at 03:15:24PM +0200, Dmitry Baryshkov wrote:
> On Sun, Feb 08, 2026 at 08:49:40PM -0800, Qiang Yu wrote:
> > The refgen providing reference voltage for PCIe QMP PHY on Glymur requires
> > two power supplies independent from the PHY's core and qref rails. Add
> > support for vdda-refgen0p9 and vdda-refgen1p2 supplies with a dedicated
> > glymur_qmp_phy_vreg_l list.
> >
> > Update both Gen5x4 and Gen4x2 configurations to use the new supply list.
>
> I'd ask for the DTSI patch too...
>
I will post dtsi patch after we get agreement on how to descibe refgen in
dt-bindings.
- Qiang Yu
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
>
> --
> With best wishes
> Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Qiang Yu @ 2026-02-12 3:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260209-magic-conscious-seahorse-b81c8b@quoll>
On Mon, Feb 09, 2026 at 09:06:23AM +0100, Krzysztof Kozlowski wrote:
> On Sun, Feb 08, 2026 at 08:49:39PM -0800, Qiang Yu wrote:
> > The PCIe QMP PHYs on Glymur require stable reference voltage provided by
> > refgen. The refgen itself requires two separate power supplies:
> > vdda-refgen0p9 and vdda-refgen1p2.
> >
> > Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
>
> How does the driver matter for the bindings? If I add dedicated driver
> for refgen, then I change the bindings?
Yeah, I know that dt-bindings should describe hardware, not software. But
what I meant to say is that the refgen is different from qref which is
controlled via TCSR registers and its LDOs are requested to vote in
tcsrcc driver. The refgen doesn't required register setting and it doesn't
have dedicated driver, so we vote its LDOs in phy driver. I will avoid
this statement in next version.
>
> There is qcom,sc8280xp-refgen-regulator so why there cannot be
> qcom,x1e-refgen-regulator?
I think we can and it seems better because the refgen for pcie phy also
supplies reference voltage to other modules like usb. But I checked the
qcom-refgen-regulator.c, it contains some register settings and there is
no LDOs voting. I'm not sure what does those register do, maybe Konrad
can provide some backgroud. But on Glymur, we only need to vote LDOs. So
what if we use a fixed regulator in the device tree to represent refgen?
We could set refgen0p9 and refgen1p2 as its input supplies, then the PCIe
PHY would just need one refgen supply reference.
- Qiang Yu
>
>
> > and vdda-refgen1p2-supply properties to the PCIe PHY dt-bindings. Use
> > conditional schema to restrict these properties to only Glymur PCIe QMP
> > PHYs.
>
> Best regards,
> Krzysztof
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 3/3] phy: k1-usb: 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>
Add USB2 PHY support for SpacemiT K3 SoC.
Register layout of handling USB disconnect operation has been changed,
So introducing a platform data to distinguish the different SoCs.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
drivers/phy/spacemit/phy-k1-usb2.c | 40 ++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/spacemit/phy-k1-usb2.c b/drivers/phy/spacemit/phy-k1-usb2.c
index 959bf79c7a72..b0ce0a92861e 100644
--- a/drivers/phy/spacemit/phy-k1-usb2.c
+++ b/drivers/phy/spacemit/phy-k1-usb2.c
@@ -51,6 +51,9 @@
#define PHY_K1_HS_HOST_DISC 0x40
#define PHY_K1_HS_HOST_DISC_CLR BIT(0)
+#define PHY_K3_HS_HOST_DISC 0x20
+#define PHY_K3_HS_HOST_DISC_CLR BIT(8)
+
#define PHY_PLL_DIV_CFG 0x98
#define PHY_FDIV_FRACT_8_15 GENMASK(7, 0)
#define PHY_FDIV_FRACT_16_19 GENMASK(11, 8)
@@ -74,10 +77,15 @@
#define K1_USB2PHY_RESET_TIME_MS 50
+struct spacemit_usb2phy_data {
+ int (*disconnect)(struct phy *phy, int port);
+};
+
struct spacemit_usb2phy {
struct phy *phy;
struct clk *clk;
struct regmap *regmap_base;
+ const struct spacemit_usb2phy_data *data;
};
static const struct regmap_config phy_regmap_config = {
@@ -145,7 +153,7 @@ static int spacemit_usb2phy_exit(struct phy *phy)
return 0;
}
-static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+static int spacemit_k1_usb2phy_disconnect(struct phy *phy, int port)
{
struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
@@ -155,6 +163,23 @@ static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
return 0;
}
+static int spacemit_k3_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ regmap_update_bits(sphy->regmap_base, PHY_K3_HS_HOST_DISC,
+ PHY_K3_HS_HOST_DISC_CLR, PHY_K3_HS_HOST_DISC_CLR);
+
+ return 0;
+}
+
+static int spacemit_usb2phy_disconnect(struct phy *phy, int port)
+{
+ struct spacemit_usb2phy *sphy = phy_get_drvdata(phy);
+
+ return sphy->data->disconnect(phy, port);
+}
+
static const struct phy_ops spacemit_usb2phy_ops = {
.init = spacemit_usb2phy_init,
.exit = spacemit_usb2phy_exit,
@@ -173,6 +198,8 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
if (!sphy)
return -ENOMEM;
+ sphy->data = device_get_match_data(dev);
+
sphy->clk = devm_clk_get_prepared(&pdev->dev, NULL);
if (IS_ERR(sphy->clk))
return dev_err_probe(dev, PTR_ERR(sphy->clk), "Failed to get clock\n");
@@ -195,8 +222,17 @@ static int spacemit_usb2phy_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(phy_provider);
}
+static const struct spacemit_usb2phy_data k1_usb2phy_data = {
+ .disconnect = spacemit_k1_usb2phy_disconnect,
+};
+
+static const struct spacemit_usb2phy_data k3_usb2phy_data = {
+ .disconnect = spacemit_k3_usb2phy_disconnect,
+};
+
static const struct of_device_id spacemit_usb2phy_dt_match[] = {
- { .compatible = "spacemit,k1-usb2-phy", },
+ { .compatible = "spacemit,k1-usb2-phy", .data = &k1_usb2phy_data },
+ { .compatible = "spacemit,k3-usb2-phy", .data = &k3_usb2phy_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, spacemit_usb2phy_dt_match);
--
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 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
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