On Tue, 2026-03-17 at 15:12 +0100, Bartosz Golaszewski wrote:

On Mon, Mar 16, 2026 at 7:31 PM Radu Rendec [off-list ref] wrote:

quoted

On Mon, 2026-03-16 at 13:05 +0100, Bartosz Golaszewski wrote:

quoted

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