From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Nicolai Buchwitz <nb@tipi-net.de>
Cc: "Andrew Lunn" <andrew+netdev@lunn.ch>,
"Jakub Kicinski" <kuba@kernel.org>,
davem@davemloft.net, "Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Russell King" <linux@armlinux.org.uk>,
thomas.petazzoni@bootlin.com,
"Alexis Lothoré" <alexis.lothore@bootlin.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH net-next 1/2] net: stmmac: dwmac4: Read the UC filter size from hardware capabilities
Date: Tue, 1 Sep 2026 09:08:38 +0200 [thread overview]
Message-ID: <d4f9378d-36a1-4669-b0b3-9dcb9e3d980a@bootlin.com> (raw)
In-Reply-To: <2631c832d5aebc56e152628132494545@tipi-net.de>
Hi again Nicolai,
On 8/31/26 14:04, Nicolai Buchwitz wrote:
> Hi Maxime
>
> On 31.8.2026 09:01, Maxime Chevallier wrote:
>> dwmac4 has multiple banks of perfect filter entries, independently
>> configurable during IP integration.
>>
>> The multi_addr bank reports a number between 0 and 31 corresponding to
>> the actual number of entries in that bank, while the 32 and 64 banks
>> are all-or-nothing.
>>
>> Expose these caps over debugfs as well.
>>
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> ---
>
>> [...]
>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index 6382836828ba..89368e34a388 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -176,7 +176,9 @@ enum power_event {
>>
>> /* MAC HW features0 bitmap */
>> #define GMAC_HW_FEAT_SAVLANINS BIT(27)
>> -#define GMAC_HW_FEAT_ADDMAC BIT(18)
>> +#define GMAC_HW_FEAT_MACADR64SEL BIT(24)
>> +#define GMAC_HW_FEAT_MACADR32SEL BIT(23)
>> +#define GMAC_HW_FEAT_ADDMAC GENMASK(22, 18)
>> #define GMAC_HW_FEAT_RXCOESEL BIT(16)
>> #define GMAC_HW_FEAT_TXCOSEL BIT(14)
>> #define GMAC_HW_FEAT_EEESEL BIT(13)
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
>> index 23ffe1adcd0d..14ac3f0e51f7 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
>> @@ -388,6 +388,8 @@ static int dwmac4_get_hw_feature(void __iomem *ioaddr,
>> dma_cap->half_duplex = (hw_cap & GMAC_HW_FEAT_HDSEL) >> 2;
>> dma_cap->vlhash = (hw_cap & GMAC_HW_FEAT_VLHASH) >> 4;
>> dma_cap->multi_addr = (hw_cap & GMAC_HW_FEAT_ADDMAC) >> 18;
>
> Now that ADDMAC has grown from single bit to a mask, the hardcoded 18 has to match
> dwmac4.h. So IMHO it would make sense to use FIELD_GET() here (like actphyif)?
>
>> + dma_cap->additional_32_addr = (hw_cap & GMAC_HW_FEAT_MACADR32SEL) >> 23;
>> + dma_cap->additional_64_addr = (hw_cap & GMAC_HW_FEAT_MACADR64SEL) >> 24;
>> dma_cap->pcs = (hw_cap & GMAC_HW_FEAT_PCSSEL) >> 3;
>> dma_cap->sma_mdio = (hw_cap & GMAC_HW_FEAT_SMASEL) >> 5;
>> dma_cap->pmt_remote_wake_up = (hw_cap & GMAC_HW_FEAT_RWKSEL) >> 6;
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index f2fc89176654..a885f8cfef21 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -6580,6 +6580,18 @@ static int stmmac_dma_cap_show(struct seq_file *seq, void *v)
>> seq_printf(seq,
>> "\tNumber of Additional MAC address registers: %d\n",
>> priv->dma_cap.multi_addr);
>> + } else if (priv->plat->core_type == DWMAC_CORE_GMAC4) {
>> + seq_printf(seq,
>> + "\tNumber of MAC address registers (1-31): %d\n",
>> + priv->dma_cap.multi_addr);
>> + seq_printf(seq,
>> + "\tAdditional 32 MAC address registers (32-63): %s\n",
>> + priv->dma_cap.additional_32_addr ? "Y" : "N");
>> + seq_printf(seq,
>> + "\tAdditional 64 MAC address registers (64-127): %s\n",
>> + priv->dma_cap.additional_64_addr ? "Y" : "N");
>> + seq_printf(seq, "\tHash Filter: %s\n",
>> + (priv->dma_cap.hash_filter) ? "Y" : "N");
>
> hash_filter seems to be only set in dwmac1000_dma.c? So on dwmac4 it would always print N?
I stand corrected actually, after looking deeper, you're right :)
On dwmac1000, the feature bit 4 is HASHSEL, whereas on dwmac4, bit4 of HW_Features0 is
VLHASH, 2 different Hash tables :)
dwmac4 doesn't seem to have a bit just to say "there's a hash table", but instead directly
reports the sizeof of the hash table.
So I'll ditch that as you recommend, maybe in its own patch.
Maxime
next prev parent reply other threads:[~2026-09-01 7:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 7:01 [PATCH net-next 0/2] net: stmmac: dwmac4: Auto-discover UC filter size Maxime Chevallier
2026-08-31 7:01 ` [PATCH net-next 1/2] net: stmmac: dwmac4: Read the UC filter size from hardware capabilities Maxime Chevallier
2026-08-31 12:04 ` Nicolai Buchwitz
2026-08-31 12:15 ` Maxime Chevallier
2026-08-31 12:26 ` Nicolai Buchwitz
2026-09-01 0:26 ` Andrew Lunn
2026-09-01 7:04 ` Maxime Chevallier
2026-09-01 12:38 ` Andrew Lunn
2026-09-01 7:08 ` Maxime Chevallier [this message]
2026-08-31 7:01 ` [PATCH net-next 2/2] net: stmmac: dwmac4: Use the full perfect filter ability for UC filter Maxime Chevallier
2026-08-31 12:06 ` Nicolai Buchwitz
2026-09-01 0:12 ` Andrew Lunn
2026-09-01 6:37 ` Maxime Chevallier
2026-09-01 12:21 ` Andrew Lunn
2026-09-01 12:27 ` Maxime Chevallier
2026-09-01 12:50 ` Andrew Lunn
2026-09-03 9:00 ` [PATCH net-next 0/2] net: stmmac: dwmac4: Auto-discover UC filter size 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=d4f9378d-36a1-4669-b0b3-9dcb9e3d980a@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=alexis.lothore@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=nb@tipi-net.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=thomas.petazzoni@bootlin.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).