netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>
Subject: [PATCH net-next 0/6] net: stmmac: simplify axi_blen handling
Date: Wed, 19 Nov 2025 10:22:32 +0000	[thread overview]
Message-ID: <aR2aaDs6rqfu32B-@shell.armlinux.org.uk> (raw)

stmmac's axi_blen (burst length) handling is very verbose and
unnecessary.

Firstly, the burst length register bitfield is the same across all
dwmac cores, so we can use common definitions for these bits which
platform glue can use.

We end up with platform glue:
- filling in the axi_blen[] array with the decimal burst lengths, e.g.
  dwmac-intel.c, etc
- decoding a bitmap into burst lengths for this array, e.g.
  dwmac-dwc-qos-eth.c

Other cases read the array from DT, placing it into the axi_blen
array, and converting later to the register bitfield.

This series removes all this complexity, ultimately ending up with
platform glue providing the register value containing the burst
length bitfield directly. Where necessary, platform glue calls
stmmac_axi_blen_to_mask() to convert a decimal array (e.g. from
DT) to the register value.

This also means that stmmac_axi_blen_to_mask() can issue a
diagnostic message at probe time if the burst length is incorrect.

 drivers/net/ethernet/stmicro/stmmac/common.h       | 13 ++++++++
 .../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c    | 28 ++--------------
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c  |  5 ++-
 .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c    | 30 ++---------------
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c   | 30 ++---------------
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h   | 11 +------
 drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h    | 13 ++------
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     | 11 ++-----
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 33 ++++---------------
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 38 ++++++++++++++++++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c   |  6 ++--
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  4 ++-
 include/linux/stmmac.h                             |  2 +-
 13 files changed, 78 insertions(+), 146 deletions(-)

- 
-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

             reply	other threads:[~2025-11-19 10:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 10:22 Russell King (Oracle) [this message]
2025-11-19 10:23 ` [PATCH net-next 1/6] net: stmmac: dwc-qos-eth: simplify switch() in dwc_eth_dwmac_config_dt() Russell King (Oracle)
2025-11-19 10:23 ` [PATCH net-next 2/6] net: stmmac: move common DMA AXI register bits to common.h Russell King (Oracle)
2025-11-19 10:23 ` [PATCH net-next 3/6] net: stmmac: provide common stmmac_axi_blen_to_mask() Russell King (Oracle)
2025-11-19 10:23 ` [PATCH net-next 4/6] net: stmmac: move stmmac_axi_blen_to_mask() to stmmac_main.c Russell King (Oracle)
2025-11-19 10:23 ` [PATCH net-next 5/6] net: stmmac: move stmmac_axi_blen_to_mask() to axi_blen init sites Russell King (Oracle)
2025-11-19 10:23 ` [PATCH net-next 6/6] net: stmmac: remove axi_blen array Russell King (Oracle)
2025-11-21  2:10 ` [PATCH net-next 0/6] net: stmmac: simplify axi_blen handling patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aR2aaDs6rqfu32B-@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).