[PATCH net-next v9 0/6] net: stmmac: qcom-ethqos: add support for SCMI power domains

[Bartosz Golaszewski]

On Mon, Mar 16, 2026 at 7:31 PM Radu Rendec <rrendec at 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