From: Furong Xu <0x1207@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
Simon Horman <horms@kernel.org>,
andrew+netdev@lunn.ch,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
xfr@outlook.com
Subject: Re: [PATCH net-next v5 3/6] net: stmmac: Refactor FPE functions to generic version
Date: Wed, 30 Oct 2024 10:29:35 +0800 [thread overview]
Message-ID: <20241030102935.00005ad5@gmail.com> (raw)
In-Reply-To: <20241029185231.fgy6tofi2uoslp3l@skbuf>
Hi Vladimir,
On Tue, 29 Oct 2024 20:52:31 +0200, Vladimir Oltean <olteanv@gmail.com> wrote:
> Let's not change the output of stmmac_dma_cap_show() sysfs attribute if
> we don't have to. Who knows what depends on that. It's better to
> introduce stmmac_fpe_supported(), which tests for both conditions,
> and use it throughout (except, of course, for the sysfs, which should
> still print the raw DMA capability).
stmmac_fpe_supported() is a better option, thanks.
>
> Which devices would those even be, which support FPE but the driver
> doesn't deal with them (after your XGMAC addition), do you have any idea?
>
Well, nobody can tell that but only Synopsys, as you can see that
stmmac_hwif_entry in hwif.c defines quite a few MAC cores.
Since FPE have been an optional implementation for MAC cores, so I think
we should not convert FPE implementation from optional to mandatory for
new MAC cores, for example, a new MAC support is pending for merge:
https://lore.kernel.org/netdev/20240904054815.1341712-1-jitendra.vegiraju@broadcom.com/
stmmac_fpe_supported() is a perfect option to handle these concerns.
next prev parent reply other threads:[~2024-10-30 2:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 3:07 [PATCH net-next v5 0/6] net: stmmac: Refactor FPE as a separate module Furong Xu
2024-10-28 3:07 ` [PATCH net-next v5 1/6] net: stmmac: Introduce separate files for FPE implementation Furong Xu
2024-10-28 3:07 ` [PATCH net-next v5 2/6] net: stmmac: Rework macro definitions for gmac4 and xgmac Furong Xu
2024-10-28 3:07 ` [PATCH net-next v5 3/6] net: stmmac: Refactor FPE functions to generic version Furong Xu
2024-10-29 18:52 ` Vladimir Oltean
2024-10-30 2:29 ` Furong Xu [this message]
2024-10-28 3:07 ` [PATCH net-next v5 4/6] net: stmmac: xgmac: Rename XGMAC_RQ to XGMAC_FPRQ Furong Xu
2024-10-28 3:07 ` [PATCH net-next v5 5/6] net: stmmac: xgmac: Complete FPE support Furong Xu
2024-10-28 3:07 ` [PATCH net-next v5 6/6] net: stmmac: xgmac: Enable FPE for tc-mqprio/tc-taprio Furong Xu
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=20241030102935.00005ad5@gmail.com \
--to=0x1207@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=joabreu@synopsys.com \
--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=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=xfr@outlook.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.