* [PATCH v4 2/4] dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
From: Jiayu Du @ 2026-01-20 14:32 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: <20260120143243.71937-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
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Andrew Lunn @ 2026-01-20 13:32 UTC (permalink / raw)
To: Xu Yang
Cc: Frank Li, vkoul, neil.armstrong, shawnguo, kernel, festevam,
jun.li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <fmdje7ftwna5vv5xrzt5e7hpv4juzwjurhvdzzrfeifaeyyblj@givopw2u7vmn>
> > Rather than reinvent the wheel, could you use regmap?
> >
> > https://elixir.bootlin.com/linux/v6.12.1/source/drivers/base/regmap/regmap-debugfs.c#L546
> >
> > Regmap should be able to provide a debugfs interface for you, no
> > driver code needed.
> >
> > This will also help you with the abstraction between the core generic
> > part of the PHY driver and the SoC integration glue. You pass the
> > regmap to the core driver, and the funny muxing through two registers
> > is hidden away from the core. If the next SoC integrated uses plan
> > MMIO, that SoC glue driver can instantiate an MMIO regmap.
> >
> > Using regmap is a good idea for core generic drivers which can be
> > integrated into SoCs in different ways. It hides the SoC details
> > behind a well known API.
>
> Thanks for your suggestion.
>
> Using regmap is generally a good fit for reusable driver and I aggre it
> helps abstract Soc-specific details.
>
> However, the regmap defbugfs has its own limitations:
> 1. By default the register is read-only, add write operation require rebuild
> the kernel which make it inconvenient to debug the issue on the spot.
That is somewhat deliberate. We don't want a nice API which can be
used for user space binary blob drivers. In networking, which is my
more normal area, we pretty much reject any sort of write interface,
other than official kernel APIs.
> Refer to: "09c6ecd39410 regmap: Add support for writing to regmap registers
> via debugfs"
>
> # ls /sys/kernel/debug/regmap/2-0050/ -l
> total 0
> -r-------- 1 root root 0 Jan 20 07:45 access
> -r-------- 1 root root 0 Jan 20 07:45 name
> -r-------- 1 root root 0 Jan 20 07:45 range
> -r-------- 1 root root 0 Jan 20 07:45 registers
>
> 2. It can't randomly read specific one register with common linux commands. Besides,
> the read operation is inefficient especially when the range is a bit large because
> when you cat the register it always read and output all the registers.
You are debugging. Do you need efficient output?
If you have a specific debug tasks in mind, maybe you should be
thinking of an official kernel API? In the past, there has been
interest in getting SERDES eye information out of PHYs, and being able
to change the configuration parameters of the eye. Could a generic API
be added for that? Some of these PHYs also support pseudo random bit
sequence generators, and there has been interest in adding APIs for
configuring them.
Andrew
--
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: Vladimir Oltean @ 2026-01-20 12:11 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: <aW9VHt6meEJFxV0I@shell.armlinux.org.uk>
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.
Similarly, the fact we don't have to whom to report an error code
doesn't make it pointless to offer the guarantee that pcs_disable() will
be called only when pcs_enable() has succeeded. It is only the latter
that seems necessary in order to develop reliable complexity on top of
these.
If SerDes PHY integration in phylink_pcs drivers is a model to follow
for other drivers, I think the way in which balanced calls can be made
from pcs_enable()/pcs_disable() needs to be given more attention.
And I think it's a bit worse than "doesn't matter, the port is dead
anyway". For example, we can have QSGMII where 4 PCSes share a single
SerDes lane, so one single malfunctioning PCS instance can affect all
the others through the lane's phy->power_count.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature
From: Xu Yang @ 2026-01-20 11:17 UTC (permalink / raw)
To: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
Disabling PHYs in runtime usually causes the client with external abort
exception or similar issue due to lack of API to notify clients about PHY
removal. This patch removes the possibility to unbind i.MX PHY drivers in
runtime.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 028c4c9dea40..abfa6ac3ae3f 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -837,6 +837,7 @@ static struct platform_driver imx8mq_usb_phy_driver = {
.driver = {
.name = "imx8mq-usb-phy",
.of_match_table = imx8mq_usb_phy_of_match,
+ .suppress_bind_attrs = true,
}
};
module_platform_driver(imx8mq_usb_phy_driver);
--
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] phy: fsl-imx8mq-usb: set platform driver data
From: Xu Yang @ 2026-01-20 11:16 UTC (permalink / raw)
To: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
Add missing platform_set_drvdata() as the data will be used in remove().
Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index e9c113edd470..028c4c9dea40 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -778,6 +778,8 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (!imx_phy)
return -ENOMEM;
+ platform_set_drvdata(pdev, imx_phy);
+
imx_phy->clk = devm_clk_get(dev, "phy");
if (IS_ERR(imx_phy->clk)) {
dev_err(dev, "failed to get imx8mq usb phy clock\n");
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-20 11:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Frank Li, vkoul, neil.armstrong, shawnguo, kernel, festevam,
jun.li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <6d27a8b1-1407-40ff-945b-927ef0a39eb1@lunn.ch>
On Fri, Jan 16, 2026 at 04:19:01PM +0100, Andrew Lunn wrote:
> On Fri, Jan 16, 2026 at 07:29:39PM +0800, Xu Yang wrote:
> > On Thu, Jan 08, 2026 at 10:43:01AM -0500, Frank Li wrote:
> > > On Thu, Jan 08, 2026 at 04:36:41PM +0800, Xu Yang wrote:
> > > > The CR port is a simple 16-bit data/address parallel port that is
> > > > provided for on-chip access to the control registers inside the
> > > > USB 3.0 femtoPHY[1].
> > >
> > >
> > > > While access to these registers is not required
> > > > for normal PHY operation, this interface enables you to access
> > > > some of the PHY’s diagnostic features during normal operation or
> > > > to override some basic PHY control signals.
> > >
> > > Simple said "Export these registers by debugfs to help PHY’s diagnostic."
> > > should be enough
> >
> > OK.
> >
> > >
> > > >
> > > > 3 debugfs files are created to read and write control registers,
> > > > all use hexadecimal format:
> > > > ctrl_reg_base: the register offset to write, or the start offset
> > > > to read.
> > > > ctrl_reg_count: how many continuous registers to be read.
> > > > ctrl_reg_value: read to show the continuous registers value from
> > > > the offset in ctrl_reg_base, to ctrl_reg_base
> > > > + ctrl_reg_count - 1, one line for one register.
> > > > when write, override the register at ctrl_reg_base,
> > > > one time can only change one 16bits register.
> > >
> > > how many regs? how about create file regNNN,
> >
> > >From 0x0 to 0x201F.
>
> Rather than reinvent the wheel, could you use regmap?
>
> https://elixir.bootlin.com/linux/v6.12.1/source/drivers/base/regmap/regmap-debugfs.c#L546
>
> Regmap should be able to provide a debugfs interface for you, no
> driver code needed.
>
> This will also help you with the abstraction between the core generic
> part of the PHY driver and the SoC integration glue. You pass the
> regmap to the core driver, and the funny muxing through two registers
> is hidden away from the core. If the next SoC integrated uses plan
> MMIO, that SoC glue driver can instantiate an MMIO regmap.
>
> Using regmap is a good idea for core generic drivers which can be
> integrated into SoCs in different ways. It hides the SoC details
> behind a well known API.
Thanks for your suggestion.
Using regmap is generally a good fit for reusable driver and I aggre it
helps abstract Soc-specific details.
However, the regmap defbugfs has its own limitations:
1. By default the register is read-only, add write operation require rebuild
the kernel which make it inconvenient to debug the issue on the spot.
Refer to: "09c6ecd39410 regmap: Add support for writing to regmap registers
via debugfs"
# ls /sys/kernel/debug/regmap/2-0050/ -l
total 0
-r-------- 1 root root 0 Jan 20 07:45 access
-r-------- 1 root root 0 Jan 20 07:45 name
-r-------- 1 root root 0 Jan 20 07:45 range
-r-------- 1 root root 0 Jan 20 07:45 registers
2. It can't randomly read specific one register with common linux commands. Besides,
the read operation is inefficient especially when the range is a bit large because
when you cat the register it always read and output all the registers.
Thanks,
Xu Yang
>
> Andrew
>
--
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-20 10:14 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: <20260120084227.j2wgbmjsrpmycpgn@skbuf>
On Tue, Jan 20, 2026 at 10:42:27AM +0200, Vladimir Oltean wrote:
> More to the point, if dwmac_integrated_pcs_enable() fails at
> dwmac_serdes_power_on() (thus, the SerDes is _not_ powered on), by your
> own admission of this PCS calling convention, sooner or later
> dwmac_integrated_pcs_disable() -> dwmac_serdes_power_off() will still be
> called, leading to a negative phy->power_count.
>
> That is to say, if the model is "irrespective of whether pcs_enable()
> succeeds or fails mid way, pcs_disable is called anyway()", then these
> methods are not prepared to handle that reliably.
That's the way it currently is, and it's been this way in the
major_config path for a very long time. If anything fails in that
path, we can't report the error back up to anyone, and the netdev
is effectively dead.
--
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: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-20 10:12 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: <20260120081844.7e6aq2urhxrylywi@skbuf>
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.
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.
--
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 v5 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux
From: Geert Uytterhoeven @ 2026-01-20 9:49 UTC (permalink / raw)
To: Josua Mayer
Cc: 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, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can, linux-phy, linux-kernel,
linux-omap, linux-i2c, linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-7-3c37e8872683@solid-run.com>
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> Some hardware designs route data or control signals through a mux to
> support multiple devices on a single sdhi controller.
>
> In particular SolidRun RZ/G2L/G2LC/V2L System on Module use a mux for
> switching between soldered eMMC and an optional microSD on a carrier
> board, e.g. for development or provisioning.
>
> SD/SDIO/eMMC are not well suited for runtime switching between different
> cards, however boot-time selection is possible and useful - in
> particular considering dt overlays.
>
> Add support for an optional SD/SDIO/eMMC mux defined in dt, and select
> it during probe.
>
> Similar functionality already exists in other places, e.g. i2c-omap.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Geert Uytterhoeven @ 2026-01-20 9:45 UTC (permalink / raw)
To: Josua Mayer
Cc: 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,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-2-3c37e8872683@solid-run.com>
Hi Josua,
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> In-tree phy-can-transceiver driver has already implemented a local
> version of devm_mux_state_get_optional.
>
> The omap-i2c driver gets and selects an optional mux in its probe
> function without using any helper.
>
> Add new helper functions covering both aforementioned use-cases:
>
> - mux_control_get_optional:
> Get a mux-control if specified in dt, return NULL otherwise.
> - devm_mux_state_get_optional:
> Get a mux-state if specified in dt, return NULL otherwise.
> - devm_mux_state_get_selected:
> Get and select a mux-state specified in dt, return error otherwise.
> - devm_mux_state_get_optional_selected:
> Get and select a mux-state if specified in dt, return error or NULL.
>
> Existing mux_get helper function is changed to take an extra argument
> indicating whether the mux is optional.
> In this case no error is printed, and NULL returned in case of ENOENT.
>
> Calling code is adapted to handle NULL return case, and to pass optional
> argument as required.
>
> To support automatic deselect for _selected helper, a new structure is
> created storing an exit pointer similar to clock core which is called on
> release.
>
> To facilitate code sharing between optional/mandatory/selected helpers,
> a new internal helper function is added to handle quiet (optional) and
> verbose (mandatory) errors, as well as storing the correct callback for
> devm release: __devm_mux_state_get
>
> Due to this structure devm_mux_state_get_*_selected can no longer print
> a useful error message when select fails. Instead callers should print
> errors where needed.
>
> Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
> property presence check") noted that "mux_get() always prints an error
> message in case of an error, including when the property is not present,
> confusing the user."
>
> The first error message covers the case that a mux name is not matched
> in dt. The second error message is based on of_parse_phandle_with_args
> return value.
>
> In optional case no error is printed and NULL is returned.
> This ensures that the new helper functions will not confuse the user
> either.
>
> With the addition of optional helper functions it became clear that
> drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
> Add stubs for all symbols exported by mux core.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Thanks for your patch!
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -677,7 +707,7 @@ EXPORT_SYMBOL_GPL(devm_mux_control_get);
> *
> * Return: A pointer to the mux-state, or an ERR_PTR with a negative errno.
> */
> -static struct mux_state *mux_state_get(struct device *dev, const char *mux_name)
> +static struct mux_state *mux_state_get(struct device *dev, const char *mux_name, bool optional)
> {
> struct mux_state *mstate;
>
> @@ -685,12 +715,10 @@ static struct mux_state *mux_state_get(struct device *dev, const char *mux_name)
> if (!mstate)
> return ERR_PTR(-ENOMEM);
>
> - mstate->mux = mux_get(dev, mux_name, &mstate->state);
> - if (IS_ERR(mstate->mux)) {
> - int err = PTR_ERR(mstate->mux);
> -
> + mstate->mux = mux_get(dev, mux_name, &mstate->state, optional);
> + if (IS_ERR_OR_NULL(mstate->mux)) {
> kfree(mstate);
mstate is freed here...
> - return ERR_PTR(err);
> + return ERR_CAST(mstate->mux);
... and dereferenced here, leading to a use after free.
> }
>
> return mstate;
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 v5 11/24] scsi: ufs: mediatek: Rework probe function
From: AngeloGioacchino Del Regno @ 2026-01-20 9:43 UTC (permalink / raw)
To: Peter Wang (王信友), chu.stanley@gmail.com,
robh@kernel.org, Chunfeng Yun (云春峰),
kishon@kernel.org, James.Bottomley@HansenPartnership.com,
bvanassche@acm.org, Chaotian Jing (井朝天),
conor+dt@kernel.org, lgirdwood@gmail.com,
nicolas.frattaroli@collabora.com, vkoul@kernel.org,
krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, krzk@kernel.org,
neil.armstrong@linaro.org, matthias.bgg@gmail.com,
avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <74944c55418976375955430d27ac568149d555f1.camel@mediatek.com>
Il 13/01/26 08:26, Peter Wang (王信友) ha scritto:
> On Mon, 2026-01-12 at 16:02 +0100, AngeloGioacchino Del Regno wrote:
>> No, MediaTek's reset hardware implementation is not the same as Texas
>> Instruments.
>> It was *very similar* to TI in the past (years ago, around the MT6795
>> Helio
>> generation times).
>>
>> MediaTek's reset controller - by hardware - is definitely different
>> from the one
>> found in TI SoCs.
>>
>> Regards,
>> Angelo
>
> I did not notice this change.
> Will you be helping to upstream MediaTek's reset controller instead of
> TI's?
>
The main reset controllers are already integrated in clock drivers since
... well, years ago.
If there's any additional reset controller that is missing, and special to
UFS, and that's not in the UFS clock driver, yes we can upstream that.
Cheers,
Angelo
> Thanks
> Peter
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Geert Uytterhoeven @ 2026-01-20 9:35 UTC (permalink / raw)
To: Josua Mayer
Cc: 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,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-1-3c37e8872683@solid-run.com>
Hi Josua,
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> Rename the temporary devm_mux_state_get_optional function to avoid
> conflict with upcoming implementation in multiplexer subsystem.
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
My
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
on v3 is still valid.
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 v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-20 9:28 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <8c63a77c-1676-461a-bfcf-55202e723718@oss.qualcomm.com>
On Tue, Jan 20, 2026 at 03:56:10PM +0800, Yongxing Mou wrote:
>
>
> On 1/20/2026 11:12 AM, Dmitry Baryshkov wrote:
> > On Tue, Jan 20, 2026 at 10:43:46AM +0800, Yongxing Mou wrote:
> > >
> > >
> > > On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
> > > > > Currently, the LeMans/Monaco devices and their derivative platforms
> > > > > operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
> > > > > Emphasis settings need to be corrected to the proper values.
> > > >
> > > > No, they need to be configured dynamically. I wrote earlier that the
> > > > driver needs refactoring.
> > > >
> > > Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch →
> > > refactor.
> > > Since the refactor involves more platforms and may take some time, I’d like
> > > to get this patch merged first.
> >
> > This patch is incorrect. It trades working on some platforms (DP) vs
> > working of someo ther platforms (eDP). I don't think it is a proper fix
> > for any problem.
> >
> Got it.. will post refactor series.
Thanks! I don't see a good way to fix your issue without restructuring
the driver.
Note, the driver has to support both older DT (which used separate -edp
and -dp compats) and the current one.
> > > > >
> > > > > This will help achieve successful link training on some dongles.
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
> > > > > Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> > > > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > > > ---
> > > > > Changes in v2:
> > > > > - Separate the LDO change out.[Konrad][Dmitry]
> > > > > - Modify the commit message.[Dmitry]
> > > > > - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
> > > > > ---
> > > > > drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
> > > > > 1 file changed, 22 insertions(+), 1 deletion(-)
> > > > >
> > > >
> > >
> > >
> > > --
> > > linux-phy mailing list
> > > linux-phy@lists.infradead.org
> > > https://lists.infradead.org/mailman/listinfo/linux-phy
> >
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-20 8:42 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: <aW8M9ZiiftGBQIRM@shell.armlinux.org.uk>
On Tue, Jan 20, 2026 at 05:04:53AM +0000, Russell King (Oracle) wrote:
> On Mon, Jan 19, 2026 at 11:21:25AM -0800, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> >
> > For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > net: stmmac: add stmmac core serdes support
> >
> > This commit adds SerDes PHY support to the stmmac core driver, moving it
> > from platform glue into the integrated PCS driver. The SerDes is managed
> > through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
> > for the power state.
> >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > index 2f826fe7229b..4d1902f3a58f 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> >
> > [ ... ]
> >
> > > static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> > > {
> > > struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> > > + struct stmmac_priv *priv = spcs->priv;
> > > + int ret;
> > >
> > > - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> > > + ret = dwmac_serdes_power_on(priv);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> > > + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> > > + if (ret)
> > > + return ret;
> > ^^^^^^^^^^
> >
> > If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
> > a powered-on state? dwmac_serdes_power_on() succeeded at this point but
> > there's no corresponding dwmac_serdes_power_off() call before returning
> > the error.
> >
> > Looking at phylink_major_config(), it appears to discard the return
> > value from phylink_pcs_enable(), so the caller won't know to call
> > pcs_disable() to clean up the power state.
>
> This AI analysis is incorrect.
>
> By the time phylink_pcs_enable() has been called, the PCS is already
> plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
> it at some point in the future, either by having the PCS displaced
> by another in a subsequent phylink_major_config(), or by a driver
> calling phylink_stop().
>
> If we clean up here, then we will call dwmac_serdes_power_off() twice.
>
> Yes, it's not "nice" but that's the way phylink is right now, and
> without reworking phylink to record that pcs_enable() has failed
> to avoid a subsequent pcs_disable(), and to stop the major config
> (which then potentially causes a whole bunch of other issues). I
> don't even want to think about that horrid scenario at the moment.
More to the point, if dwmac_integrated_pcs_enable() fails at
dwmac_serdes_power_on() (thus, the SerDes is _not_ powered on), by your
own admission of this PCS calling convention, sooner or later
dwmac_integrated_pcs_disable() -> dwmac_serdes_power_off() will still be
called, leading to a negative phy->power_count.
That is to say, if the model is "irrespective of whether pcs_enable()
succeeds or fails mid way, pcs_disable is called anyway()", then these
methods are not prepared to handle that reliably.
--
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: Vladimir Oltean @ 2026-01-20 8:18 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: <aW8M9ZiiftGBQIRM@shell.armlinux.org.uk>
On Tue, Jan 20, 2026 at 05:04:53AM +0000, Russell King (Oracle) wrote:
> On Mon, Jan 19, 2026 at 11:21:25AM -0800, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> >
> > For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > net: stmmac: add stmmac core serdes support
> >
> > This commit adds SerDes PHY support to the stmmac core driver, moving it
> > from platform glue into the integrated PCS driver. The SerDes is managed
> > through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
> > for the power state.
> >
> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > index 2f826fe7229b..4d1902f3a58f 100644
> > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> >
> > [ ... ]
> >
> > > static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> > > {
> > > struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> > > + struct stmmac_priv *priv = spcs->priv;
> > > + int ret;
> > >
> > > - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> > > + ret = dwmac_serdes_power_on(priv);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> > > + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> > > + if (ret)
> > > + return ret;
> > ^^^^^^^^^^
> >
> > If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
> > a powered-on state? dwmac_serdes_power_on() succeeded at this point but
> > there's no corresponding dwmac_serdes_power_off() call before returning
> > the error.
> >
> > Looking at phylink_major_config(), it appears to discard the return
> > value from phylink_pcs_enable(), so the caller won't know to call
> > pcs_disable() to clean up the power state.
>
> This AI analysis is incorrect.
>
> By the time phylink_pcs_enable() has been called, the PCS is already
> plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
> it at some point in the future, either by having the PCS displaced
> by another in a subsequent phylink_major_config(), or by a driver
> calling phylink_stop().
>
> If we clean up here, then we will call dwmac_serdes_power_off() twice.
>
> Yes, it's not "nice" but that's the way phylink is right now, and
> without reworking phylink to record that pcs_enable() has failed
> to avoid a subsequent pcs_disable(), and to stop the major config
> (which then potentially causes a whole bunch of other issues). I
> don't even want to think about that horrid scenario at the moment.
Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
after calling pcs_disable(), though?
I had to deal with the same issue when preparing patches that integrate
SerDes support into the Lynx PCS.
I had these patches (please pardon the unadapted commit messages for the
present situation):
-- >8 --
Subject: [PATCH] net: phylink: handle return code from phylink_pcs_enable()
I am trying to make phylink_pcs_ops :: pcs_enable() something that is
handled sufficiently carefully by phylink, such that we can expect that
when we return an error code here, no other phylink_pcs_ops call is
being made. This way, the API can be considered sufficiently reliable to
allocate memory in pcs_enable() which is freed in pcs_disable().
Currently this does not take place. The pcs_enable() method has an int
return code, which is ignored. If the PCS returns an error, the
initialization of the phylink instance is not stopped, but continues on
like a train, most likely triggering faults somewhere else.
Like this:
$ ip link set endpmac2 up
fsl_dpaa2_eth dpni.1 endpmac2: configuring for c73/10gbase-kr link mode
fsl_dpaa2_eth dpni.1 endpmac2: pcs_enable() failed: -ENOMEM // added by me
Unable to handle kernel paging request at virtual address fffffffffffffff4
Call trace:
mtip_backplane_get_state+0x34/0x2b4
lynx_pcs_get_state+0x30/0x180
phylink_resolve+0x2c0/0x764
process_scheduled_works+0x228/0x330
worker_thread+0x28c/0x450
Do a minimal handling of the error by clearing pl->pcs, so that we lose
access to its ops, and thus are unable to call anything else (which
would be invalid anyway).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/phy/phylink.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 32ffa4f9e5b2..a8459116b701 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1315,8 +1315,15 @@ static void phylink_major_config(struct phylink *pl, bool restart,
}
}
- if (pl->pcs_state == PCS_STATE_STARTING || pcs_changed)
- phylink_pcs_enable(pl->pcs);
+ if (pl->pcs_state == PCS_STATE_STARTING || pcs_changed) {
+ err = phylink_pcs_enable(pl->pcs);
+ if (err < 0) {
+ phylink_err(pl, "pcs_enable() failed: %pe\n",
+ ERR_PTR(err));
+ pl->pcs = NULL;
+ return;
+ }
+ }
err = phylink_pcs_config(pl->pcs, pl->pcs_neg_mode, state,
!!(pl->link_config.pause & MLO_PAUSE_AN));
-- >8 --
-- >8 --
Subject: [PATCH] net: phylink: suppress pcs->ops->pcs_get_state() calls after
phylink_stop()
I am attempting to make phylink_pcs_ops :: pcs_disable() treated
sufficiently carefully by phylink so as to be able to free memory
allocations from this PCS callback, and do not suffer from faults
attempting to access that memory later from other phylink_pcs callbacks.
Currently, nothing prevents this situation from happening:
$ ip link set endpmac2 up
$ ip link set endpmac2 down
$ ethtool endpmac2
Unable to handle kernel paging request at virtual address 0000100000000034
Call trace:
__mutex_lock+0xb8/0x574
__mutex_lock_slowpath+0x14/0x20
mutex_lock+0x24/0x58
mtip_backplane_get_state+0x44/0x24c
lynx_pcs_get_state+0x30/0x180
phylink_ethtool_ksettings_get+0x178/0x218
dpaa2_eth_get_link_ksettings+0x54/0xa4
__ethtool_get_link_ksettings+0x68/0xa8
linkmodes_prepare_data+0x44/0xc4
ethnl_default_doit+0x118/0x39c
genl_rcv_msg+0x29c/0x314
netlink_rcv_skb+0x11c/0x134
genl_rcv+0x34/0x4c
However, the case where "ethtool endpmac2" is executed as the first
thing (before the interface is brought up) does not crash. What's
different is that second situation is that phylink_major_config() did
not run yet, so pl->pcs is still NULL inside phylink_mac_pcs_get_state().
In plain English, "as long as the PCS is disabled, the link is naturally
down, no need to ask".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/phy/phylink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index a8459116b701..f78d0e0f7cfb 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -2527,6 +2527,7 @@ void phylink_stop(struct phylink *pl)
pl->pcs_state = PCS_STATE_DOWN;
phylink_pcs_disable(pl->pcs);
+ pl->pcs = NULL;
}
EXPORT_SYMBOL_GPL(phylink_stop);
-- >8 --
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Yongxing Mou @ 2026-01-20 7:56 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <5ytgf7saw6yfvqzqmy4gtjygo4cx52vomi7mwswc7hgedzz3rb@eiqxiqs2cjmb>
On 1/20/2026 11:12 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 20, 2026 at 10:43:46AM +0800, Yongxing Mou wrote:
>>
>>
>> On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
>>> On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
>>>> Currently, the LeMans/Monaco devices and their derivative platforms
>>>> operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
>>>> Emphasis settings need to be corrected to the proper values.
>>>
>>> No, they need to be configured dynamically. I wrote earlier that the
>>> driver needs refactoring.
>>>
>> Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch →
>> refactor.
>> Since the refactor involves more platforms and may take some time, I’d like
>> to get this patch merged first.
>
> This patch is incorrect. It trades working on some platforms (DP) vs
> working of someo ther platforms (eDP). I don't think it is a proper fix
> for any problem.
>
Got it.. will post refactor series.
>>>>
>>>> This will help achieve successful link training on some dongles.
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
>>>> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>> Changes in v2:
>>>> - Separate the LDO change out.[Konrad][Dmitry]
>>>> - Modify the commit message.[Dmitry]
>>>> - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
>>>> ---
>>>> drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
>>>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>>>
>>>
>>
>>
>> --
>> linux-phy mailing list
>> linux-phy@lists.infradead.org
>> https://lists.infradead.org/mailman/listinfo/linux-phy
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/4] Add USB support for Canaan K230
From: Greg KH @ 2026-01-20 6:06 UTC (permalink / raw)
To: Jiayu Du
Cc: vkoul, conor, neil.armstrong, robh, krzk+dt, pjw, palmer, aou,
alex, linux-phy, linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <aW5WyizgDyQJaKLQ@duge-virtual-machine>
On Tue, Jan 20, 2026 at 12:07:38AM +0800, Jiayu Du wrote:
> On Mon, Jan 19, 2026 at 05:38:31PM +0800, Jiayu Du wrote:
>
> This is series is the RESEND of the series here[1]. I resend it
> because I mistakenly sent the wrong USBPHY driver code.
>
> Link: https://lore.kernel.org/all/20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
> ]
>
I have no idea which is which anymore, sorry. Please send out a v4 so
we know which to look at.
confused,
greg k-h
--
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-20 5:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: 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: <20260119192125.1245102-1-kuba@kernel.org>
On Mon, Jan 19, 2026 at 11:21:25AM -0800, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> net: stmmac: add stmmac core serdes support
>
> This commit adds SerDes PHY support to the stmmac core driver, moving it
> from platform glue into the integrated PCS driver. The SerDes is managed
> through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
> for the power state.
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > index 2f826fe7229b..4d1902f3a58f 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
>
> [ ... ]
>
> > static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> > {
> > struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> > + struct stmmac_priv *priv = spcs->priv;
> > + int ret;
> >
> > - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> > + ret = dwmac_serdes_power_on(priv);
> > + if (ret)
> > + return ret;
> > +
> > + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> > + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> > + if (ret)
> > + return ret;
> ^^^^^^^^^^
>
> If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
> a powered-on state? dwmac_serdes_power_on() succeeded at this point but
> there's no corresponding dwmac_serdes_power_off() call before returning
> the error.
>
> Looking at phylink_major_config(), it appears to discard the return
> value from phylink_pcs_enable(), so the caller won't know to call
> pcs_disable() to clean up the power state.
This AI analysis is incorrect.
By the time phylink_pcs_enable() has been called, the PCS is already
plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
it at some point in the future, either by having the PCS displaced
by another in a subsequent phylink_major_config(), or by a driver
calling phylink_stop().
If we clean up here, then we will call dwmac_serdes_power_off() twice.
Yes, it's not "nice" but that's the way phylink is right now, and
without reworking phylink to record that pcs_enable() has failed
to avoid a subsequent pcs_disable(), and to stop the major config
(which then potentially causes a whole bunch of other issues). I
don't even want to think about that horrid scenario at the moment.
--
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 v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-20 3:12 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <749e716e-a6cb-4adb-8ffc-0d6f4c6d56c4@oss.qualcomm.com>
On Tue, Jan 20, 2026 at 10:43:46AM +0800, Yongxing Mou wrote:
>
>
> On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
> > On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
> > > Currently, the LeMans/Monaco devices and their derivative platforms
> > > operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
> > > Emphasis settings need to be corrected to the proper values.
> >
> > No, they need to be configured dynamically. I wrote earlier that the
> > driver needs refactoring.
> >
> Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch →
> refactor.
> Since the refactor involves more platforms and may take some time, I’d like
> to get this patch merged first.
This patch is incorrect. It trades working on some platforms (DP) vs
working of someo ther platforms (eDP). I don't think it is a proper fix
for any problem.
> > >
> > > This will help achieve successful link training on some dongles.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
> > > Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > ---
> > > Changes in v2:
> > > - Separate the LDO change out.[Konrad][Dmitry]
> > > - Modify the commit message.[Dmitry]
> > > - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
> > > 1 file changed, 22 insertions(+), 1 deletion(-)
> > >
> >
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Yongxing Mou @ 2026-01-20 2:43 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel, stable, Abel Vesa
In-Reply-To: <47skckagggxijdhinmmibtrd3dydixtj6pccrgjwyczs7bj2te@2rq2iprmzvyf>
On 1/19/2026 8:55 PM, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 08:37:20PM +0800, Yongxing Mou wrote:
>> Currently, the LeMans/Monaco devices and their derivative platforms
>> operate in DP mode rather than eDP mode. Per the PHY HPG, the Swing and
>> Emphasis settings need to be corrected to the proper values.
>
> No, they need to be configured dynamically. I wrote earlier that the
> driver needs refactoring.
>
Hi, Dmitry. I plan to submit them in this order: this patch → LDO patch
→ refactor.
Since the refactor involves more platforms and may take some time, I’d
like to get this patch merged first.
>>
>> This will help achieve successful link training on some dongles.
>>
>> Cc: stable@vger.kernel.org
>> Fixes: 3f12bf16213c ("phy: qcom: edp: Add support for eDP PHY on SA8775P")
>> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Separate the LDO change out.[Konrad][Dmitry]
>> - Modify the commit message.[Dmitry]
>> - Link to v1: https://lore.kernel.org/r/20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com
>> ---
>> drivers/phy/qualcomm/phy-qcom-edp.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,12/14] net: stmmac: add support for reading inband SGMII status
From: Jakub Kicinski @ 2026-01-19 19:21 UTC (permalink / raw)
To: rmk+kernel
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: <E1vhoSr-00000005H2N-2H2L@rmk-PC.armlinux.org.uk>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: add support for reading inband SGMII status
This patch adds support for reading link status, speed, and duplex for
SGMII links from the RGSMII status register. New fields are added to
stmmac_pcs_info and stmmac_pcs structures for the register offset and mask.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> index 73fc56ce5e55..9dd7e78cfbc4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
[ ... ]
> @@ -111,7 +121,37 @@ static void dwmac_integrated_pcs_get_state(struct phylink_pcs *pcs,
>
> phylink_mii_c22_pcs_decode_state(state, neg_mode, status, lpa);
> } else {
> - state->link = false;
> + rgsmii = field_get(spcs->rgsmii_status_mask,
> + readl(spcs->rgsmii));
^^^^
When dwmac1000_pcs_init() or dwmac4_pcs_init() is used, the pcs_info
structures do not initialize the new rgsmii_offset and rgsmii_status_mask
fields. For example, dwmac4_pcs_info in dwmac4_core.c only sets:
static const struct stmmac_pcs_info dwmac4_pcs_info = {
.pcs_offset = GMAC_PCS_BASE,
.int_mask = GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
};
This leaves rgsmii_status_mask implicitly zero. Calling field_get() with a
mask of zero violates its API contract (mask must be non-zero) and results
in undefined behavior from __ffs(0).
Should the existing dwmac1000_pcs_info and dwmac4_pcs_info structures be
updated to provide proper values for the new fields? Or should there be a
guard check before calling field_get() when rgsmii_status_mask is zero?
> +
> + state->link = status & BMSR_LSTATUS &&
> + rgsmii & GMAC_RGSMIII_LNKSTS;
[ ... ]
> @@ -205,6 +245,8 @@ int stmmac_integrated_pcs_init(struct stmmac_priv *priv,
>
> spcs->priv = priv;
> spcs->base = priv->ioaddr + pcs_info->pcs_offset;
> + spcs->rgsmii = priv->ioaddr + pcs_info->rgsmii_offset;
> + spcs->rgsmii_status_mask = pcs_info->rgsmii_status_mask;
The values are copied from pcs_info here, but dwmac1000_pcs_info and
dwmac4_pcs_info do not initialize these fields.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> index a7c71f40f952..f9e7a7ed840b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
> @@ -29,12 +29,16 @@ struct stmmac_priv;
>
> struct stmmac_pcs_info {
> unsigned int pcs_offset;
> + unsigned int rgsmii_offset;
> + u32 rgsmii_status_mask;
> u32 int_mask;
> };
These new fields need to be initialized by all users of stmmac_pcs_info.
--
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: Jakub Kicinski @ 2026-01-19 19:21 UTC (permalink / raw)
To: rmk+kernel
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: <E1vhoSH-00000005H1f-2cq9@rmk-PC.armlinux.org.uk>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: add stmmac core serdes support
This commit adds SerDes PHY support to the stmmac core driver, moving it
from platform glue into the integrated PCS driver. The SerDes is managed
through phy_init/phy_exit for lifecycle and phy_power_on/phy_power_off
for the power state.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> index 2f826fe7229b..4d1902f3a58f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
[ ... ]
> static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
> {
> struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> + struct stmmac_priv *priv = spcs->priv;
> + int ret;
>
> - stmmac_mac_irq_modify(spcs->priv, 0, spcs->int_mask);
> + ret = dwmac_serdes_power_on(priv);
> + if (ret)
> + return ret;
> +
> + if (spcs->interface != PHY_INTERFACE_MODE_NA) {
> + ret = dwmac_serdes_set_mode(priv, spcs->interface);
> + if (ret)
> + return ret;
^^^^^^^^^^
If dwmac_serdes_set_mode() fails here, doesn't this leave the SerDes in
a powered-on state? dwmac_serdes_power_on() succeeded at this point but
there's no corresponding dwmac_serdes_power_off() call before returning
the error.
Looking at phylink_major_config(), it appears to discard the return
value from phylink_pcs_enable(), so the caller won't know to call
pcs_disable() to clean up the power state.
Should this be something like:
if (spcs->interface != PHY_INTERFACE_MODE_NA) {
ret = dwmac_serdes_set_mode(priv, spcs->interface);
if (ret) {
dwmac_serdes_power_off(priv);
return ret;
}
}
> + }
> +
> + stmmac_mac_irq_modify(priv, 0, spcs->int_mask);
>
> return 0;
> }
[ ... ]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-01-19 16:07 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex, linux-phy,
linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn>
On Mon, Jan 19, 2026 at 05:38:31PM +0800, Jiayu Du wrote:
This is series is the RESEND of the series here[1]. I resend it
because I mistakenly sent the wrong USBPHY driver code.
Link: https://lore.kernel.org/all/20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 00/11] Describe PCIe/USB3.0 clock generator on R-Car Gen3
From: Geert Uytterhoeven @ 2026-01-19 15:58 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <2b6f19f3-aaf9-4fb7-bef7-f38e19f94351@mailbox.org>
Hi Marek,
On Sun, 18 Jan 2026 at 14:54, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 1/13/26 3:19 PM, Geert Uytterhoeven wrote:
> > I do not know what is the actual issue. Adding debug prints to
> > rs9_suspend() and rs9_resume() shows these functions are not called,
> > while adding 'status = "disabled"' to the renesas,9fgv0841 clock node
> > in arch/arm64/boot/dts/renesas/salvator-common.dtsi does fix the issue.
> >
> > Perhaps you have pending patches for the rs9 or PCIe drivers?
> > Do you have a clue?
> I believe this one should address the problem:
>
> [PATCH] clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841
>
> https://lore.kernel.org/linux-clk/20260118025756.96377-1-marek.vasut+renesas@mailbox.org/
Yes it does, thanks!
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] dt-bindings: phy: sc8280xp-qmp-pcie: Disallow bifurcation register on Purwa
From: Konrad Dybcio @ 2026-01-19 15:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, Konrad Dybcio, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, YijieYang
In-Reply-To: <8ea2358b-00e9-44b2-acce-777863e8688e@kernel.org>
On 1/19/26 3:50 PM, Krzysztof Kozlowski wrote:
> On 19/01/2026 12:48, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> Neither of the two Gen4x4 PHYs found on Purwa supports bifurcation.
>> The PHY is however physically laid out as if it were to, since there
>> are two separate ports (A/B).
>>
>> Split out a new if-then block to un-require the bifurcation register
>> handle to squash this warning:
>>
>> purwa-iot-evk.dtb: phy@1bd4000 (qcom,x1p42100-qmp-gen4x4-pcie-phy): 'qcom,4ln-config-sel' is a required property
>
> Warning does not exist in the kernel, so please do not reference it.
Only because no Purwa-based device enables it, so I think it's valid
If you really want to, I can resend with that mention removed
Konrad
--
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