* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Tobias Heider @ 2026-03-24 19:14 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Andersson, Bjorn Helgaas, Ziyue Zhang, konradybcio, robh,
krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski, bhelgaas,
johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa, kw,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <dnx4ge2e2zy2unw5jtmmhktyzlnmmhrogb5skskxewi6y7ekau@vpfdphzay7td>
On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > Resending because the previous mail ended up being HTML (sorry)
> >
> > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > >
> > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > to the port nodes.
> > > > > > > > >
> > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > > - x1-hp-omnibook-x14
> > > > > > > > > - x1-microsoft-denali
> > > > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > > > - x1-asus-zenbook-a14
> > > > > > > > > - x1-crd
> > > > > > > > > - x1-dell-thena
> > > > > > > > >
> > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > >
> > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > >
> > > > > > >
> > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > combinations, so it fails correctly so.
> > > > > > >
> > > > > >
> > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > v7.0-rc?
> > > > > >
> > > > >
> > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > >
> > > >
> > > > In line with Bjorn's request, we shouldn't have to guess.
> > > >
> > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > applied?
> > > > > >
> > > > >
> > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > fix on top of v7.0-rc1.
> > > > >
> > > >
> > > > So 960609b22be5 was broken when I merged it?
> > > >
> > >
> > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > platforms.
> > >
> > > > The commit message says that the commit was incomplete, in that it
> > > > didn't fully convert from the old to the new style, so it sounds like
> > > > the offending commit was incomplete - but I believe the offending commit
> > > > was a workaround for the new solution not being in place and this commit
> > > > mostly reverts the changes in the offending commit.
> > > >
> > >
> > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > new for greater good, but it apparently decided to do so only for a subset of
> > > the platforms for some reason which don't know. But the problem arises due to
> > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > or dts converted and not both to the new binding, the driver will get confused
> > > and fail. And this is what exactly happended for below machines:
> > >
> > > - x1-hp-omnibook-x14
> > > - x1-microsoft-denali
> > > - x1e80100-lenovo-yoga-slim7x
> > > - x1e80100-medion-sprchrgd-14-s1
> > > - x1p42100-lenovo-thinkbook-16
> > > - x1-asus-zenbook-a14
> > > - x1-crd
> > > - x1-dell-thena
> >
> > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> >
> > I'll try to collect some test feedback for the fix.
> > I'd certainly appreciate this being included as an rc fix since
> > currently half of
> > the x1 laptop devices are broken.
> >
>
> Thanks for the report. We will try to get this patch into v7.0-rcS.
>
> It'd be appreciated if you can test this patch and give your tested-by tag.
>
> - Mani
Thank you!
Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
I have tested the CRD and got user feedback that it works on at least an
Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
Potentially more but not everyone provides feedback when things don't break.
Tested-by: Tobias Heider <tobias.heider@canonical.com>
>
> --
> மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Abel Vesa @ 2026-03-24 16:26 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-4-ce0fc07f0e52@oss.qualcomm.com>
On 26-03-23 00:15:31, Qiang Yu wrote:
> The third PCIe controller on Glymur SoC supports 8-lane operation via
> bifurcation of two PHYs (each requires separate power domian, resets and
> aux clk).
>
> Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
> clock ("phy_b_aux") required for 8-lane operation. Introduce new
> glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Diogo Ivo @ 2026-03-24 14:36 UTC (permalink / raw)
To: Jon Hunter, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <7a6f8967-c635-4d84-bbab-9e019ff79134@nvidia.com>
On 3/24/26 13:33, Jon Hunter wrote:
>
>
> On 24/03/2026 11:31, Diogo Ivo wrote:
>>
>>
>> On 3/24/26 10:16, Jon Hunter wrote:
>>>
>>> On 27/01/2026 15:11, Diogo Ivo wrote:
>>>> Move the Tegra186 PHY .set_mode() callback to a common implementation.
>>>> In order to do this first revert cefc1caee9dd.
>>>
>>> This commit message does not seem complete.
>>
>> How so? It is succint but it states exactly what the commit does. It
>> reverts cefc1caee9dd and changes T186 to the common implementation
>> prepared in the previous patch.
>
> It does not read clearly to me. The 2nd sentence sounds like that's all
> this is doing but we are not, we are reverting and doing the move.
>>> Furthermore, I am not sure why we want to revert cefc1caee9dd. We
>>> purposely moved the regulator_enable/disable into
>>> tegra186_xusb_padctl_id_override() because it is tied to setting the
>>> USB2_VBUS_ID. So I would prefer to keep it this way and move the
>>> Tegra210 implementation in the same direction (if possible).
>>
>> I don't agree that this is the best solution.
>>
>> We really benefit from a common implementation for the two platforms, not
>> only because of duplicate code but more importantly because without it
>> whenever a bug is found and fixed on either platform it most likely will
>> not be fixed on the other one. Case in point, cefc1caee9dd fixed a bug
>> on T186 but not the same bug on T210 (which then led to this series)
>> since
>> the implementation was not shared among them. Were it the case that they
>> shared the implementation the fix would have come "free" for T210.
>>
>> This will keep happening for as long as we have duplicate
>> implementations,
>> which becomes more relevant since there is a severe lack of testing in
>> older Tegra platforms. I also thought about making the id_override()
>> implementation shared between T186 and T210 but that would be take more
>> changes since register definitions would need to be moved somewhere
>> else too.
>
> I am all for a common implementation. I believe that in the
> tegra186_xusb_padctl_id_override() function the only thing that is
> different is the offset for the USB2_VBUS_ID register, which should be
> easy to handle.
Ok, I can make it common there as well. However I still feel like
reverting cefc1caee9dd leads to cleaner code since vbus_override() and
id_override() will look similar and only do exactly what they state in
their names and the overall logic looks cleaner.
Diogo
> Jon
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Lad, Prabhakar @ 2026-03-24 14:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Magnus Damm,
Pavel Machek, linux-renesas-soc, linux-phy, linux-kernel,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CAMuHMdV_94xOmqRqDKW_e740ckmRoyW+oaHvorphNg27JNKUrw@mail.gmail.com>
Hi Geert,
Thank you for the review.
On Tue, Mar 24, 2026 at 1:05 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Tue, 24 Mar 2026 at 13:16, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> > the value instead of performing multiple MMIO reads.
> >
> > Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> > directly. This preserves the existing behaviour while improving code
> > clarity and avoiding redundant register accesses.
> >
> > Reported-by: Pavel Machek <pavel@nabladev.com>
> > Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Thanks for your patch!
>
> > --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > @@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> > static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> > {
> > if (ch->phy_data->vblvl_ctrl) {
> > + u32 val = readl(ch->base + USB2_ADPCTRL);
> > bool vbus_valid;
> > bool device;
> >
> > - device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> > - vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
> > + device = !!(val & USB2_ADPCTRL_IDDIG);
> > + vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
>
> Perhaps combine variable declarations and assignments?
> The "!!" is not needed when assigning to a bool.
>
Agreed, I will address it and send a v2.
Cheers,
Prabhakar
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-24 13:50 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acHCIA1d5-s2xkvz@google.com>
On Mon, Mar 23, 2026 at 03:48:42PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 11:39:03PM +0100, Andrew Lunn wrote:
> > > If there is a deprecated property you can do:
> > >
> > > error = device_property_read_u32(dev, "prop", &val);
> > > if (error == -ENOENT)
> > > error = device_property_read_u32(dev, "deprecated-prop", &val);
> >
> > It is not as simple as that. There are a lot of optional
> > properties. Say "prop" is optional? And not present. So -ENOENT. We
> > then look for this deprecated property. That should not happen.
>
> Why? That is exactly what you want: you favor new one if it is present
> and fall back to deprecated one if it is absent. And then you decide
> whether to continue or abort.
The old property is only valid in DT, where it is deprecated, but
still valid. It should never appear in any other newer firmware
bindings.
> If you only have of_property_read_u32() then it will not stand out. If
> you advocate of using device_property_read_u32() normally but
> of_property_read_u32() for deprecated only - that is a possibility, but
> I do not know if anyone does this.
For the subsystems i've dealt with, when somebody proposes a patch
adding an ACPI binding, and they do an of_ to device_ conversion
without engaging brain, i point out the issues, they should not be
adding deprecated properties to a brand new binding, and they go away
and never come back. And so the code remains OF only. Which is fine,
nobody does networking devices using ACPI.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Jon Hunter @ 2026-03-24 13:33 UTC (permalink / raw)
To: Diogo Ivo, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <5a5397c8-cc32-4d6b-86a4-76f924ae6d75@tecnico.ulisboa.pt>
On 24/03/2026 11:31, Diogo Ivo wrote:
>
>
> On 3/24/26 10:16, Jon Hunter wrote:
>>
>> On 27/01/2026 15:11, Diogo Ivo wrote:
>>> Move the Tegra186 PHY .set_mode() callback to a common implementation.
>>> In order to do this first revert cefc1caee9dd.
>>
>> This commit message does not seem complete.
>
> How so? It is succint but it states exactly what the commit does. It
> reverts cefc1caee9dd and changes T186 to the common implementation
> prepared in the previous patch.
It does not read clearly to me. The 2nd sentence sounds like that's all
this is doing but we are not, we are reverting and doing the move.
>> Furthermore, I am not sure why we want to revert cefc1caee9dd. We
>> purposely moved the regulator_enable/disable into
>> tegra186_xusb_padctl_id_override() because it is tied to setting the
>> USB2_VBUS_ID. So I would prefer to keep it this way and move the
>> Tegra210 implementation in the same direction (if possible).
>
> I don't agree that this is the best solution.
>
> We really benefit from a common implementation for the two platforms, not
> only because of duplicate code but more importantly because without it
> whenever a bug is found and fixed on either platform it most likely will
> not be fixed on the other one. Case in point, cefc1caee9dd fixed a bug
> on T186 but not the same bug on T210 (which then led to this series) since
> the implementation was not shared among them. Were it the case that they
> shared the implementation the fix would have come "free" for T210.
>
> This will keep happening for as long as we have duplicate implementations,
> which becomes more relevant since there is a severe lack of testing in
> older Tegra platforms. I also thought about making the id_override()
> implementation shared between T186 and T210 but that would be take more
> changes since register definitions would need to be moved somewhere
> else too.
I am all for a common implementation. I believe that in the
tegra186_xusb_padctl_id_override() function the only thing that is
different is the offset for the USB2_VBUS_ID register, which should be
easy to handle.
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Geert Uytterhoeven @ 2026-03-24 13:05 UTC (permalink / raw)
To: Prabhakar
Cc: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Magnus Damm,
Pavel Machek, linux-renesas-soc, linux-phy, linux-kernel,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260324121608.3444943-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Tue, 24 Mar 2026 at 13:16, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> the value instead of performing multiple MMIO reads.
>
> Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> directly. This preserves the existing behaviour while improving code
> clarity and avoiding redundant register accesses.
>
> Reported-by: Pavel Machek <pavel@nabladev.com>
> Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> {
> if (ch->phy_data->vblvl_ctrl) {
> + u32 val = readl(ch->base + USB2_ADPCTRL);
> bool vbus_valid;
> bool device;
>
> - device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> - vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
> + device = !!(val & USB2_ADPCTRL_IDDIG);
> + vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
Perhaps combine variable declarations and assignments?
The "!!" is not needed when assigning to a bool.
>
> - return vbus_valid ? device : !device;
> + return device == vbus_valid;
> }
>
> if (!ch->uses_otg_pins)
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/4] dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
From: Jiayu Du @ 2026-03-24 13:03 UTC (permalink / raw)
To: robh
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex, linux-phy,
linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260121145526.14672-3-jiayu.riscv@isrc.iscas.ac.cn>
On Wed, Jan 21, 2026 at 10:55:23PM +0800, Jiayu Du wrote:
> 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>
Hi Rob,
Will this patch2 be applied for next?
Best regards,
Jiayu Du
> ---
> 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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 7/7] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 5/7] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..4e242b1892334 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,13 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +314,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d9400599e80a4..7ac75fc8cdcf4 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_RING,
};
+static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
+ .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ,
+ .ale_dev_id = "am64-cpswxg",
+ .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
.quirks = 0,
.ale_dev_id = "am64-cpswxg",
@@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
{ .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
+ { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
{ .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
{ .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
{ .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/7] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..283e3eedc0f31 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,19 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - items:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/7] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6b584706b913a..7531a8a049123 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/7] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index a959c1d7e643a..70d25f5ff1cfe 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -53,13 +53,19 @@ properties:
"#size-cells": true
compatible:
- enum:
- - ti,am642-cpsw-nuss
- - ti,am654-cpsw-nuss
- - ti,j7200-cpswxg-nuss
- - ti,j721e-cpsw-nuss
- - ti,j721e-cpswxg-nuss
- - ti,j784s4-cpswxg-nuss
+ oneOf:
+ - items:
+ - enum:
+ - ti,am642-cpsw-nuss
+ - ti,am654-cpsw-nuss
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ - items:
+ - enum:
+ - ti,j722s-cpsw-nuss
+ - const: ti,am642-cpsw-nuss
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/7] J722S SGMII support
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages (patches 1-3 and 7)
- No changes to patches 4-6
Nora Schiffer (7):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
net: ethernet: ti: am65-cpsw: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++------
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 +++++++
drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
7 files changed, 94 insertions(+), 25 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 2/7] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..6e12a75100eb8 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,21 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - items:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Diogo Ivo @ 2026-03-24 12:28 UTC (permalink / raw)
To: Thierry Reding
Cc: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <acJ50sQraVmy4zXs@orome>
On 3/24/26 11:48, Thierry Reding wrote:
> On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
>> As the PHY subsystem already synchronizes concurrent accesses to a PHY
>> instance with a core-internal mutex remove the driver specific mutex
>> synchronization.
>>
>> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
>> ---
>> v1->v2:
>> - New patch
>> ---
>> drivers/usb/host/xhci-tegra.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
>> index 8b492871d21d..927861ca14f2 100644
>> --- a/drivers/usb/host/xhci-tegra.c
>> +++ b/drivers/usb/host/xhci-tegra.c
>> @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
>>
>> dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
>>
>> - mutex_lock(&tegra->lock);
>> -
>> if (tegra->host_mode)
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
>> else
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
>>
>> - mutex_unlock(&tegra->lock);
>> -
>
> It looks to me like the mutex here is trying to protect against
> tegra->host_mode changing while we're setting a different mode. That
> doesn't seem to be taken care of by the PHY internal mutex.
I'm not sure I understand your point. Do you mean guarding against
tegra->host_mode changing in tegra_xhci_id_notify()? If so I don't see
how it would guard against that.
Diogo
> Thierry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Lad, Prabhakar @ 2026-03-24 12:18 UTC (permalink / raw)
To: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
Magnus Damm, Pavel Machek
Cc: linux-renesas-soc, linux-phy, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260324121608.3444943-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi All,
On Tue, Mar 24, 2026 at 12:16 PM Prabhakar <prabhakar.csengg@gmail.com> wrote:
>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> the value instead of performing multiple MMIO reads.
>
> Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> directly. This preserves the existing behaviour while improving code
> clarity and avoiding redundant register accesses.
>
> Reported-by: Pavel Machek <pavel@nabladev.com>
> Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
My bad, wrong link, https://lore.kernel.org/all/acJVCOdlchLiSe5n@duo.ucw.cz/
Cheers,
Prabhakar
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Prabhakar @ 2026-03-24 12:16 UTC (permalink / raw)
To: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
Magnus Damm, Pavel Machek
Cc: linux-renesas-soc, linux-phy, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
the value instead of performing multiple MMIO reads.
Simplify the return logic by comparing the IDDIG and VBUSVALID bits
directly. This preserves the existing behaviour while improving code
clarity and avoiding redundant register accesses.
Reported-by: Pavel Machek <pavel@nabladev.com>
Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Note, patch applies on top of next-20260323.
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 79e820e2fe55..74d7561dbf79 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
{
if (ch->phy_data->vblvl_ctrl) {
+ u32 val = readl(ch->base + USB2_ADPCTRL);
bool vbus_valid;
bool device;
- device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
- vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
+ device = !!(val & USB2_ADPCTRL_IDDIG);
+ vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
- return vbus_valid ? device : !device;
+ return device == vbus_valid;
}
if (!ch->uses_otg_pins)
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Thierry Reding @ 2026-03-24 11:48 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <20260127-diogo-tegra_phy-v2-2-787b9eed3ed5@tecnico.ulisboa.pt>
[-- Attachment #1.1: Type: text/plain, Size: 1227 bytes --]
On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
> As the PHY subsystem already synchronizes concurrent accesses to a PHY
> instance with a core-internal mutex remove the driver specific mutex
> synchronization.
>
> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> ---
> v1->v2:
> - New patch
> ---
> drivers/usb/host/xhci-tegra.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> index 8b492871d21d..927861ca14f2 100644
> --- a/drivers/usb/host/xhci-tegra.c
> +++ b/drivers/usb/host/xhci-tegra.c
> @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
>
> dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
>
> - mutex_lock(&tegra->lock);
> -
> if (tegra->host_mode)
> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
> else
> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
>
> - mutex_unlock(&tegra->lock);
> -
It looks to me like the mutex here is trying to protect against
tegra->host_mode changing while we're setting a different mode. That
doesn't seem to be taken care of by the PHY internal mutex.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Diogo Ivo @ 2026-03-24 11:31 UTC (permalink / raw)
To: Jon Hunter, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <af04fc85-1ed4-4046-86ee-1ffcec8c44cd@nvidia.com>
On 3/24/26 10:16, Jon Hunter wrote:
>
> On 27/01/2026 15:11, Diogo Ivo wrote:
>> Move the Tegra186 PHY .set_mode() callback to a common implementation.
>> In order to do this first revert cefc1caee9dd.
>
> This commit message does not seem complete.
How so? It is succint but it states exactly what the commit does. It
reverts cefc1caee9dd and changes T186 to the common implementation
prepared in the previous patch.
> Furthermore, I am not sure why we want to revert cefc1caee9dd. We
> purposely moved the regulator_enable/disable into
> tegra186_xusb_padctl_id_override() because it is tied to setting the
> USB2_VBUS_ID. So I would prefer to keep it this way and move the
> Tegra210 implementation in the same direction (if possible).
I don't agree that this is the best solution.
We really benefit from a common implementation for the two platforms, not
only because of duplicate code but more importantly because without it
whenever a bug is found and fixed on either platform it most likely will
not be fixed on the other one. Case in point, cefc1caee9dd fixed a bug
on T186 but not the same bug on T210 (which then led to this series) since
the implementation was not shared among them. Were it the case that they
shared the implementation the fix would have come "free" for T210.
This will keep happening for as long as we have duplicate implementations,
which becomes more relevant since there is a severe lack of testing in
older Tegra platforms. I also thought about making the id_override()
implementation shared between T186 and T210 but that would be take more
changes since register definitions would need to be moved somewhere
else too.
Diogo
> Jon
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Jon Hunter @ 2026-03-24 10:16 UTC (permalink / raw)
To: Diogo Ivo, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <20260127-diogo-tegra_phy-v2-6-787b9eed3ed5@tecnico.ulisboa.pt>
On 27/01/2026 15:11, Diogo Ivo wrote:
> Move the Tegra186 PHY .set_mode() callback to a common implementation.
> In order to do this first revert cefc1caee9dd.
This commit message does not seem complete.
Furthermore, I am not sure why we want to revert cefc1caee9dd. We
purposely moved the regulator_enable/disable into
tegra186_xusb_padctl_id_override() because it is tied to setting the
USB2_VBUS_ID. So I would prefer to keep it this way and move the
Tegra210 implementation in the same direction (if possible).
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: tegra: xusb: Fix per-pad high-speed termination calibration
From: Jon Hunter @ 2026-03-24 9:11 UTC (permalink / raw)
To: Wei-Cheng Chen, jckuo, vkoul, neil.armstrong, thierry.reding
Cc: linux-phy, linux-tegra, linux-kernel, waynec, wtsai
In-Reply-To: <20260304102649.3670783-1-weichengc@nvidia.com>
On 04/03/2026 10:26, Wei-Cheng Chen wrote:
> From: Wayne Chang <waynec@nvidia.com>
>
> The existing code reads a single hs_term_range_adj value from bit field
> [10:7] of FUSE_SKU_CALIB_0 and applies it to all USB2 pads uniformly.
> However, on SoCs that support per-pad termination, each pad has its own
> hs_term_range_adj field: pad 0 in FUSE_SKU_CALIB_0[10:7], and pads 1-3
> in FUSE_USB_CALIB_EXT_0 at bit offsets [8:5], [12:9], and [16:13]
> respectively.
>
> Fix the calibration by reading per-pad values from the appropriate fuse
> registers. For SoCs that do not support per-pad termination, replicate
> pad 0's value to all pads to maintain existing behavior.
>
> Add a has_per_pad_term flag to the SoC data to indicate whether per-pad
> termination values are available in FUSE_USB_CALIB_EXT_0.
>
> Fixes: 1ef535c6ba8e ("phy: tegra: xusb: Add Tegra194 support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wayne Chang <waynec@nvidia.com>
> Signed-off-by: Wei-Cheng Chen <weichengc@nvidia.com>
> ---
> drivers/phy/tegra/xusb-tegra186.c | 33 ++++++++++++++++++++++++-------
> drivers/phy/tegra/xusb.h | 1 +
> 2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
> index bec9616c4a2..4452e73fb82 100644
> --- a/drivers/phy/tegra/xusb-tegra186.c
> +++ b/drivers/phy/tegra/xusb-tegra186.c
> @@ -20,8 +20,8 @@
> /* FUSE USB_CALIB registers */
> #define HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? (11 + (x - 1) * 6) : 0)
> #define HS_CURR_LEVEL_PAD_MASK 0x3f
> -#define HS_TERM_RANGE_ADJ_SHIFT 7
> -#define HS_TERM_RANGE_ADJ_MASK 0xf
> +#define HS_TERM_RANGE_ADJ_PADX_SHIFT(x) ((x) ? (5 + (x - 1) * 4) : 7)
> +#define HS_TERM_RANGE_ADJ_PAD_MASK 0xf
> #define HS_SQUELCH_SHIFT 29
> #define HS_SQUELCH_MASK 0x7
>
> @@ -253,7 +253,7 @@
> struct tegra_xusb_fuse_calibration {
> u32 *hs_curr_level;
> u32 hs_squelch;
> - u32 hs_term_range_adj;
> + u32 *hs_term_range_adj;
> u32 rpd_ctrl;
> };
>
> @@ -930,7 +930,7 @@ static int tegra186_utmi_phy_power_on(struct phy *phy)
>
> value = padctl_readl(padctl, XUSB_PADCTL_USB2_OTG_PADX_CTL1(index));
> value &= ~TERM_RANGE_ADJ(~0);
> - value |= TERM_RANGE_ADJ(priv->calib.hs_term_range_adj);
> + value |= TERM_RANGE_ADJ(priv->calib.hs_term_range_adj[index]);
> value &= ~RPD_CTRL(~0);
> value |= RPD_CTRL(priv->calib.rpd_ctrl);
> padctl_writel(padctl, value, XUSB_PADCTL_USB2_OTG_PADX_CTL1(index));
> @@ -1464,17 +1464,23 @@ static const char * const tegra186_usb3_functions[] = {
> static int
> tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
> {
> + const struct tegra_xusb_padctl_soc *soc = padctl->base.soc;
> struct device *dev = padctl->base.dev;
> unsigned int i, count;
> u32 value, *level;
> + u32 *hs_term_range_adj;
> int err;
>
> - count = padctl->base.soc->ports.usb2.count;
> + count = soc->ports.usb2.count;
>
> level = devm_kcalloc(dev, count, sizeof(u32), GFP_KERNEL);
> if (!level)
> return -ENOMEM;
>
> + hs_term_range_adj = devm_kcalloc(dev, count, sizeof(u32), GFP_KERNEL);
> + if (!hs_term_range_adj)
> + return -ENOMEM;
> +
> err = tegra_fuse_readl(TEGRA_FUSE_SKU_CALIB_0, &value);
> if (err)
> return dev_err_probe(dev, err,
> @@ -1490,8 +1496,8 @@ tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
>
> padctl->calib.hs_squelch = (value >> HS_SQUELCH_SHIFT) &
> HS_SQUELCH_MASK;
> - padctl->calib.hs_term_range_adj = (value >> HS_TERM_RANGE_ADJ_SHIFT) &
> - HS_TERM_RANGE_ADJ_MASK;
> + hs_term_range_adj[0] = (value >> HS_TERM_RANGE_ADJ_PADX_SHIFT(0)) &
> + HS_TERM_RANGE_ADJ_PAD_MASK;
>
> err = tegra_fuse_readl(TEGRA_FUSE_USB_CALIB_EXT_0, &value);
> if (err) {
> @@ -1503,6 +1509,17 @@ tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
>
> padctl->calib.rpd_ctrl = (value >> RPD_CTRL_SHIFT) & RPD_CTRL_MASK;
>
> + for (i = 1; i < count; i++) {
> + if (soc->has_per_pad_term)
> + hs_term_range_adj[i] =
> + (value >> HS_TERM_RANGE_ADJ_PADX_SHIFT(i)) &
> + HS_TERM_RANGE_ADJ_PAD_MASK;
> + else
> + hs_term_range_adj[i] = hs_term_range_adj[0];
> + }
> +
> + padctl->calib.hs_term_range_adj = hs_term_range_adj;
> +
> return 0;
> }
>
> @@ -1708,6 +1725,7 @@ const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc = {
> .num_supplies = ARRAY_SIZE(tegra194_xusb_padctl_supply_names),
> .supports_gen2 = true,
> .poll_trk_completed = true,
> + .has_per_pad_term = true,
> };
> EXPORT_SYMBOL_GPL(tegra194_xusb_padctl_soc);
>
> @@ -1732,6 +1750,7 @@ const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc = {
> .trk_hw_mode = false,
> .trk_update_on_idle = true,
> .supports_lp_cfg_en = true,
> + .has_per_pad_term = true,
> };
> EXPORT_SYMBOL_GPL(tegra234_xusb_padctl_soc);
> #endif
> diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
> index d2b5f956513..810b410672f 100644
> --- a/drivers/phy/tegra/xusb.h
> +++ b/drivers/phy/tegra/xusb.h
> @@ -436,6 +436,7 @@ struct tegra_xusb_padctl_soc {
> bool trk_hw_mode;
> bool trk_update_on_idle;
> bool supports_lp_cfg_en;
> + bool has_per_pad_term;
> };
>
> struct tegra_xusb_padctl {
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Thanks
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-24 6:07 UTC (permalink / raw)
To: Tobias Heider
Cc: Bjorn Andersson, Bjorn Helgaas, Ziyue Zhang, konradybcio, robh,
krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski, bhelgaas,
johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa, kw,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <CAARv3RSag8n0=ut9KGm0yALRPVTiyQ+bBBbT+3Vf1sNOCBLbGA@mail.gmail.com>
On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> Resending because the previous mail ended up being HTML (sorry)
>
> On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > >
> > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > to the port nodes.
> > > > > > > >
> > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > - x1-hp-omnibook-x14
> > > > > > > > - x1-microsoft-denali
> > > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > > - x1-asus-zenbook-a14
> > > > > > > > - x1-crd
> > > > > > > > - x1-dell-thena
> > > > > > > >
> > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > >
> > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > the old style with them described in the Root Complex node.
> > > > > > >
> > > > > >
> > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > combinations, so it fails correctly so.
> > > > > >
> > > > >
> > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > v7.0-rc?
> > > > >
> > > >
> > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > >
> > >
> > > In line with Bjorn's request, we shouldn't have to guess.
> > >
> > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > fixing that change, or is it only applicable once some other changes are
> > > > > applied?
> > > > >
> > > >
> > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > fix on top of v7.0-rc1.
> > > >
> > >
> > > So 960609b22be5 was broken when I merged it?
> > >
> >
> > Broken on the machines mentioned in the commit message, not for all Hamoa
> > platforms.
> >
> > > The commit message says that the commit was incomplete, in that it
> > > didn't fully convert from the old to the new style, so it sounds like
> > > the offending commit was incomplete - but I believe the offending commit
> > > was a workaround for the new solution not being in place and this commit
> > > mostly reverts the changes in the offending commit.
> > >
> >
> > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > new for greater good, but it apparently decided to do so only for a subset of
> > the platforms for some reason which don't know. But the problem arises due to
> > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > platform DTS to also be changed to the new binding. If we only have either dtsi
> > or dts converted and not both to the new binding, the driver will get confused
> > and fail. And this is what exactly happended for below machines:
> >
> > - x1-hp-omnibook-x14
> > - x1-microsoft-denali
> > - x1e80100-lenovo-yoga-slim7x
> > - x1e80100-medion-sprchrgd-14-s1
> > - x1p42100-lenovo-thinkbook-16
> > - x1-asus-zenbook-a14
> > - x1-crd
> > - x1-dell-thena
>
> I can confirm the breakage for (some of) the listed devices on Ubuntu.
> We are experimenting with 7.0-rcs ahead of our 26.04 release.
>
> I'll try to collect some test feedback for the fix.
> I'd certainly appreciate this being included as an rc fix since
> currently half of
> the x1 laptop devices are broken.
>
Thanks for the report. We will try to get this patch into v7.0-rcS.
It'd be appreciated if you can test this patch and give your tested-by tag.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-24 5:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <20260319171728.GA505341@bhelgaas>
On Thu, Mar 19, 2026 at 12:17:28PM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 19, 2026 at 10:58:36AM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > >
> > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > to the port nodes.
> > > > > >
> > > > > > This fixes probe failures seen on the following platforms:
> > > > > > - x1-hp-omnibook-x14
> > > > > > - x1-microsoft-denali
> > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > - x1-asus-zenbook-a14
> > > > > > - x1-crd
> > > > > > - x1-dell-thena
> > > > > >
> > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > >
> > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > the old style with them described in the Root Complex node.
> > > >
> > > > This is not related to the driver change. The driver correctly
> > > > parses all Root Port properties either in the Root Complex node (old
> > > > binding) or Root Port node (new binding). But commit 960609b22be5,
> > > > left converting mentioned board DTS to the new binding, leaving
> > > > those affected platforms in a half baked state i.e., some properties
> > > > in RC node and some in Root Port node. Driver cannot parse such
> > > > combinations, so it fails correctly so.
> > >
> > > The commit log mentions probe failures on some machines. I'd like it
> > > to be more clear about who is affected and what they need to do to fix
> > > their machines.
> >
> > There is already a list of affected machines mentioned in the commit
> > message.
> >
> > And for fix, they just need to apply this patch. Or once this patch
> > gets merged into v7.0-rcS, v7.0 will have no issue.
> >
> > > If it only affects developers who generated DTs based on
> > > 960609b22be5 for internal testing, we should say that so it's
> > > clear that no end users will see any regressions or boot
> > > failures.
> >
> > Whoever have included commit 960609b22be5 in their kernel and using
> > the above mentioned machines will see the failure. But looks like no
> > one really tested v7.0-rcS on these machines as we haven't gotten
> > any reports so far.
>
> Two points:
>
> - a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root
> Port binding") is intended for hardware with multiple Root Ports
> with independent PHY/reset controls.
>
Not really. The commit was a prerequisite for adding multi-Root Port
controllers, but the intention is also to move the Root Port resources to Root
Port node and not stuff everything in the Host Bridge node.
> The driver will always fall back to PHY/reset info in the host
> bridge, so I think the only reason to do 960609b22be5 and this fix
> is if hamoa.dtsi will also be used for hardware with multiple Root
> Ports. If there's no plan for multiple RPs with hamoa.dtsi,
> reverting 960609b22be5 is another, less risky, option.
>
That will leave things in a messy state. Our intention is to move Root Port
resources to Root Port nodes for all SoCs irrespective of whether they support
multi-RPs or not.
> - 960609b22be5 only touches .dtsi and .dts files; it doesn't change
> the kernel itself.
>
> So I assume this issue only affects somebody who used v7.0-rc1 to
> rebuild the DTB for one of those machines and then installed that
> new DTB on their system. That sounds like developers to me, not
> end users.
>
Unfortunately, DTB is still not treated as a firmware like ACPI. And the fact
that we build the DTBs with the kernel, causes the DTBs to be updated whenever
an end user or a developer builds the kernel .deb package using 'make deb-pkg'
and installs then package using 'dpkg -i'.
And most of the users of these affected machines are pretty much both end users
and developers who know how to build the kernel themselves, so they won't be
updating the kernel through their distro update.
> The commit log already mentions the affected machines. I'm
> suggesting that it should also say something about the fact that
> only DTBs built with 960609b22be5 are affected, i.e., DTBs built
> with 960609b22be5 but without this fix are incompatible with the
> kernel driver.
Sure.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
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