Add support for the firmware-managed variant of the DesignWare MAC on
the sa8255p platform. This series contains new DT bindings and driver
changes required to support the MAC in the STMMAC driver.

It also reorganizes the ethqos code quite a bit to make the introduction
of power domains into the driver a bit easier on the eye.

The DTS changes will go in separately.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v9:
- Rebase on top of current linux-next again
- Link to v8: https://patch.msgid.link/20260311-qcom-sa8255p-emac-v8-0-58227bcf1018@oss.qualcomm.com

Changes in v8:
- Rebase on top of recent changes in linux-next which required an
  extensive rework
- Drop partial R-b tags
- Link to v7: https://patch.msgid.link/20260306-qcom-sa8255p-emac-v7-0-d6a3013094b7@oss.qualcomm.com

Changes in v7:
- Restored the correct authorship after learning git uses .mailmap for
  the --author switch
- Rebased on top of changes from Russell
- Fixed resource management issues in error paths
- Link to v6: https://lore.kernel.org/r/20260112-qcom-sa8255p-emac-v6-0-86a3d4b2ad83@oss.qualcomm.com

Changes in v6:
- Fix $id value in the bindings
- Drop patch 3/8 from the series
- Update init/exit callback signatures
- Link to v5: https://lore.kernel.org/r/20251107-qcom-sa8255p-emac-v5-0-01d3e3aaf388@linaro.org
- Link to v6: https://lore.kernel.org/r/20251219-qcom-sa8255p-emac-v6-0-487f1082461e@oss.qualcomm.com

Changes in v5:
- Name the DT binding document after the new compatbile
- Add missing space
- Make the power-domains limits stricter
- Link to v4: https://lore.kernel.org/r/20251104-qcom-sa8255p-emac-v4-0-f76660087cea@linaro.org

Changes in v4:
- Remove the phys property from the SCMI bindings
- Mark the power-domain-names property as required
- Set maxItems for power-domains to 1 for all existing bindings to
  maintain the current requirements after modifying the value in the
  top-level document
- Link to v3: https://lore.kernel.org/r/20251027-qcom-sa8255p-emac-v3-0-75767b9230ab@linaro.org

Changes in v3:
- Drop 'power' and 'perf' prefixes from power domain names
- Rebase on top of Russell's changes to dwmac
- Rebase on top of even more changes from Russell that are not yet
  in next (E1vB6ld-0000000BIPy-2Qi4@rmk-PC.armlinux.org.uk)
- Link to v2: https://lore.kernel.org/all/20251008-qcom-sa8255p-emac-v2-0-92bc29309fce@linaro.org/

Changes in v2:
- Fix the power-domains property in DT bindings
- Rework the DT bindings example
- Drop the DTS patch, it will go upstream separately
- Link to v1: https://lore.kernel.org/r/20250910-qcom-sa8255p-emac-v1-0-32a79cf1e668@linaro.org

---
Bartosz Golaszewski (6):
      dt-bindings: net: qcom: document the ethqos device for SCMI-based systems
      net: stmmac: qcom-ethqos: use generic device properties
      net: stmmac: qcom-ethqos: wrap emac driver data in additional structure
      net: stmmac: qcom-ethqos: split power management fields into a separate structure
      net: stmmac: qcom-ethqos: split power management context into a separate struct
      net: stmmac: qcom-ethqos: add support for sa8255p

 .../bindings/net/allwinner,sun7i-a20-gmac.yaml     |   3 +
 .../bindings/net/altr,socfpga-stmmac.yaml          |   3 +
 .../bindings/net/amlogic,meson-dwmac.yaml          |   3 +
 .../devicetree/bindings/net/eswin,eic7700-eth.yaml |   3 +
 .../devicetree/bindings/net/intel,dwmac-plat.yaml  |   3 +
 .../bindings/net/loongson,ls1b-gmac.yaml           |   3 +
 .../bindings/net/loongson,ls1c-emac.yaml           |   3 +
 .../devicetree/bindings/net/nxp,dwmac-imx.yaml     |   3 +
 .../devicetree/bindings/net/nxp,lpc1850-dwmac.yaml |   3 +
 .../devicetree/bindings/net/nxp,s32-dwmac.yaml     |   3 +
 .../devicetree/bindings/net/qcom,ethqos.yaml       |   3 +
 .../bindings/net/qcom,sa8255p-ethqos.yaml          |  98 +++++
 .../devicetree/bindings/net/renesas,rzn1-gmac.yaml |   3 +
 .../bindings/net/renesas,rzv2h-gbeth.yaml          |   3 +
 .../devicetree/bindings/net/rockchip-dwmac.yaml    |   3 +
 .../devicetree/bindings/net/snps,dwmac.yaml        |   5 +-
 .../bindings/net/sophgo,cv1800b-dwmac.yaml         |   3 +
 .../bindings/net/sophgo,sg2044-dwmac.yaml          |   3 +
 .../bindings/net/starfive,jh7110-dwmac.yaml        |   3 +
 .../devicetree/bindings/net/stm32-dwmac.yaml       |   3 +
 .../devicetree/bindings/net/tesla,fsd-ethqos.yaml  |   3 +
 .../devicetree/bindings/net/thead,th1520-gmac.yaml |   3 +
 .../bindings/net/toshiba,visconti-dwmac.yaml       |   3 +
 MAINTAINERS                                        |   1 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |   2 +-
 .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 401 +++++++++++++++++----
 26 files changed, 498 insertions(+), 72 deletions(-)
---
base-commit: dac1315bf558e4895665aa1c278fd30113ca119d
change-id: 20250704-qcom-sa8255p-emac-8460235ac512

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

On Mon, 2026-03-16 at 13:05 +0100, Bartosz Golaszewski wrote:
> Add support for the firmware-managed variant of the DesignWare MAC on
> the sa8255p platform. This series contains new DT bindings and driver
> changes required to support the MAC in the STMMAC driver.
> 
> It also reorganizes the ethqos code quite a bit to make the introduction
> of power domains into the driver a bit easier on the eye.
> 
> The DTS changes will go in separately.

I'm seeing some weird behavior with this version. The probe part looks
good (but see below), but when I try to bring an interface up, it fails
with ETIMEDOUT. The relevant part of the stack trace leading to the
error is this:

dwmac4_dma_reset+0x208/0x220 [stmmac]
stmmac_reset+0x2c/0x68 [stmmac]
stmmac_init_dma_engine+0x108/0x400 [stmmac]
stmmac_hw_setup+0x5c/0x538 [stmmac]
__stmmac_open+0xc8/0x2a0 [stmmac]
stmmac_open+0xcc/0x238 [stmmac]
__dev_open+0x138/0x2a8

Now dwmac4_dma_reset() is very simple. It sets the soft reset bit in
the DMA_BUS_MODE register, then waits for the hardware to clear it, and
that never happens.

Now, getting back to the probe part, there is one extra message
(compared to my previous successful test on v7), which I see at the
very end of the probing:

  qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00
  exceeds mask 0x00000f00), truncating

This is a sa8775p ride board, so there are two stmmac devices. I only
see that message for the 2nd one, which is also the one I'm trying to
enable, and which fails.

I realize this may or may not be related to your changes. But there is
no way to test on a SCMI-pd board without them. I'm not sure how
relevant it would be to test on the non-SCMI variant. I'm assuming the
DMA part should work the same way (regardless of SCMI-pd), so if I can
reproduce it there, and since I know it works on mainline Linux (that's
where I tested v7), I could bisect and see which commit in net-next
breaks it. If you don't have any better idea, let me know and I can
try. Meanwhile, I'll keep poking at v9.

Radu

> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Changes in v9:
> - Rebase on top of current linux-next again
> - Link to v8: https://patch.msgid.link/20260311-qcom-sa8255p-emac-v8-0-58227bcf1018@oss.qualcomm.com
> 
> Changes in v8:
> - Rebase on top of recent changes in linux-next which required an
>   extensive rework
> - Drop partial R-b tags
> - Link to v7: https://patch.msgid.link/20260306-qcom-sa8255p-emac-v7-0-d6a3013094b7@oss.qualcomm.com
> 
> Changes in v7:
> - Restored the correct authorship after learning git uses .mailmap for
>   the --author switch
> - Rebased on top of changes from Russell
> - Fixed resource management issues in error paths
> - Link to v6: https://lore.kernel.org/r/20260112-qcom-sa8255p-emac-v6-0-86a3d4b2ad83@oss.qualcomm.com
> 
> Changes in v6:
> - Fix $id value in the bindings
> - Drop patch 3/8 from the series
> - Update init/exit callback signatures
> - Link to v5: https://lore.kernel.org/r/20251107-qcom-sa8255p-emac-v5-0-01d3e3aaf388@linaro.org
> - Link to v6: https://lore.kernel.org/r/20251219-qcom-sa8255p-emac-v6-0-487f1082461e@oss.qualcomm.com
> 
> Changes in v5:
> - Name the DT binding document after the new compatbile
> - Add missing space
> - Make the power-domains limits stricter
> - Link to v4: https://lore.kernel.org/r/20251104-qcom-sa8255p-emac-v4-0-f76660087cea@linaro.org
> 
> Changes in v4:
> - Remove the phys property from the SCMI bindings
> - Mark the power-domain-names property as required
> - Set maxItems for power-domains to 1 for all existing bindings to
>   maintain the current requirements after modifying the value in the
>   top-level document
> - Link to v3: https://lore.kernel.org/r/20251027-qcom-sa8255p-emac-v3-0-75767b9230ab@linaro.org
> 
> Changes in v3:
> - Drop 'power' and 'perf' prefixes from power domain names
> - Rebase on top of Russell's changes to dwmac
> - Rebase on top of even more changes from Russell that are not yet
>   in next (E1vB6ld-0000000BIPy-2Qi4@rmk-PC.armlinux.org.uk)
> - Link to v2: https://lore.kernel.org/all/20251008-qcom-sa8255p-emac-v2-0-92bc29309fce@linaro.org/
> 
> Changes in v2:
> - Fix the power-domains property in DT bindings
> - Rework the DT bindings example
> - Drop the DTS patch, it will go upstream separately
> - Link to v1: https://lore.kernel.org/r/20250910-qcom-sa8255p-emac-v1-0-32a79cf1e668@linaro.org
> 
> ---
> Bartosz Golaszewski (6):
>       dt-bindings: net: qcom: document the ethqos device for SCMI-based systems
>       net: stmmac: qcom-ethqos: use generic device properties
>       net: stmmac: qcom-ethqos: wrap emac driver data in additional structure
>       net: stmmac: qcom-ethqos: split power management fields into a separate structure
>       net: stmmac: qcom-ethqos: split power management context into a separate struct
>       net: stmmac: qcom-ethqos: add support for sa8255p
> 
>  .../bindings/net/allwinner,sun7i-a20-gmac.yaml     |   3 +
>  .../bindings/net/altr,socfpga-stmmac.yaml          |   3 +
>  .../bindings/net/amlogic,meson-dwmac.yaml          |   3 +
>  .../devicetree/bindings/net/eswin,eic7700-eth.yaml |   3 +
>  .../devicetree/bindings/net/intel,dwmac-plat.yaml  |   3 +
>  .../bindings/net/loongson,ls1b-gmac.yaml           |   3 +
>  .../bindings/net/loongson,ls1c-emac.yaml           |   3 +
>  .../devicetree/bindings/net/nxp,dwmac-imx.yaml     |   3 +
>  .../devicetree/bindings/net/nxp,lpc1850-dwmac.yaml |   3 +
>  .../devicetree/bindings/net/nxp,s32-dwmac.yaml     |   3 +
>  .../devicetree/bindings/net/qcom,ethqos.yaml       |   3 +
>  .../bindings/net/qcom,sa8255p-ethqos.yaml          |  98 +++++
>  .../devicetree/bindings/net/renesas,rzn1-gmac.yaml |   3 +
>  .../bindings/net/renesas,rzv2h-gbeth.yaml          |   3 +
>  .../devicetree/bindings/net/rockchip-dwmac.yaml    |   3 +
>  .../devicetree/bindings/net/snps,dwmac.yaml        |   5 +-
>  .../bindings/net/sophgo,cv1800b-dwmac.yaml         |   3 +
>  .../bindings/net/sophgo,sg2044-dwmac.yaml          |   3 +
>  .../bindings/net/starfive,jh7110-dwmac.yaml        |   3 +
>  .../devicetree/bindings/net/stm32-dwmac.yaml       |   3 +
>  .../devicetree/bindings/net/tesla,fsd-ethqos.yaml  |   3 +
>  .../devicetree/bindings/net/thead,th1520-gmac.yaml |   3 +
>  .../bindings/net/toshiba,visconti-dwmac.yaml       |   3 +
>  MAINTAINERS                                        |   1 +
>  drivers/net/ethernet/stmicro/stmmac/Kconfig        |   2 +-
>  .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 401 +++++++++++++++++----
>  26 files changed, 498 insertions(+), 72 deletions(-)
> ---
> base-commit: dac1315bf558e4895665aa1c278fd30113ca119d
> change-id: 20250704-qcom-sa8255p-emac-8460235ac512
> 
> Best regards,

On Mon, Mar 16, 2026 at 7:31 PM Radu Rendec <rrendec@redhat.com> wrote:
>
> On Mon, 2026-03-16 at 13:05 +0100, Bartosz Golaszewski wrote:
> > Add support for the firmware-managed variant of the DesignWare MAC on
> > the sa8255p platform. This series contains new DT bindings and driver
> > changes required to support the MAC in the STMMAC driver.
> >
> > It also reorganizes the ethqos code quite a bit to make the introduction
> > of power domains into the driver a bit easier on the eye.
> >
> > The DTS changes will go in separately.
>
> I'm seeing some weird behavior with this version. The probe part looks
> good (but see below), but when I try to bring an interface up, it fails
> with ETIMEDOUT. The relevant part of the stack trace leading to the
> error is this:
>
> dwmac4_dma_reset+0x208/0x220 [stmmac]
> stmmac_reset+0x2c/0x68 [stmmac]
> stmmac_init_dma_engine+0x108/0x400 [stmmac]
> stmmac_hw_setup+0x5c/0x538 [stmmac]
> __stmmac_open+0xc8/0x2a0 [stmmac]
> stmmac_open+0xcc/0x238 [stmmac]
> __dev_open+0x138/0x2a8
>
> Now dwmac4_dma_reset() is very simple. It sets the soft reset bit in
> the DMA_BUS_MODE register, then waits for the hardware to clear it, and
> that never happens.
>
> Now, getting back to the probe part, there is one extra message
> (compared to my previous successful test on v7), which I see at the
> very end of the probing:
>
>   qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00
>   exceeds mask 0x00000f00), truncating
>
> This is a sa8775p ride board, so there are two stmmac devices. I only
> see that message for the 2nd one, which is also the one I'm trying to
> enable, and which fails.
>
> I realize this may or may not be related to your changes. But there is
> no way to test on a SCMI-pd board without them. I'm not sure how
> relevant it would be to test on the non-SCMI variant. I'm assuming the
> DMA part should work the same way (regardless of SCMI-pd), so if I can
> reproduce it there, and since I know it works on mainline Linux (that's
> where I tested v7), I could bisect and see which commit in net-next
> breaks it. If you don't have any better idea, let me know and I can
> try. Meanwhile, I'll keep poking at v9.
>

Does current net-next on its own still work? Or is the second
interface broken even without this series?

Bart

On Tue, 2026-03-17 at 15:12 +0100, Bartosz Golaszewski wrote:
> On Mon, Mar 16, 2026 at 7:31 PM Radu Rendec <rrendec@redhat.com> wrote:
> > 
> > On Mon, 2026-03-16 at 13:05 +0100, Bartosz Golaszewski wrote:
> > > Add support for the firmware-managed variant of the DesignWare MAC on
> > > the sa8255p platform. This series contains new DT bindings and driver
> > > changes required to support the MAC in the STMMAC driver.
> > > 
> > > It also reorganizes the ethqos code quite a bit to make the introduction
> > > of power domains into the driver a bit easier on the eye.
> > > 
> > > The DTS changes will go in separately.
> > 
> > I'm seeing some weird behavior with this version. The probe part looks
> > good (but see below), but when I try to bring an interface up, it fails
> > with ETIMEDOUT. The relevant part of the stack trace leading to the
> > error is this:
> > 
> > dwmac4_dma_reset+0x208/0x220 [stmmac]
> > stmmac_reset+0x2c/0x68 [stmmac]
> > stmmac_init_dma_engine+0x108/0x400 [stmmac]
> > stmmac_hw_setup+0x5c/0x538 [stmmac]
> > __stmmac_open+0xc8/0x2a0 [stmmac]
> > stmmac_open+0xcc/0x238 [stmmac]
> > __dev_open+0x138/0x2a8
> > 
> > Now dwmac4_dma_reset() is very simple. It sets the soft reset bit in
> > the DMA_BUS_MODE register, then waits for the hardware to clear it, and
> > that never happens.
> > 
> > Now, getting back to the probe part, there is one extra message
> > (compared to my previous successful test on v7), which I see at the
> > very end of the probing:
> > 
> >   qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00
> >   exceeds mask 0x00000f00), truncating
> > 
> > This is a sa8775p ride board, so there are two stmmac devices. I only
> > see that message for the 2nd one, which is also the one I'm trying to
> > enable, and which fails.
> > 
> > I realize this may or may not be related to your changes. But there is
> > no way to test on a SCMI-pd board without them. I'm not sure how
> > relevant it would be to test on the non-SCMI variant. I'm assuming the
> > DMA part should work the same way (regardless of SCMI-pd), so if I can
> > reproduce it there, and since I know it works on mainline Linux (that's
> > where I tested v7), I could bisect and see which commit in net-next
> > breaks it. If you don't have any better idea, let me know and I can
> > try. Meanwhile, I'll keep poking at v9.
> > 
> 
> Does current net-next on its own still work? Or is the second
> interface broken even without this series?

I don't think there is a way to test net-next on its own (without your
series) on a board with SCMI-pd firmware. It would require the
qcom-ethqos driver to have direct access to the clocks, but the clocks
would not be there.

What I could test though is a board with the "other" firmware (without
SCMI-pd). And on that board, I do *not* see the problem even with your
series applied. In fact, I tested the exact same kernel build I had
previously tested on the SCMI-pd board.

I'm not sure what to make of that or what else I could try.

FWIW, the "clk_csr value out of range" message I mentioned before is
still there on the board where everything works, so it's probably a
red herring.

-- 
Radu