From: Daniel Golle <daniel@makrotopia.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Felix Fietkau <nbd@nbd.name>, Sean Wang <sean.wang@mediatek.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net v2 5/5] net: ethernet: mtk_eth_soc: convert cap_bit in mtk_eth_muxc struct to u64
Date: Thu, 17 Apr 2025 16:57:48 +0100 [thread overview]
Message-ID: <aAEk_J9JCi3lkuGD@makrotopia.org> (raw)
In-Reply-To: <20250417081325.0e0345ee@kernel.org>
On Thu, Apr 17, 2025 at 08:13:25AM -0700, Jakub Kicinski wrote:
> On Wed, 16 Apr 2025 01:52:03 +0100 Daniel Golle wrote:
> > The capabilities bitfield was converted to a 64-bit value, but a cap_bit
> > in struct mtk_eth_muxc which is used to store a full bitfield (rather
> > than the bit number, as the name would suggest) still holds only a
> > 32-bit value.
> >
> > Change the type of cap_bit to u64 in order to avoid truncating the
> > bitfield which results in path selection to not work with capabilities
> > above the 32-bit limit.
>
> Could you please be more specific and name a bit or a field that goes
> over 32b? Since this is a fix ideally we'd also have impact to the user
> described in the commit message. But having enough info for the reviewer
> to quickly validate the change is the bare minimum.
I reckon it's too late to include that information in the commit
description. However, let me still illustrate the problem here now:
In mtk_eth_soc.h:
enum mkt_eth_capabilities {
MTK_RGMII_BIT = 0,
MTK_TRGMII_BIT,
MTK_SGMII_BIT,
MTK_USXGMII_BIT,
MTK_2P5GPHY_BIT,
MTK_ESW_BIT,
MTK_GEPHY_BIT,
MTK_MUX_BIT,
MTK_INFRA_BIT,
MTK_SHARED_SGMII_BIT,
MTK_HWLRO_BIT,
MTK_RSS_BIT,
MTK_SHARED_INT_BIT,
MTK_PDMA_INT_BIT,
MTK_TRGMII_MT7621_CLK_BIT,
MTK_QDMA_BIT,
MTK_SOC_MT7628_BIT,
MTK_RSTCTRL_PPE1_BIT,
MTK_RSTCTRL_PPE2_BIT,
MTK_U3_COPHY_V2_BIT,
MTK_SRAM_BIT,
MTK_36BIT_DMA_BIT,
/* MUX BITS*/
MTK_ETH_MUX_GDM1_TO_GMAC1_ESW_BIT,
MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY_BIT,
MTK_ETH_MUX_U3_GMAC2_TO_QPHY_BIT,
MTK_ETH_MUX_GMAC2_TO_2P5GPHY_BIT,
MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII_BIT,
MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII_BIT,
MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII_BIT,
MTK_ETH_MUX_GMAC123_TO_USXGMII_BIT,
/* PATH BITS */
MTK_ETH_PATH_GMAC1_RGMII_BIT,
MTK_ETH_PATH_GMAC1_TRGMII_BIT,
MTK_ETH_PATH_GMAC1_SGMII_BIT,
MTK_ETH_PATH_GMAC2_RGMII_BIT,
MTK_ETH_PATH_GMAC2_SGMII_BIT,
MTK_ETH_PATH_GMAC2_2P5GPHY_BIT,
MTK_ETH_PATH_GMAC2_GEPHY_BIT,
MTK_ETH_PATH_GMAC3_SGMII_BIT,
MTK_ETH_PATH_GDM1_ESW_BIT,
MTK_ETH_PATH_GMAC1_USXGMII_BIT,
MTK_ETH_PATH_GMAC2_USXGMII_BIT,
MTK_ETH_PATH_GMAC3_USXGMII_BIT,
};
...
#define MTK_ETH_MUX_GDM1_TO_GMAC1_ESW \
BIT_ULL(MTK_ETH_MUX_GDM1_TO_GMAC1_ESW_BIT)
#define MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY \
BIT_ULL(MTK_ETH_MUX_GMAC2_GMAC0_TO_GEPHY_BIT)
#define MTK_ETH_MUX_U3_GMAC2_TO_QPHY \
BIT_ULL(MTK_ETH_MUX_U3_GMAC2_TO_QPHY_BIT)
#define MTK_ETH_MUX_GMAC2_TO_2P5GPHY \
BIT_ULL(MTK_ETH_MUX_GMAC2_TO_2P5GPHY_BIT)
#define MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII \
BIT_ULL(MTK_ETH_MUX_GMAC1_GMAC2_TO_SGMII_RGMII_BIT)
#define MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII \
BIT_ULL(MTK_ETH_MUX_GMAC12_TO_GEPHY_SGMII_BIT)
#define MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII \
BIT_ULL(MTK_ETH_MUX_GMAC123_TO_GEPHY_SGMII_BIT)
#define MTK_ETH_MUX_GMAC123_TO_USXGMII \
BIT_ULL(MTK_ETH_MUX_GMAC123_TO_USXGMII_BIT)
The above MTK_ETH_MUX_* macros are the ones used as values for cap_bit in
mtk_eth_path.c.
So technically MTK_ETH_MUX_GMAC123_TO_USXGMII == BIT_ULL(29)
which is still fine for a 32-bit value, but never the less BIT_ULL returns
a 64-bit type and hence using a 32-bit type to store the result is at
least misleading.
However, you are right that with the currently supported SoCs this doesn't
result in an actual bug (but it will with the upcoming addition of newer SoC
like MT7987).
next prev parent reply other threads:[~2025-04-17 15:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 0:50 [PATCH net v2 1/5] net: ethernet: mtk_eth_soc: reapply mdc divider on reset Daniel Golle
2025-04-16 0:51 ` [PATCH net v2 2/5] net: ethernet: mtk_eth_soc: correct the max weight of the queue limit for 100Mbps Daniel Golle
2025-04-16 0:51 ` [PATCH net v2 3/5] net: ethernet: mtk_eth_soc: revise QDMA packet scheduler settings Daniel Golle
2025-04-16 0:51 ` [PATCH net v2 4/5] net: ethernet: mtk_eth_soc: net: revise NETSYSv3 hardware configuration Daniel Golle
2025-04-17 15:10 ` Jakub Kicinski
2025-04-17 15:45 ` Daniel Golle
2025-04-17 15:59 ` Jakub Kicinski
2025-04-17 16:16 ` Daniel Golle
2025-04-16 0:52 ` [PATCH net v2 5/5] net: ethernet: mtk_eth_soc: convert cap_bit in mtk_eth_muxc struct to u64 Daniel Golle
2025-04-17 15:13 ` Jakub Kicinski
2025-04-17 15:57 ` Daniel Golle [this message]
2025-04-17 15:31 ` [PATCH net v2 1/5] net: ethernet: mtk_eth_soc: reapply mdc divider on reset 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=aAEk_J9JCi3lkuGD@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=andrew+netdev@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sean.wang@mediatek.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).