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

[Radu Rendec]

On Tue, 2026-03-17 at 15:12 +0100, Bartosz Golaszewski wrote:
> 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?

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