* [PATCH v6 00/24] MediaTek UFS Cleanup and MT8196 Enablement
From: Nicolas Frattaroli @ 2026-01-24 12:00 UTC (permalink / raw)
To: Alim Akhtar, Avri Altman, Bart Van Assche, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chunfeng Yun, Vinod Koul,
Kishon Vijay Abraham I, Peter Wang, Stanley Jhu,
James E.J. Bottomley, Martin K. Petersen, Philipp Zabel,
Liam Girdwood, Mark Brown, Chaotian Jing, Neil Armstrong
Cc: Louis-Alexis Eyraud, kernel, linux-scsi, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-phy, Nicolas Frattaroli,
Conor Dooley, Krzysztof Kozlowski
In this series, the existing MediaTek UFS binding is expanded and
completed to correctly describe not just the existing compatibles, but
also to introduce a new compatible in the from of the MT8196 SoC.
The resets, which until now were completely absent from both the UFS
host controller binding and the UFS PHY binding, are introduced to both.
This also means the driver's undocumented and, in mainline, unused reset
logic is reworked. In particular, the PHY reset is no longer a reset of
the host controller node, but of the PHY node.
This means the host controller can reset the PHY through the common PHY
framework.
The resets remain optional.
Additionally, a massive number of driver cleanups are introduced. These
were prompted by me inspecting the driver more closely as I was
adjusting it to correspond to the binding.
The driver still implements vendor properties that are undocumented in
the binding. I did not touch most of those, as I neither want to
convince the bindings maintainers that they are needed without knowing
precisely what they're for, nor do I want to argue with the driver
authors when removing them.
Due to the "Marie Kondo with a chainsaw" nature of the driver cleanup
patches, I humbly request that reviewers do not comment on displeasing
code they see in the context portion of a patch before they've read the
whole patch series, as that displeasing code may in fact be reworked in
a subsequent patch of this series. Please keep comments focused on the
changed lines of the diff; I know there's more that can be done, but it
doesn't necessarily need to be part of this series.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v6:
- Reword "Rework probe function" commit to better justify the changes
being made.
- Drop "Add vendor prefix to clk-scale-up-vcore-min"
- Add patch to remove clk-scale-up-vcore-min entirely, describing the
process for bringing it back (in a different form) in the commit
message.
- Link to v5: https://lore.kernel.org/r/20260108-mt8196-ufs-v5-0-49215157ec41@collabora.com
Changes in v5:
- Drop "scsi: ufs: mediatek: Make scale_us in setup_clk_gating const" as
someone else already got a patch in for this into next.
- Make mtk_init_boost_crypt void
- Don't disable/enable misc regulators during suspend/resume, but enable
them once when acquiring with a devm helper.
- Link to v4: https://lore.kernel.org/r/20251218-mt8196-ufs-v4-0-ddec7a369dd2@collabora.com
Changes in v4:
- bindings: Redo the supply situation, as the avdd pins don't describe
the vcc(q2) card supplies.
- bindings: format clock in mt8196 example more tersely.
- phy: use devm_reset_control_get_optional_exclusive directly
- driver: get and enable/disable the aforementioned avdd supplies.
- Link to v3: https://lore.kernel.org/r/20251023-mt8196-ufs-v3-0-0f04b4a795ff@collabora.com
Changes in v3:
- Split mediatek,ufs bindings change into two patches, one for
completing the existing binding, one for the MT8196
- Add over a dozen driver cleanup patches
- Add explicit support for the MT8196 compatible to the driver
- Note: next-20251023, on which I based this, currently has a broken
build due to an unrelated OPP core change that was merged with no
build testing. I can't use next-20251022 either, as that lacks the
recent mediatek UFS changes. It is what it is.
- Link to v2: https://lore.kernel.org/r/20251016-mt8196-ufs-v2-0-c373834c4e7a@collabora.com
Changes in v2:
- Reorder define in mtk_sip_svc.h
- Use bulk reset APIs in UFS host driver
- Link to v1: https://lore.kernel.org/r/20251014-mt8196-ufs-v1-0-195dceb83bc8@collabora.com
---
Nicolas Frattaroli (24):
dt-bindings: phy: Add mediatek,mt8196-ufsphy variant
dt-bindings: ufs: mediatek,ufs: Complete the binding
dt-bindings: ufs: mediatek,ufs: Add mt8196 variant
scsi: ufs: mediatek: Move MTK_SIP_UFS_CONTROL to mtk_sip_svc.h
phy: mediatek: ufs: Add support for resets
scsi: ufs: mediatek: Rework resets
scsi: ufs: mediatek: Rework 0.9V regulator
scsi: ufs: mediatek: Rework init function
scsi: ufs: mediatek: Rework the crypt-boost stuff
scsi: ufs: mediatek: Handle misc host voltage regulators
scsi: ufs: mediatek: Rework probe function
scsi: ufs: mediatek: Remove vendor kernel quirks cruft
scsi: ufs: mediatek: Use the common PHY framework
scsi: ufs: mediatek: Switch to newer PM ops helpers
scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property
scsi: ufs: mediatek: Rework _ufs_mtk_clk_scale error paths
scsi: ufs: mediatek: Clean up logging prints
scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state
scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice
scsi: ufs: mediatek: Rework hardware version reading
scsi: ufs: mediatek: Back up idle timer in per-instance struct
scsi: ufs: mediatek: Remove ret local from link_startup_notify
scsi: ufs: mediatek: Remove undocumented "clk-scale-up-vcore-min"
scsi: ufs: mediatek: Add MT8196 compatible, update copyright
.../devicetree/bindings/phy/mediatek,ufs-phy.yaml | 16 +
.../devicetree/bindings/ufs/mediatek,ufs.yaml | 173 +++-
drivers/phy/mediatek/phy-mtk-ufs.c | 71 ++
drivers/ufs/host/ufs-mediatek-sip.h | 9 -
drivers/ufs/host/ufs-mediatek.c | 973 +++++++++------------
drivers/ufs/host/ufs-mediatek.h | 17 +-
include/linux/soc/mediatek/mtk_sip_svc.h | 3 +
7 files changed, 655 insertions(+), 607 deletions(-)
---
base-commit: 4af4e95edc37ae54f64cbd75b46f16ce15f3a6b8
change-id: 20251014-mt8196-ufs-cec4b9a97e53
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v6 01/24] dt-bindings: phy: Add mediatek,mt8196-ufsphy variant
From: Nicolas Frattaroli @ 2026-01-24 12:00 UTC (permalink / raw)
To: Alim Akhtar, Avri Altman, Bart Van Assche, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chunfeng Yun, Vinod Koul,
Kishon Vijay Abraham I, Peter Wang, Stanley Jhu,
James E.J. Bottomley, Martin K. Petersen, Philipp Zabel,
Liam Girdwood, Mark Brown, Chaotian Jing, Neil Armstrong
Cc: Louis-Alexis Eyraud, kernel, linux-scsi, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-phy, Nicolas Frattaroli,
Conor Dooley
In-Reply-To: <20260124-mt8196-ufs-v6-0-e7c005b60028@collabora.com>
The MediaTek MT8196 SoC includes an M-PHY compatible with the already
existing mt8183 binding.
However, one omission from the original binding was that all of these
variants may have an optional reset.
Add the new compatible, and also the resets property, with an example.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
.../devicetree/bindings/phy/mediatek,ufs-phy.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
index 6e2edd43fc2a..ee71dfa4e0c0 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
@@ -27,6 +27,7 @@ properties:
- items:
- enum:
- mediatek,mt8195-ufsphy
+ - mediatek,mt8196-ufsphy
- const: mediatek,mt8183-ufsphy
- const: mediatek,mt8183-ufsphy
@@ -43,6 +44,10 @@ properties:
- const: unipro
- const: mp
+ resets:
+ items:
+ - description: Optional UFS M-PHY reset.
+
"#phy-cells":
const: 0
@@ -66,5 +71,16 @@ examples:
clock-names = "unipro", "mp";
#phy-cells = <0>;
};
+ - |
+ #include <dt-bindings/reset/mediatek,mt8196-resets.h>
+ ufs-phy@16800000 {
+ compatible = "mediatek,mt8196-ufsphy", "mediatek,mt8183-ufsphy";
+ reg = <0x16800000 0x10000>;
+ clocks = <&ufs_ao_clk 3>,
+ <&ufs_ao_clk 5>;
+ clock-names = "unipro", "mp";
+ resets = <&ufs_ao_clk MT8196_UFSAO_RST0_UFS_MPHY>;
+ #phy-cells = <0>;
+ };
...
--
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 next] phy: google: fix build dependency for Google Tensor USB PHY
From: André Draszik @ 2026-01-24 6:52 UTC (permalink / raw)
To: Roy Luo
Cc: Vinod Koul, Neil Armstrong, Peter Griffin, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar, linux-phy, linux-kernel,
linux-arm-kernel, linux-samsung-soc, kernel test robot
In-Reply-To: <CA+zupgwEWM4c9yK1f-Y_Cv5gk=0zYNuUb3kZyZ6O3FDRbPPvKw@mail.gmail.com>
Hi Roy,
On Fri, 2026-01-23 at 15:51 -0800, Roy Luo wrote:
> On Thu, Jan 22, 2026 at 10:28 PM André Draszik <andre.draszik@linaro.org> wrote:
> >
> >
> > COMPILE_TEST is not limited to ARCH_xxx. It allows drivers to be
> > compile tested even if the current build doesn't enable whatever
> > option (like TYPEC).
> >
> > See also https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#compile-testing
>
> "If a config symbol has a dependency, but the code controlled by the
> config symbol can still be compiled if the dependency is not met",
> TYPEC doesn't fall into this category as it's mandatory for compiling
> PHY_GOOGLE_USB.
> With "depends on TYPEC || COMPILE_TEST", this very build error
> would resurface when TYPEC=n, COMPILE_TEST=y and
> PHY_GOOGLE_USB=y. Please let me know if I missed anything.
No it wouldn't. If you look at the build log & .config from the reported
failure, the error was because:
CONFIG_PHY_GOOGLE_USB=y
CONFIG_TYPEC=m
built-in code can not link against code from a module.
The typec APIs are all stubbed out when TYPEC=n.
Cheers,
Andre'
>
> Thanks,
> Roy
>
> >
> > Cheers,
> > Andre'
> >
> >
> > >
> > > [1] https://lore.kernel.org/all/CA+zupgwgfKwPYqj8G2tNf4pEXNEWA+vL2WYJPhJ16xExgko7Dw@mail.gmail.com/
> > >
> > > Regards,
> > > Roy
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-24 0:59 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Maxime Chevallier,
Maxime Coquelin, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <E1vjDrM-00000005fQR-0rmB@rmk-PC.armlinux.org.uk>
On Fri, Jan 23, 2026 at 09:53:44AM +0000, Russell King (Oracle) wrote:
> Rather than having platform glue implement SerDes PHY support, add it
> to the core driver, specifically to the stmmac integrated PCS driver
> as the SerDes is connected to the integrated PCS.
>
> Platforms using external PCS can also populate plat->serdes, and the
> core driver will call phy_init() and phy_exit() when the administrative
> state of the interface changes, but the other phy methods will not be
> called.
>
> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> --
> rfc->v1: avoid calling phy_get_mode() with NULL serdes PHY
> v2: add cleanup when dwmac_serdes_set_mode() fails, because AI allegedly
> knows better than the author and phylink maintainer, even though this
> will result in dwmac_serdes_power_off() being called multiple times
> and producing a kernel warning. But if it makes AI happy, then it must
> be a good thing. It'll also make Vladimir happy.
These gratuitous passive-aggressive comments about what makes me happy,
based on twisted interpretations of conversations, are best kept to yourself.
I remember Jakub's request was only to add a note in the commit message
about the reason behind the lack of cleanup, not to add cleanup which
will be executed twice:
https://lore.kernel.org/netdev/20260120153248.0636f1e9@kernel.org/
I only expressed dissatisfaction with the phylink_pcs calling convention
as it is today, and searched for ways to make the calls balanced. I also
didn't make any suggestion to make the code worse by performing the
SerDes power down twice, just subscribed to Jakub's request to leave a
comment why your v1 is the way that it is:
https://lore.kernel.org/netdev/20260122112913.svzaie4eywk5nc32@skbuf/
Getting over that dissatisfaction and working within the framework of
the existing calling convention, but also inserting the comment that I
was looking to see, I believe that functionally correct code would look
like this (applies on top of your entire v2 patch set):
-- >8 --
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
index d46a071bc383..c4465dca6b93 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
@@ -59,12 +59,27 @@ int dwmac_serdes_power_on(struct stmmac_priv *priv)
{
int ret;
+ /* Because the dwmac_integrated_pcs_disable() call path is eventually
+ * invoked irrespective of the dwmac_integrated_pcs_enable() return
+ * code, we risk either underflowing the SerDes phy->power_count or
+ * leaving the lane powered on, depending on the cleanup choice and the
+ * point of failure. Keeping separate track of the lane power on state
+ * is a band aid until phylink offers balanced pcs_enable() and
+ * pcs_disable() calls.
+ */
+ if (priv->plat->serdes_powered_on)
+ return 0;
+
ret = phy_power_on(priv->plat->serdes);
- if (ret)
+ if (ret) {
dev_err(priv->device, "failed to power on SerDes: %pe\n",
ERR_PTR(ret));
+ return ret;
+ }
- return ret;
+ priv->plat->serdes_powered_on = true;
+
+ return 0;
}
int dwmac_serdes_init_mode(struct stmmac_priv *priv, phy_interface_t interface)
@@ -95,10 +110,17 @@ void dwmac_serdes_power_off(struct stmmac_priv *priv)
{
int ret;
+ if (!priv->plat->serdes_powered_on)
+ return;
+
ret = phy_power_off(priv->plat->serdes);
- if (ret)
+ if (ret) {
dev_err(priv->device, "failed to power off SerDes: %pe\n",
ERR_PTR(ret));
+ return;
+ }
+
+ priv->plat->serdes_powered_on = false;
}
void dwmac_serdes_exit(struct stmmac_priv *priv)
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 6097f4b6dd12..e62bba38ab60 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -225,6 +225,7 @@ struct plat_stmmacenet_data {
*/
phy_interface_t phy_interface;
struct phy *serdes;
+ bool serdes_powered_on;
struct stmmac_mdio_bus_data *mdio_bus_data;
struct device_node *phy_node;
struct fwnode_handle *port_node;
-- >8 --
--
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 v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Russell King (Oracle) @ 2026-01-24 0:16 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Konrad Dybcio, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <20260124000409.36nsxlvkde4zpddk@skbuf>
On Sat, Jan 24, 2026 at 02:04:09AM +0200, Vladimir Oltean wrote:
> On Fri, Jan 23, 2026 at 11:13:26AM +0000, Russell King (Oracle) wrote:
> > According to patchwork, this doesn't apply to net-next. That's odd,
> > it was generated on last night's net next, and although there has been
> > further work, it rebases cleanly on top of this morning's. How can
> > these changes:
> >
> > drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 6 +++++-
> > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++----
> > 2 files changed, 21 insertions(+), 5 deletions(-)
> >
> > which happened in net-next overnight result in this change in patch 1:
> >
> > drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > failing to apply?
> >
> > No, patchwork is clearly wrong.
>
> Conflicts with commit dc6597fab3e3 ("net: stmmac: dwmac-imx: keep
> preamble before sfd on i.MX8MP"), merged in the meantime.
>
> In include/linux/stmmac.h (your commit "net: stmmac: add stmmac core
> serdes support" adds a "struct phy;" line, but that other commit
> modifies the context by inserting:
>
> #define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(14)
>
> (the last stmmac flag in your context, at patch generation time, was:
> #define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
> )
I still maintain that this is silly - to mark all patches as such
and without any details about the problem applying the patches is
not helpful.
--
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 v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Vladimir Oltean @ 2026-01-24 0:04 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Konrad Dybcio, linux-arm-kernel,
linux-arm-msm, linux-phy, linux-stm32, Mohd Ayaan Anwar,
Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aXNX1oi7nWLcPK28@shell.armlinux.org.uk>
On Fri, Jan 23, 2026 at 11:13:26AM +0000, Russell King (Oracle) wrote:
> According to patchwork, this doesn't apply to net-next. That's odd,
> it was generated on last night's net next, and although there has been
> further work, it rebases cleanly on top of this morning's. How can
> these changes:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 6 +++++-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++----
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> which happened in net-next overnight result in this change in patch 1:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> failing to apply?
>
> No, patchwork is clearly wrong.
Conflicts with commit dc6597fab3e3 ("net: stmmac: dwmac-imx: keep
preamble before sfd on i.MX8MP"), merged in the meantime.
In include/linux/stmmac.h (your commit "net: stmmac: add stmmac core
serdes support" adds a "struct phy;" line, but that other commit
modifies the context by inserting:
#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(14)
(the last stmmac flag in your context, at patch generation time, was:
#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: Roy Luo @ 2026-01-23 23:51 UTC (permalink / raw)
To: André Draszik
Cc: Vinod Koul, Neil Armstrong, Peter Griffin, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar, linux-phy, linux-kernel,
linux-arm-kernel, linux-samsung-soc, kernel test robot
In-Reply-To: <f956ccd3f5f694de7a634819da3f790a8dce132b.camel@linaro.org>
On Thu, Jan 22, 2026 at 10:28 PM André Draszik <andre.draszik@linaro.org> wrote:
>
> Hi Roy,
>
> On Thu, 2026-01-22 at 11:00 -0800, Roy Luo wrote:
> > On Thu, Jan 22, 2026 at 2:39 AM André Draszik <andre.draszik@linaro.org> wrote:
> > >
> > > Hi Roy,
> > >
> > > On Wed, 2026-01-21 at 22:21 +0000, Roy Luo wrote:
> > > > The Google Tensor USB PHY driver uses the Type-C switch framework to
> > > > handle orientation changes. However, the Kconfig did not specify a
> > > > dependency on the TYPEC framework, leading to undefined reference
> > > > errors when building for architectures or configurations where
> > > > CONFIG_TYPEC is disabled or configured as a module.
> > > >
> > > > Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> > > > required symbols are available during linking.
> > > >
> > > > Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> > > > Signed-off-by: Roy Luo <royluo@google.com>
> > > > ---
> > > > drivers/phy/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > > > index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> > > > --- a/drivers/phy/Kconfig
> > > > +++ b/drivers/phy/Kconfig
> > > > @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
> > > >
> > > > config PHY_GOOGLE_USB
> > > > tristate "Google Tensor SoC USB PHY driver"
> > > > + depends on TYPEC
> > >
> > > Can you make this
> > >
> > > depends on TYPEC || COMPILE_TEST
> > >
> > > to allow some better test coverage?
> > >
> > > Cheers,
> > > Andre
> >
> > Hi Andre,
> >
> > Whether to add COMPILE_TEST for build coverage was discussed in
> > another thread [1]. My takeaway from that discussion is that
> > COMPILE_TEST is intended to substitute for ARCH_XXX in build
> > testing and should not be used without it. Once ARCH_GOOGLE is
> > present, we can add "depends on (ARCH_GOOGLE || COMPILTE_TEST)".
>
> COMPILE_TEST is not limited to ARCH_xxx. It allows drivers to be
> compile tested even if the current build doesn't enable whatever
> option (like TYPEC).
>
> See also https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#compile-testing
"If a config symbol has a dependency, but the code controlled by the
config symbol can still be compiled if the dependency is not met",
TYPEC doesn't fall into this category as it's mandatory for compiling
PHY_GOOGLE_USB.
With "depends on TYPEC || COMPILE_TEST", this very build error
would resurface when TYPEC=n, COMPILE_TEST=y and
PHY_GOOGLE_USB=y. Please let me know if I missed anything.
Thanks,
Roy
>
> Cheers,
> Andre'
>
>
> >
> > [1] https://lore.kernel.org/all/CA+zupgwgfKwPYqj8G2tNf4pEXNEWA+vL2WYJPhJ16xExgko7Dw@mail.gmail.com/
> >
> > Regards,
> > Roy
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Russell King (Oracle) @ 2026-01-23 21:32 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Konrad Dybcio,
linux-arm-kernel, linux-arm-msm, linux-phy, linux-stm32,
Maxime Coquelin, Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aXN5BFXMshnhwBQ7@oss.qualcomm.com>
On Fri, Jan 23, 2026 at 07:05:00PM +0530, Mohd Ayaan Anwar wrote:
> 4. Switching from 1G to 2.5G - similar issues + a NULL pointer
> dereference. I am checking on the reason for it.
For the NULL pointer dereference, this is a bit weird, and may help to
point towards the issue.
> [ 1235.996004] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> [ 1240.517716] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
> [ 1240.529470] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
> [ 1240.537642] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
> [ 1240.546702] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
> [ 1240.555441] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
> [ 1240.880168] Code: d63f0020 f9400e60 b4000040 f900081f (f9000ad3)
This code line disassembles to:
0: d63f0020 blr x1
4: f9400e60 ldr x0, [x19, #24]
8: b4000040 cbz x0, 10 <.text+0x10>
c: f900081f str xzr, [x0, #16]
10: f9000ad3 str x19, [x22, #16]
which, after comparing with my disassembly, the blr x1 is the call to
pcs_disable() inside phylink_pcs_disable() in this code:
if (pcs_changed) {
phylink_pcs_disable(pl->pcs);
if (pl->pcs)
pl->pcs->phylink = NULL;
pcs->phylink = pl;
and the failing store is the one for that last line of C code - in
other words, pcs = NULL.
This means that mac_select_pcs() returned NULL when being asked
"which PCS should be used for 2500base-X" ?
This suggests that the SerDes detection of support for 2500BASE-X
isn't working, meaning that stmmac_mac_select_pcs() ends up returning
NULL, rather than &priv->integrated_pcs->pcs.
That would only happen if:
/* Only allow 2500Base-X if the SerDes has support. */
ret = dwmac_serdes_validate(priv, PHY_INTERFACE_MODE_2500BASEX);
if (ret == 0)
__set_bit(PHY_INTERFACE_MODE_2500BASEX,
spcs->pcs.supported_interfaces);
fails, meaning we don't set that interface mode for the PCS.
dwmac_serdes_validate() calls phy_validate() for PHY_MODE_ETHERNET
with the PHY interface mode as the sub mode.
Patch 3 adds the required methods to phy-qcom-sgmii-eth.c to allow
phy_validate() to indicate whether this is supported or not:
.validate = qcom_dwmac_sgmii_phy_validate,
and its implementation is:
int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
return ret < 0 ? ret : 0;
where qcom_dwmac_sgmii_phy_speed() is:
if (mode != PHY_MODE_ETHERNET)
return -EINVAL;
if (submode == PHY_INTERFACE_MODE_SGMII ||
submode == PHY_INTERFACE_MODE_1000BASEX)
return SPEED_1000;
if (submode == PHY_INTERFACE_MODE_2500BASEX)
return SPEED_2500;
return -EINVAL;
So, this should be returning a positive integer (SPEED_2500), which
should cause phy_validate(serdes, PHY_MODE_ETHERNET,
PHY_INTERFACE_MODE_2500BASEX, NULL) to return success (zero). That
should result in PHY_INTERFACE_MODE_2500BASEX being set in
spcs->pcs.supported_interfaces, and thus &priv->integrated_pcs->pcs
being returned for PHY_INTERFACE_MODE_2500BASEX.
Is the particular hardware you're running this oopsing test on not
using a SerDes PHY? If that's the case, how does it switch between
2.5Gbps and 1Gbps data rate on the SerDes?
--
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 v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Russell King (Oracle) @ 2026-01-23 17:26 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Konrad Dybcio,
linux-arm-kernel, linux-arm-msm, linux-phy, linux-stm32,
Maxime Coquelin, Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aXN5BFXMshnhwBQ7@oss.qualcomm.com>
On Fri, Jan 23, 2026 at 07:05:00PM +0530, Mohd Ayaan Anwar wrote:
> Hello Russell,
> On Fri, Jan 23, 2026 at 09:52:00AM +0000, Russell King (Oracle) wrote:
> > This is the v1 submission: if it doesn't get tested but review goes
> > well, it'll end up in net-next and mainline without testing on the
> > affected hardware!
> >
> > Mentioned previously, I've been trying to sort out the PCS support in
> > stmmac, and this series represents the current state of play.
> >
> > Previous posted patches centred around merely getting autonegotiation
> > to be configured correctly, to a point where the manual configuration
> > can be removed from the qcom-ethqos driver. The qcom-ethqos driver
> > uses both SGMII and 2500BASE-X, manually configuring the dwmac's
> > integrated PCS appropriately.
> >
>
> Thank you for CC'ing me on this series. Sorry, but I have been M.I.A.
> for the past couple of months due to some health issues, which caused a
> backlog at work that I had to power through. I haven't been able to
> monitor the mailing list for stmmac patches.
Sorry to hear that, but if it's any consolation, you're not alone. On
new year's eve, I had three teeth extracted, including one that was
laying horizontally in the palate of the mouth buried in bone, and
needed in bone graft (modern bone grafts are quite different from what
you'd expect btw.) It's been quite sore/painful as it heals.
> I tested v1 last night and just picked up v2. Here are my observations
> and logs (phylink logs are enabled). I haven't had time to debug the
> issues, but they are not seen on the net-next tree. One thing that I
> remember from our last discussion is the need to test with comma
> detection enabled; I will test that next.
>
> Tested on the QCS9100 Ride R3 board with 2X AQR115C PHYs. I have one
> more board that I can test next week (IQ8275, which has a single
> QCA8081 PHY, but that is limited to 2.5G because the PHY switches its
> mode according to the speed).
Thanks for testing!
Given the results you've given, my suggestion would be that the
following patches are probably the most risky:
Patch 2 "net: stmmac: qcom-ethqos: convert to set_clk_tx_rate() method"
This changes the way the clock is configured. It would be worth
testing that and giving a tested-by for the first two patches if
that's successful.
Patch 6 "net: stmmac: qcom-ethqos: convert to dwmac generic SerDes
support"
This changes how the SerDes is handled, which is a significant change.
It's possible that the PHY calibration needs some other state to be
appropriately configured, and that's not happening in the same order.
Either of these two would account for what appears to be an unstable
SerDes link.
As for the NULL pointer deref, I'll look at that in a bit (waiting
for a build to complete so I can hopefully pinpoint where the oops
is happening.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v4 3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260123-ti-phy-v4-0-b557e2c46e6f@gmail.com>
Convert TI OMAP Control PHY binding to DT schema.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../bindings/phy/ti,control-phy-otghs.yaml | 99 ++++++++++++++++++++++
Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------------
2 files changed, 99 insertions(+), 98 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
new file mode 100644
index 000000000000..4ecb1611ee65
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,control-phy-otghs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI OMAP Control PHY Module
+
+maintainers:
+ - Roger Quadros <rogerq@ti.com>
+
+description:
+ The TI OMAP Control PHY module is a hardware block within the system
+ control module (SCM) of Texas Instruments OMAP SoCs. It provides
+ centralized control over power, configuration, and auxiliary features
+ for multiple on-chip PHYs. This module is essential for proper PHY
+ operation in power-constrained embedded systems.
+
+properties:
+ $nodename:
+ pattern: "^phy@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,control-phy-otghs
+ - ti,control-phy-pcie
+ - ti,control-phy-pipe3
+ - ti,control-phy-usb2
+ - ti,control-phy-usb2-am437
+ - ti,control-phy-usb2-dra7
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [otghs_control, power, pcie_pcs, control_sma]
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,control-phy-otghs
+ then:
+ properties:
+ reg-names:
+ const: otghs_control
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,control-phy-pcie
+ then:
+ properties:
+ reg:
+ minItems: 3
+
+ reg-names:
+ items:
+ - const: power
+ - const: pcie_pcs
+ - const: control_sma
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,control-phy-usb2
+ - ti,control-phy-usb2-dra7
+ - ti,control-phy-usb2-am437
+ - ti,control-phy-pipe3
+ then:
+ properties:
+ reg-names:
+ const: power
+
+required:
+ - reg
+ - compatible
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ phy@4a00233c {
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
deleted file mode 100644
index 7c7936b89f2c..000000000000
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
-
-OMAP CONTROL PHY
-
-Required properties:
- - compatible: Should be one of
- "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
- "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
- e.g. USB2_PHY on OMAP5.
- "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
- e.g. USB3 PHY and SATA PHY on OMAP5.
- "ti,control-phy-pcie" - for pcie to support external clock for pcie and to
- set PCS delay value.
- e.g. PCIE PHY in DRA7x
- "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on
- DRA7 platform.
- "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on
- AM437 platform.
- - reg : register ranges as listed in the reg-names property
- - reg-names: "otghs_control" for control-phy-otghs
- "power", "pcie_pcs" and "control_sma" for control-phy-pcie
- "power" for all other types
-
-omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,control-phy-otghs";
- reg = <0x4a00233c 0x4>;
- reg-names = "otghs_control";
-};
-
-TI PIPE3 PHY
-
-Required properties:
- - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or
- "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated.
- - reg : Address and length of the register set for the device.
- - reg-names: The names of the register addresses corresponding to the registers
- filled in "reg".
- - #phy-cells: determine the number of cells that should be given in the
- phandle while referencing this phy.
- - clocks: a list of phandles and clock-specifier pairs, one for each entry in
- clock-names.
- - clock-names: should include:
- * "wkupclk" - wakeup clock.
- * "sysclk" - system clock.
- * "refclk" - reference clock.
- * "dpll_ref" - external dpll ref clk
- * "dpll_ref_m2" - external dpll ref clk
- * "phy-div" - divider for apll
- * "div-clk" - apll clock
-
-Optional properties:
- - id: If there are multiple instance of the same type, in order to
- differentiate between each instance "id" can be used (e.g., multi-lane PCIe
- PHY). If "id" is not provided, it is set to default value of '1'.
- - syscon-pllreset: Handle to system control region that contains the
- CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
- register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
- - syscon-pcs : phandle/offset pair. Phandle to the system control module and the
- register offset to write the PCS delay value.
-
-Deprecated properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
- the PHY.
-
-Recommended properties:
- - syscon-phy-power : phandle/offset pair. Phandle to the system control
- module and the register offset to power on/off the PHY.
-
-This is usually a subnode of ocp2scp to which it is connected.
-
-usb3phy@4a084400 {
- compatible = "ti,phy-usb3";
- reg = <0x4a084400 0x80>,
- <0x4a084800 0x64>,
- <0x4a084c00 0x40>;
- reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_usb>;
- #phy-cells = <0>;
- clocks = <&usb_phy_cm_clk32k>,
- <&sys_clkin>,
- <&usb_otg_ss_refclk960m>;
- clock-names = "wkupclk",
- "sysclk",
- "refclk";
-};
-
-sata_phy: phy@4a096000 {
- compatible = "ti,phy-pipe3-sata";
- reg = <0x4A096000 0x80>, /* phy_rx */
- <0x4A096400 0x64>, /* phy_tx */
- <0x4A096800 0x40>; /* pll_ctrl */
- reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_sata>;
- clocks = <&sys_clkin1>, <&sata_ref_clk>;
- clock-names = "sysclk", "refclk";
- syscon-pllreset = <&scm_conf 0x3fc>;
- #phy-cells = <0>;
-};
--
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 v4 2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260123-ti-phy-v4-0-b557e2c46e6f@gmail.com>
Convert TI PIPE3 PHY binding to DT schema.
Changes during conversion:
- Define a new pattern 'pcie-phy' to match nodes defined in DT.
- Drop obsolete "id" property from the schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../devicetree/bindings/phy/ti,phy-usb3.yaml | 138 +++++++++++++++++++++
1 file changed, 138 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
new file mode 100644
index 000000000000..84f538aa587c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,phy-usb3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI PIPE3 PHY Module
+
+maintainers:
+ - Roger Quadros <rogerq@ti.com>
+
+description:
+ The TI PIPE3 PHY is a high-speed SerDes (Serializer/Deserializer)
+ transceiver integrated in OMAP5, DRA7xx/AM57xx, and similar SoCs.
+ It supports multiple protocols (USB3, SATA, PCIe) using the PIPE3
+ interface standard, which defines a common physical layer for
+ high-speed serial interfaces.
+
+properties:
+ $nodename:
+ pattern: "^(pcie-phy|usb3-phy|phy)@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,omap-usb3
+ - ti,phy-pipe3-pcie
+ - ti,phy-pipe3-sata
+ - ti,phy-usb3
+
+ reg:
+ minItems: 2
+ maxItems: 3
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: phy_rx
+ - const: phy_tx
+ - const: pll_ctrl
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ minItems: 2
+ maxItems: 7
+
+ clock-names:
+ minItems: 2
+ maxItems: 7
+ items:
+ enum: [wkupclk, sysclk, refclk, dpll_ref,
+ dpll_ref_m2, phy-div, div-clk]
+
+ syscon-phy-power:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset controlling PHY power
+
+ syscon-pllreset:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset of CTRL_CORE_SMA_SW_0
+
+ syscon-pcs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset for PCS delay programming
+
+ ctrl-module:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle of control module for PHY power on.
+ deprecated: true
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,phy-pipe3-sata
+ then:
+ properties:
+ syscon-pllreset: true
+ else:
+ properties:
+ syscon-pllreset: false
+
+required:
+ - reg
+ - compatible
+ - reg-names
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* TI PIPE3 USB3 PHY */
+ usb3-phy@4a084400 {
+ compatible = "ti,phy-usb3";
+ reg = <0x4a084400 0x80>,
+ <0x4a084800 0x64>,
+ <0x4a084c00 0x40>;
+ reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+ #phy-cells = <0>;
+ clocks = <&usb_phy_cm_clk32k>,
+ <&sys_clkin>,
+ <&usb_otg_ss_refclk960m>;
+ clock-names = "wkupclk", "sysclk", "refclk";
+ ctrl-module = <&omap_control_usb>;
+ };
+
+ - |
+ /* TI PIPE3 SATA PHY */
+ phy@4a096000 {
+ compatible = "ti,phy-pipe3-sata";
+ reg = <0x4a096000 0x80>, /* phy_rx */
+ <0x4a096400 0x64>, /* phy_tx */
+ <0x4a096800 0x40>; /* pll_ctrl */
+ reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+ clocks = <&sys_clkin1>, <&sata_ref_clk>;
+ clock-names = "sysclk", "refclk";
+ syscon-pllreset = <&scm_conf 0x3fc>;
+ #phy-cells = <0>;
+ };
+...
--
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 v4 1/3] arm: dts: ti: omap: align node patterns with established convention
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260123-ti-phy-v4-0-b557e2c46e6f@gmail.com>
Update OMAP DTS node patterns to match established conventions.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 ++--
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 ++--
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index c9282f57ffa5..ed206eb84d02 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -328,7 +328,7 @@ ocp2scp@0 {
ranges = <0 0 0x8000>;
reg = <0x0 0x20>;
- pcie1_phy: pciephy@4000 {
+ pcie1_phy: pcie-phy@4000 {
compatible = "ti,phy-pipe3-pcie";
reg = <0x4000 0x80>, /* phy_rx */
<0x4400 0x64>; /* phy_tx */
@@ -348,7 +348,7 @@ pcie1_phy: pciephy@4000 {
#phy-cells = <0>;
};
- pcie2_phy: pciephy@5000 {
+ pcie2_phy: pcie-phy@5000 {
compatible = "ti,phy-pipe3-pcie";
reg = <0x5000 0x80>, /* phy_rx */
<0x5400 0x64>; /* phy_tx */
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 4ee53dfb71b4..d8b16cbe6c35 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -72,13 +72,13 @@ scm_conf: scm_conf@0 {
#size-cells = <1>;
};
- omap_control_usb2phy: control-phy@300 {
+ omap_control_usb2phy: phy@300 {
compatible = "ti,control-phy-usb2";
reg = <0x300 0x4>;
reg-names = "power";
};
- omap_control_usbotg: control-phy@33c {
+ omap_control_usbotg: phy@33c {
compatible = "ti,control-phy-otghs";
reg = <0x33c 0x4>;
reg-names = "otghs_control";
diff --git a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
index 9f6100c7c34d..5c94db589dd1 100644
--- a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
@@ -472,7 +472,7 @@ usb2_phy: usb2phy@4000 {
#phy-cells = <0>;
};
- usb3_phy: usb3phy@4400 {
+ usb3_phy: usb3-phy@4400 {
compatible = "ti,omap-usb3";
reg = <0x4400 0x80>,
<0x4800 0x64>,
--
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 v4 0/3] dt-bindings: phy: Convert TI OMAP control and PIPE3 PHY to DT schema
From: Charan Pedumuru @ 2026-01-23 15:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
This series converts the old text-based DeviceTree bindings for TI OMAP
Control PHY and TI PIPE3 PHY to modern JSON-schema (YAML) format.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v4:
- ti,phy-usb3: Limit phandle arrays for optional properties to one entry.
- ti,phy-usb3: Use lowercase hex for reg values in examples.
- Link to v3: https://lore.kernel.org/r/20260122-ti-phy-v3-0-751619729433@gmail.com
Changes in v3:
- Change maintainer to "Roger Quadros" for both YAML files.
- dts: Split node pattern updates into a separate patch and align node
naming with standard conventions.
- ti,phy-usb3: Update node pattern to follow standard conventions.
- ti,phy-usb3: Refine the reg-names property and add constraints for
optional phandle-array properties.
- ti,phy-usb3: Redefine "syscon-pllreset" dependency on the compatible
"ti,phy-pipe3-sata" in a correct format.
- ti,control-phy-otghs: Update node pattern and adjust maxItems for reg
and reg-names.
- ti,control-phy-otghs: Fix the conditional handling for the
ti,control-phy-pcie compatible.
- Link to v2: https://lore.kernel.org/r/20260107-ti-phy-v2-0-a1ec27401fff@gmail.com
Changes in v2:
- ti,control-phy-otghs: Update commit message to reflect the latest
binding changes.
- ti,phy-usb3: Drop the obsolete "id" property from the schema.
- Both bindings: Update maintainers list, modify node pattern and improve
node descriptions for clarity.
- ti,phy-usb3: Introduce new YAML schema with properly defined optional
properties for the PIPE3 PHY.
- Link to v1: https://lore.kernel.org/r/20260103-ti-phy-v1-1-8c3f5e2cbd63@gmail.com
---
Charan Pedumuru (3):
arm: dts: ti: omap: align node patterns with established convention
dt-bindings: phy: ti,phy-usb3: convert to DT schema
dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
.../bindings/phy/ti,control-phy-otghs.yaml | 99 +++++++++++++++
.../devicetree/bindings/phy/ti,phy-usb3.yaml | 138 +++++++++++++++++++++
Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
6 files changed, 242 insertions(+), 103 deletions(-)
---
base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8
change-id: 20251231-ti-phy-58bb9e38cfc9
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 8/9] arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generator
From: Marek Vasut @ 2026-01-23 15:02 UTC (permalink / raw)
To: Geert Uytterhoeven
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: <CAMuHMdV7UPWCqj4A6097KKT+Es2Zz_mPeJoyJd5qDMudrNx_5A@mail.gmail.com>
On 1/23/26 2:37 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> Thanks for your patch!
>
> On Sun, 18 Jan 2026 at 14:51, Marek Vasut
> <marek.vasut+renesas@mailbox.org> wrote:
>> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on ULCB
>> board. The clock generator supplies 100 MHz differential clock for both
>> PCIe ports, the USB 3.0 PHY and SATA.
>>
>> SATA is not yet described in the ULCB DT, therefore the connection to
>> this clock generator is not described here either.
>>
>> The H3 ULCB schematic does describe connection from output DIF7 to
>> USB3S1_CLK_*, but these signals do not exist on the SoC, therefore
>> this connection is also not described.
>
> That is the case because the first ULCB came with R-Car H3 ES1.0,
> which did have two USB3 channels. R-Car H3 ES2.0, M3-W, M3-W+,
> and M3-N have only a single USB3 channel.
>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-devel for v6.21.
Thank you
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-23 13:39 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: <20260118135038.8033-10-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on Ebisu
> board. The clock generator supplies 100 MHz differential clock for both
> PCIe slot and BT/WLAN expansion port, as well as for the USB 3.0 PHY.
>
> This configuration is valid for SW49 in OFF position, which means the
> PCIe signals are routed to the PCIe slot and U11 9FGV0841 PCIe clock
> generator output 3 supplies clock to the PCIe slot.
>
> In case the SW49 is set to ON position, which means the PCIe signals
> are routed to the EX BT/WLAN expansion port, and U11 9FGV0841 PCIe
> clock generator output 4 supplies clock to the port and &pciec0_rp
> clocks should be changed to "clocks = <&pcie_usb_clk 4>;". Once the
> BT/WLAN port is tested, this can be implemented using a DTO. Until
> then, assume SW49 is set to OFF position.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
> --- a/arch/arm64/boot/dts/renesas/ebisu.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ebisu.dtsi
> @@ -578,12 +591,30 @@ &ohci0 {
>
> &pcie_bus_clk {
> clock-frequency = <100000000>;
I will drop the clock-frequency while applying, as there is no point
in changing it in a disabled node.
> + status = "disabled";
> };
> @@ -871,7 +902,19 @@ &usb2_phy0 {
> status = "okay";
> };
>
> +&usb3_phy0 {
> + clocks = <&pcie_usb_clk 6>;
> + status = "okay";
> +};
> +
> +&usb3s0_clk {
> + clock-frequency = <100000000>;
Likewise.
> + status = "disabled";
> +};
> +
> &usb3_peri0 {
> + phys = <&usb3_phy0>;
> + phy-names = "usb";
> companion = <&xhci0>;
> status = "okay";
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 8/9] arm64: dts: renesas: ulcb: ulcb-kf: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-23 13:37 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: <20260118135038.8033-9-marek.vasut+renesas@mailbox.org>
Hi Marek,
Thanks for your patch!
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on ULCB
> board. The clock generator supplies 100 MHz differential clock for both
> PCIe ports, the USB 3.0 PHY and SATA.
>
> SATA is not yet described in the ULCB DT, therefore the connection to
> this clock generator is not described here either.
>
> The H3 ULCB schematic does describe connection from output DIF7 to
> USB3S1_CLK_*, but these signals do not exist on the SoC, therefore
> this connection is also not described.
That is the case because the first ULCB came with R-Car H3 ES1.0,
which did have two USB3 channels. R-Car H3 ES2.0, M3-W, M3-W+,
and M3-N have only a single USB3 channel.
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
> --- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> @@ -352,19 +352,30 @@ &ohci0 {
>
> &pcie_bus_clk {
> clock-frequency = <100000000>;
I will drop the clock-frequency while applying, as there is no point
in changing it in a disabled node.
> + status = "disabled";
> };
>
> @@ -475,6 +486,16 @@ &usb2_phy0 {
> status = "okay";
> };
>
> +&usb3_phy0 {
> + clocks = <&cpg CPG_MOD 328>, <&pcie_usb_clk 6>, <&usb_extal_clk>;
> + status = "okay";
> +};
> +
> +&usb3s0_clk {
> + clock-frequency = <100000000>;
Likewise.
> + status = "disabled";
> +};
> +
> &xhci0 {
> status = "okay";
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies
From: Mohd Ayaan Anwar @ 2026-01-23 13:35 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Konrad Dybcio,
linux-arm-kernel, linux-arm-msm, linux-phy, linux-stm32,
Maxime Coquelin, Neil Armstrong, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <aXNEwBW3OA1xLEUj@shell.armlinux.org.uk>
Hello Russell,
On Fri, Jan 23, 2026 at 09:52:00AM +0000, Russell King (Oracle) wrote:
> This is the v1 submission: if it doesn't get tested but review goes
> well, it'll end up in net-next and mainline without testing on the
> affected hardware!
>
> Mentioned previously, I've been trying to sort out the PCS support in
> stmmac, and this series represents the current state of play.
>
> Previous posted patches centred around merely getting autonegotiation
> to be configured correctly, to a point where the manual configuration
> can be removed from the qcom-ethqos driver. The qcom-ethqos driver
> uses both SGMII and 2500BASE-X, manually configuring the dwmac's
> integrated PCS appropriately.
>
Thank you for CC'ing me on this series. Sorry, but I have been M.I.A.
for the past couple of months due to some health issues, which caused a
backlog at work that I had to power through. I haven't been able to
monitor the mailing list for stmmac patches.
I tested v1 last night and just picked up v2. Here are my observations
and logs (phylink logs are enabled). I haven't had time to debug the
issues, but they are not seen on the net-next tree. One thing that I
remember from our last discussion is the need to test with comma
detection enabled; I will test that next.
Tested on the QCS9100 Ride R3 board with 2X AQR115C PHYs. I have one
more board that I can test next week (IQ8275, which has a single
QCA8081 PHY, but that is limited to 2.5G because the PHY switches its
mode according to the speed).
1. Boot up at 2.5G: Continous TX timeouts keep issuing a reset,
resulting in a broken data path.
[ 7.492567] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[ 7.492576] qcom-ethqos 23040000.ethernet: DWMAC4/5
[ 7.492601] qcom-ethqos 23040000.ethernet: Using 36/40 bits DMA host/device width
[ 9.556835] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 9.566440] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 9.577175] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 9.586679] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 9.615015] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 9.622371] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 9.631155] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 9.637701] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 9.646026] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 9.654175] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 9.663212] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 9.671797] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 9.695529] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 14.219898] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 14.231487] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
[ 26.308402] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 3 timed out 5512 ms
[ 26.319068] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
[ 26.328258] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 26.885477] qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[ 26.893552] qcom-ethqos 23040000.ethernet eth1: failed to kill vid 0081/0
[ 26.900711] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 26.908972] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 26.917145] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 26.925232] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 27.836839] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 27.846435] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 27.857175] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 27.866659] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 27.892561] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 27.899700] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 27.908831] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 27.915373] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 27.923697] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 27.931850] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 27.940894] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 27.949481] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 27.965702] 8021q: adding VLAN 0 to HW filter on device eth1
[ 27.971735] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 32.552893] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 32.564571] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
[ 44.292394] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 2 timed out 5548 ms
[ 44.293874] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
[ 44.295010] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 44.846480] qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[ 44.846503] qcom-ethqos 23040000.ethernet eth1: failed to kill vid 0081/0
[ 44.846652] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 44.847116] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 44.847529] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 44.847965] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 45.752841] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 45.752865] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 45.752875] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 45.752881] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 45.764640] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 45.764958] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 45.765223] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 45.765228] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 45.765232] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 45.765236] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 45.765240] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 45.765243] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 45.775210] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 45.776826] 8021q: adding VLAN 0 to HW filter on device eth1
[ 50.455049] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 50.457389] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
2. Boot up at 1G: link state is flapping + the same TX timeout issue as
above. Also, a warning due to qcom-ethqos toggling ANE. For the link
state flapping issue, the MAC/IOMACRO configuration looks fine to me, do
we need to handle something in the PHY?
<Console gets flooded due to the flapping of the link state>
[ 34.444213] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 34.444229] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 34.444257] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 34.444262] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 34.444818] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 34.444832] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 34.444862] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 34.444867] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 34.445124] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041000
[ 34.445154] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 34.445426] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 34.445439] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 34.445480] qcom-ethqos 23040000.ethernet eth1: Link is Down
[ 34.445509] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 34.449951] qcom-ethqos 23040000.ethernet: PCS ANE process completed
[ 34.449957] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 34.449966] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 40.476697] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 2 timed out 5004 ms
[ 40.477296] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
[ 40.479898] qcom-ethqos 23040000.ethernet eth1: phy link down sgmii/Unknown/Unknown/none/off/nolpi
[ 40.517655] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 40.518174] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 40.518623] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 40.518986] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 41.405148] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 41.405175] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 41.405185] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=340)
[ 41.405192] qcom-ethqos 23040000.ethernet eth1: phy: sgmii setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 41.416920] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 41.417226] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 41.418826] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 41.418832] qcom-ethqos 23040000.ethernet eth1: configuring for phy/sgmii link mode
[ 41.418836] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/sgmii
[ 41.418842] qcom-ethqos 23040000.ethernet eth1: interface sgmii inband modes: pcs=03 phy=03
[ 41.418846] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/sgmii
[ 41.418849] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/sgmii/none adv=00000000,00000000,00000000,00000000 pause=00
[ 41.425947] 8021q: adding VLAN 0 to HW filter on device eth1
[ 41.432191] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 44.979659] qcom-ethqos 23040000.ethernet eth1: phy link up sgmii/1Gbps/Full/none/off/nolpi
[ 44.982047] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041000
[ 44.982092] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 45.019087] qcom-ethqos 23040000.ethernet: PCS ANE process completed
[ 45.019101] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 45.019120] qcom-ethqos 23040000.ethernet eth1: pcs link up
3. Switching from 2.5G to 1G: similar continuous Tx timeouts, warning
due to ANE.
[ 97.318077] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 97.877280] qcom-ethqos 23040000.ethernet eth1: Timeout accessing MAC_VLAN_Tag_Filter
[ 97.877309] qcom-ethqos 23040000.ethernet eth1: failed to kill vid 0081/0
[ 97.877507] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 97.878080] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 97.878530] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 97.879004] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 98.784839] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[ 98.784865] qcom-ethqos 23040000.ethernet eth1: interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[ 98.784876] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=333)
[ 98.784883] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 00000000,00000000,00008000,000062ff advertising 00000000,00000000,00008000,000062ff
[ 98.796612] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 98.796912] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 98.798518] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 98.798522] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[ 98.798526] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 98.798530] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 98.798534] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 98.798537] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=00000000,00000000,00000000,00000000 pause=00
[ 98.802000] 8021q: adding VLAN 0 to HW filter on device eth1
[ 98.808472] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 102.180528] qcom-ethqos 23040000.ethernet eth1: phy link up sgmii/1Gbps/Full/none/off/nolpi
[ 102.182972] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/sgmii
[ 102.182986] qcom-ethqos 23040000.ethernet eth1: interface sgmii inband modes: pcs=03 phy=03
[ 102.182994] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/sgmii
[ 102.183000] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/sgmii/none adv=00000000,00000000,00000000,00000000 pause=00
[ 102.186901] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.186913] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.186952] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 102.186955] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 102.187089] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.187092] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.187123] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 102.187126] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 102.187169] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041000
[ 102.187175] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.187178] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.187206] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 102.187213] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 102.187217] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 102.187218] qcom-ethqos 23040000.ethernet eth1: Link is Down
[ 102.187273] qcom-ethqos 23040000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 102.220947] qcom-ethqos 23040000.ethernet: PCS ANE process completed
[ 102.220958] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 102.220972] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 114.309051] qcom-ethqos 23040000.ethernet eth1: NETDEV WATCHDOG: CPU: 2: transmit queue 3 timed out 5588 ms
[ 114.309141] qcom-ethqos 23040000.ethernet eth1: Reset adapter.
4. Switching from 1G to 2.5G - similar issues + a NULL pointer
dereference. I am checking on the reason for it.
[ 1235.996004] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 1240.517716] qcom-ethqos 23040000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off/nolpi
[ 1240.529470] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[ 1240.537642] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=00 phy=00
[ 1240.546702] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[ 1240.555441] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
[ 1240.564481] Mem abort info:
[ 1240.567377] ESR = 0x0000000096000044
[ 1240.571242] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1240.576720] SET = 0, FnV = 0
[ 1240.579874] EA = 0, S1PTW = 0
[ 1240.583123] FSC = 0x04: level 0 translation fault
[ 1240.588162] Data abort info:
[ 1240.591149] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
[ 1240.596799] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 1240.602007] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1240.607483] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000137f96000
[ 1240.614107] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000
[ 1240.621093] Internal error: Oops: 0000000096000044 [#1] SMP
[ 1240.626910] Modules linked in: --
[ 1240.737142] CPU: 1 UID: 0 PID: 55 Comm: kworker/u33:0 Not tainted 6.19.0-rc5-00581-g73cb8467a63e #1 PREEMPT
[ 1240.747223] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
[ 1240.754461] Workqueue: events_power_efficient phylink_resolve
[ 1240.760368] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1240.767509] pc : phylink_major_config+0x408/0x948
[ 1240.772340] lr : phylink_major_config+0x3fc/0x948
[ 1240.777167] sp : ffff800080353c60
[ 1240.780568] x29: ffff800080353cb0 x28: ffffb305068a8a00 x27: ffffb305068a8000
[ 1240.787894] x26: ffff000080092100 x25: 0000000000000000 x24: 0000000000000000
[ 1240.795219] x23: 0000000000000001 x22: 0000000000000000 x21: ffffb3050555b3d0
[ 1240.802544] x20: ffff800080353d10 x19: ffff0000b6059400 x18: 00000000ffffffff
[ 1240.809870] x17: 74756f2f79687020 x16: ffffb305045e4f18 x15: 6769666e6f632072
[ 1240.817195] x14: 6f6a616d203a3168 x13: 782d657361623030 x12: ffffb305068c6a98
[ 1240.824521] x11: 0000000000000583 x10: 0000000000000018 x9 : ffffb305068c6a98
[ 1240.831849] x8 : 0000000100006583 x7 : 0000000000000000 x6 : ffff00008083cc40
[ 1240.839174] x5 : ffff00008083cc40 x4 : 0000000000000001 x3 : 0000000000000001
[ 1240.846498] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000b269e5a8
[ 1240.853824] Call trace:
[ 1240.856339] phylink_major_config+0x408/0x948 (P)
[ 1240.861167] phylink_resolve+0x294/0x6e4
[ 1240.865196] process_one_work+0x148/0x28c
[ 1240.869316] worker_thread+0x2d8/0x3d8
[ 1240.873171] kthread+0x134/0x208
[ 1240.876490] ret_from_fork+0x10/0x20
[ 1240.880168] Code: d63f0020 f9400e60 b4000040 f900081f (f9000ad3)
[ 1240.886423] ---[ end trace 0000000000000000 ]---
That's all I have right now. I will try to test out with comma detection
enabled and share the results in a day or so.
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 7/9] arm64: dts: renesas: salvator-common: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-23 13:34 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: <20260118135038.8033-8-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe the 9FGV0841 PCIe and USB3.0 clock generator present on both
> Salvator-X and Salvator-XS boards. The clock generator supplies 100 MHz
> differential clock for both PCIe ports, as well as for the USB 3.0 PHY.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -641,16 +654,27 @@ &ohci1 {
>
> &pcie_bus_clk {
> clock-frequency = <100000000>;
I will drop the clock-frequency while applying, as there is no point
in changing it in a disabled node.
> + status = "disabled";
> };
> @@ -1038,11 +1062,13 @@ &usb3_peri0 {
> };
>
> &usb3_phy0 {
> + clocks = <&cpg CPG_MOD 328>, <&pcie_usb_clk 6>, <&usb_extal_clk>;
> status = "okay";
> };
>
> &usb3s0_clk {
> clock-frequency = <100000000>;
Likewise.
> + status = "disabled";
> };
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 6/9] arm64: dts: renesas: r8a77990: Add USB 3.0 PHY and USB3S0 clock nodes
From: Geert Uytterhoeven @ 2026-01-23 13:32 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: <20260118135038.8033-7-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add USB 3.0 PHY and PHY clock node for R8877990 E3 . The PHY node is
> different in that it does not have control registers and extal clock,
> which are not routed to the SoC pads on E3, therefore describe the
> PHY as usb-nop-xceiv simple PHY. Add USB3S0 clock pad fixed-clock
> node, the frequency has to be overridden at board level.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: Describe PHY as usb-nop-xceiv and update commit message
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 5/9] arm64: dts: renesas: r8a77990: Describe PCIe root port
From: Geert Uytterhoeven @ 2026-01-23 13:31 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: <20260118135038.8033-6-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add node which describes the root port in the PCIe controller DT node.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 4/9] arm64: dts: renesas: r8a77965: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:31 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: <20260118135038.8033-5-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 3/9] arm64: dts: renesas: r8a77961: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:30 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: <20260118135038.8033-4-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 2/9] arm64: dts: renesas: r8a77960: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:29 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: <20260118135038.8033-3-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 1/9] arm64: dts: renesas: r8a77951: Describe PCIe root ports
From: Geert Uytterhoeven @ 2026-01-23 13:29 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: <20260118135038.8033-2-marek.vasut+renesas@mailbox.org>
On Sun, 18 Jan 2026 at 14:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add nodes which describe the root ports in the PCIe controller DT nodes.
> This can be used together with the pwrctrl driver to control clock and
> power supply to a PCIe slot.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v6.21.
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 v3 2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Charan Pedumuru @ 2026-01-23 13:12 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Kishon Vijay Abraham I, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Roger Quadros,
linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <20260122233309.GA3730160-robh@kernel.org>
On 23-01-2026 05:03, Rob Herring wrote:
> On Thu, Jan 22, 2026 at 05:52:58PM +0000, Charan Pedumuru wrote:
>> Convert TI PIPE3 PHY binding to DT schema.
>> Changes during conversion:
>> - Define a new pattern 'pcie-phy' to match nodes defined in DT.
>> - Drop obsolete "id" property from the schema.
>>
>> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
>> ---
>> .../devicetree/bindings/phy/ti,phy-usb3.yaml | 135 +++++++++++++++++++++
>> 1 file changed, 135 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
>> new file mode 100644
>> index 000000000000..605f12f0f79a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
>> @@ -0,0 +1,135 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/ti,phy-usb3.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI PIPE3 PHY Module
>> +
>> +maintainers:
>> + - Roger Quadros <rogerq@ti.com>
>> +
>> +description:
>> + The TI PIPE3 PHY is a high-speed SerDes (Serializer/Deserializer)
>> + transceiver integrated in OMAP5, DRA7xx/AM57xx, and similar SoCs.
>> + It supports multiple protocols (USB3, SATA, PCIe) using the PIPE3
>> + interface standard, which defines a common physical layer for
>> + high-speed serial interfaces.
>> +
>> +properties:
>> + $nodename:
>> + pattern: "^(pcie-phy|usb3-phy|phy)@[0-9a-f]+$"
>> +
>> + compatible:
>> + enum:
>> + - ti,omap-usb3
>> + - ti,phy-pipe3-pcie
>> + - ti,phy-pipe3-sata
>> + - ti,phy-usb3
>> +
>> + reg:
>> + minItems: 2
>> + maxItems: 3
>> +
>> + reg-names:
>> + minItems: 2
>> + items:
>> + - const: phy_rx
>> + - const: phy_tx
>> + - const: pll_ctrl
>> +
>> + "#phy-cells":
>> + const: 0
>> +
>> + clocks:
>> + minItems: 2
>> + maxItems: 7
>> +
>> + clock-names:
>> + minItems: 2
>> + maxItems: 7
>> + items:
>> + enum: [wkupclk, sysclk, refclk, dpll_ref,
>> + dpll_ref_m2, phy-div, div-clk]
>> +
>> + syscon-phy-power:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + items:
>> + - description: Phandle to the system control module
>> + - description: Register offset controlling PHY power
>
> This allows N entries of 2 cells each. You need either:
>
> items:
> - items:
> - description: ...
> - description: ...
>
> (the hyphen is important!)
>
> Or:
>
> maxItems: 1
> items:
> items:
> - description: ...
> - description: ...
Okay, I will use the above format in the next revision.
>
>> +
>> + syscon-pllreset:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + items:
>> + - description: Phandle to the system control module
>> + - description: Register offset of CTRL_CORE_SMA_SW_0
>> +
>> + syscon-pcs:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + items:
>> + - description: Phandle to the system control module
>> + - description: Register offset for PCS delay programming
>> +
>> + ctrl-module:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle of control module for PHY power on.
>> + deprecated: true
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: ti,phy-pipe3-sata
>> + then:
>> + properties:
>> + syscon-pllreset: true
>> + else:
>> + properties:
>> + syscon-pllreset: false
>> +
>> +required:
>> + - reg
>> + - compatible
>> + - reg-names
>> + - "#phy-cells"
>> + - clocks
>> + - clock-names
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + /* TI PIPE3 USB3 PHY */
>> + usb3-phy@4a084400 {
>> + compatible = "ti,phy-usb3";
>> + reg = <0x4a084400 0x80>,
>> + <0x4a084800 0x64>,
>> + <0x4a084c00 0x40>;
>> + reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> + #phy-cells = <0>;
>> + clocks = <&usb_phy_cm_clk32k>,
>> + <&sys_clkin>,
>> + <&usb_otg_ss_refclk960m>;
>> + clock-names = "wkupclk", "sysclk", "refclk";
>> + ctrl-module = <&omap_control_usb>;
>> + };
>> +
>> + - |
>> + /* TI PIPE3 SATA PHY */
>> + phy@4a096000 {
>> + compatible = "ti,phy-pipe3-sata";
>> + reg = <0x4A096000 0x80>, /* phy_rx */
>> + <0x4A096400 0x64>, /* phy_tx */
>> + <0x4A096800 0x40>; /* pll_ctrl */
>
> Use lowercase hex.
Sure.
>
>> + reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> + clocks = <&sys_clkin1>, <&sata_ref_clk>;
>> + clock-names = "sysclk", "refclk";
>> + syscon-pllreset = <&scm_conf 0x3fc>;
>> + #phy-cells = <0>;
>> + };
>> +...
>>
>> --
>> 2.52.0
>>
--
Best Regards,
Charan.
--
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