From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>,
Daniel Golle <daniel@makrotopia.org>,
Landen Chao <Landen.Chao@mediatek.com>,
DENG Qingfang <dqfext@gmail.com>,
Sean Wang <sean.wang@mediatek.com>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Frank Wunderlich <frank-w@public-files.de>,
Bartel Eerdekens <bartel.eerdekens@constell8.be>,
mithat.guner@xeront.com, erkin.bozoglu@xeront.com
Subject: Re: [PATCH net-next 01/15] net: dsa: mt7530: always trap frames to active CPU port on MT7530
Date: Sun, 17 Dec 2023 14:39:46 +0300 [thread overview]
Message-ID: <f830ac10-8ab3-4660-8e9f-762bb41aca78@arinc9.com> (raw)
In-Reply-To: <20231207174829.jccyws7myhxbgr5k@skbuf>
On 7.12.2023 20:48, Vladimir Oltean wrote:
> On Sat, Dec 02, 2023 at 11:29:18AM +0300, Arınç ÜNAL wrote:
>>>> struct mt7530_priv {
>>>> struct device *dev;
>>>> @@ -786,6 +787,7 @@ struct mt7530_priv {
>>>> struct irq_domain *irq_domain;
>>>> u32 irq_enable;
>>>> int (*create_sgmii)(struct mt7530_priv *priv, bool dual_sgmii);
>>>> + unsigned long active_cpu_ports;
>>>
>>> So this will be 32 or 64 bit in size. Presumably you know how many CPU
>>> ports there can be, which looking at this code must be less than 8 as
>>> CPU_PORT_MASK is only 3 bits in size. So, maybe use a u8, and check
>>> that cpu_dp->index <= 7 ?
>
> We picked "unsigned long" as storage because that's also the size of the
> argument that __ffs() takes. But admittedly, we could have also stored a
> smaller variable and promote it to unsigned long when we pass it to __ffs().
>
>> Aren't there other mechanisms to check that cpu_dp->index is a valid port?
>
> cpu_dp->index is guaranteed by DSA to be valid (according to the "reg"
> value from the device tree and smaller than ds->num_ports). It's just a
> question of balancing this kind of optimization with the possibility
> that a future switch appears which has more than MT7530_NUM_PORTS (7) ports.
If this was to happen - as unlikely as I find it - I would suggest adding a
new MTXXXX_NUM_PORTS and set priv->ds->num_ports to it after checking
priv->id. I'm a maintainer here so I'll keep an eye out.
>
>>
>> mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
>> }
>>
>> struct mt7530_priv {
>> [...]
>> u8 active_cpu_ports;
>> };
>
> Actually, looking at the code now, I don't understand why we even keep
> track of the active_cpu_ports mask in the driver. We could read the
> MT7530_MFC register in mt753x_conduit_state_change(), flip the bit
> corresponding just to cpu_dp->index (rather than rmw all of CPU_PORT_MASK),
> and write back the result. And to address Russell's concern, we could test
> whether the resulting CPU_PORT_MASK portion of what we're going to write
> back is all-zeroes or not, and if it is, clear the CPU_EN bit, otherwise
> set it.
Correct me if I'm wrong, we introduced priv->active_cpu_ports because
CPU_PORT_MASK from the MT7530_MFC register is a 3-bit mask, meant to keep a
single port number ranging from 0 to 7. There's no single bit corresponding
to cpu_dp->index on the MT7530_MFC register. So I don't see how what you
suggest here would work.
This is what I've got right now:
static void
mt753x_conduit_state_change(struct dsa_switch *ds,
const struct net_device *conduit,
bool operational)
{
struct dsa_port *cpu_dp = conduit->dsa_ptr;
struct mt7530_priv *priv = ds->priv;
u8 mask;
int val = 0;
/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
* forwarded to the numerically smallest CPU port which the DSA conduit
* interface its affine to is up.
*/
if (priv->id != ID_MT7530 && priv->id != ID_MT7621)
return;
mask = BIT(cpu_dp->index);
if (operational)
priv->active_cpu_ports |= mask;
else
priv->active_cpu_ports &= ~mask;
if (priv->active_cpu_ports)
val =
CPU_EN |
CPU_PORT(__ffs((unsigned long)priv->active_cpu_ports));
mt7530_rmw(priv, MT7530_MFC, CPU_EN | CPU_PORT_MASK, val);
}
>
>>
>>>
>>> I would also suggest moving irq_enable after create_sgmii, to avoid
>>> holes in the struct.
>>
>> Sorry, I've got no idea about this. Could you explain why would there
>> possibly be holes in the struct with the current ordering of the members of
>> the mt7530_priv structure?
>>
>> Arınç
>
> FWIW:
>
> $ pahole -C mt7530_priv $KBUILD_OUTPUT/drivers/net/dsa/mt7530.o
> struct mt7530_priv {
> struct device * dev; /* 0 8 */
> struct dsa_switch * ds; /* 8 8 */
> struct mii_bus * bus; /* 16 8 */
> struct regmap * regmap; /* 24 8 */
> struct reset_control * rstc; /* 32 8 */
> struct regulator * core_pwr; /* 40 8 */
> struct regulator * io_pwr; /* 48 8 */
> struct gpio_desc * reset; /* 56 8 */
> /* --- cacheline 1 boundary (64 bytes) --- */
> const struct mt753x_info * info; /* 64 8 */
> unsigned int id; /* 72 4 */
> bool mcm; /* 76 1 */
>
> /* XXX 3 bytes hole, try to pack */
>
> phy_interface_t p6_interface; /* 80 4 */
> phy_interface_t p5_interface; /* 84 4 */
> unsigned int p5_intf_sel; /* 88 4 */
> u8 mirror_rx; /* 92 1 */
> u8 mirror_tx; /* 93 1 */
>
> /* XXX 2 bytes hole, try to pack */
>
> struct mt7530_port ports[7]; /* 96 168 */
> /* --- cacheline 4 boundary (256 bytes) was 8 bytes ago --- */
> struct mt753x_pcs pcs[7]; /* 264 280 */
> /* --- cacheline 8 boundary (512 bytes) was 32 bytes ago --- */
> struct mutex reg_mutex; /* 544 32 */
> /* --- cacheline 9 boundary (576 bytes) --- */
> int irq; /* 576 4 */
>
> /* XXX 4 bytes hole, try to pack */
>
> struct irq_domain * irq_domain; /* 584 8 */
> u32 irq_enable; /* 592 4 */
>
> /* XXX 4 bytes hole, try to pack */
>
> int (*create_sgmii)(struct mt7530_priv *, bool); /* 600 8 */
> unsigned long active_cpu_ports; /* 608 8 */
>
> /* size: 616, cachelines: 10, members: 24 */
> /* sum members: 603, holes: 4, sum holes: 13 */
> /* last cacheline: 40 bytes */
> };
>
> It's not like this makes any practical difference, as struct mt7530_priv
> isn't used from hot paths, but tidying it up is a good sign of clean,
> careful development, and of understanding memory alignment.
Got it, thanks. I've got a few patches that introduce changes to the
mt7530_priv structure. I'll make sure that, in the end, mt7530_priv won't
have any holes.
Arınç
next prev parent reply other threads:[~2023-12-17 11:40 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-18 12:31 [PATCH net-next 00/15] MT7530 DSA subdriver improvements Arınç ÜNAL
2023-11-18 12:31 ` [PATCH net-next 01/15] net: dsa: mt7530: always trap frames to active CPU port on MT7530 Arınç ÜNAL
2023-11-18 14:34 ` Russell King (Oracle)
2023-12-02 8:29 ` Arınç ÜNAL
2023-12-07 17:48 ` Vladimir Oltean
2023-12-17 11:39 ` Arınç ÜNAL [this message]
2023-11-19 12:25 ` Vladimir Oltean
2023-11-18 12:31 ` [PATCH net-next 02/15] net: dsa: mt7530: use p5_interface_select as data type for p5_intf_sel Arınç ÜNAL
2023-11-19 14:40 ` Vladimir Oltean
2023-11-18 12:31 ` [PATCH net-next 03/15] net: dsa: mt7530: store port 5 SGMII capability of MT7531 Arınç ÜNAL
2023-11-19 14:50 ` Vladimir Oltean
2023-11-18 12:31 ` [PATCH net-next 04/15] net: dsa: mt7530: improve comments regarding port 5 and 6 Arınç ÜNAL
2023-11-18 12:31 ` [PATCH net-next 05/15] net: dsa: mt7530: improve code path for setting up port 5 Arınç ÜNAL
2023-11-18 14:41 ` Russell King (Oracle)
2023-12-02 8:36 ` Arınç ÜNAL
2023-12-07 18:03 ` Vladimir Oltean
2023-12-17 12:01 ` Arınç ÜNAL
2023-11-18 12:31 ` [PATCH net-next 06/15] net: dsa: mt7530: do not set priv->p5_interface on mt7530_setup_port5() Arınç ÜNAL
2023-12-07 18:18 ` Vladimir Oltean
2023-12-17 12:42 ` Arınç ÜNAL
2023-11-18 12:31 ` [PATCH net-next 07/15] net: dsa: mt7530: do not run mt7530_setup_port5() if port 5 is disabled Arınç ÜNAL
2023-11-21 18:53 ` Simon Horman
2023-12-02 8:45 ` Arınç ÜNAL
2023-12-02 9:30 ` Russell King (Oracle)
2023-12-06 21:46 ` Simon Horman
2023-12-07 6:51 ` Dan Carpenter
2023-12-07 18:40 ` Vladimir Oltean
2023-12-07 20:01 ` Vladimir Oltean
2023-12-08 4:23 ` Dan Carpenter
2023-12-08 18:46 ` Vladimir Oltean
2023-12-17 12:22 ` Arınç ÜNAL
2024-01-02 11:16 ` Dan Carpenter
2024-01-06 18:01 ` Arınç ÜNAL
2024-01-09 14:57 ` Vladimir Oltean
2024-01-10 7:26 ` Arınç ÜNAL
2024-01-10 18:23 ` Vladimir Oltean
2024-01-11 10:22 ` Arınç ÜNAL
2024-01-11 10:31 ` Vladimir Oltean
2024-01-11 10:35 ` Frank Wunderlich
2024-01-11 10:59 ` Arınç ÜNAL
2023-11-18 12:31 ` [PATCH net-next 08/15] net: dsa: mt7530: empty default case on mt7530_setup_port5() Arınç ÜNAL
2023-11-18 12:31 ` [PATCH net-next 09/15] net: dsa: mt7530: call port 6 setup from mt7530_mac_config() Arınç ÜNAL
2023-11-18 13:12 ` [PATCH net-next 10/15] net: dsa: mt7530: remove pad_setup function pointer Arınç ÜNAL
2023-11-18 13:13 ` [PATCH net-next 11/15] net: dsa: mt7530: move XTAL check to mt7530_setup() Arınç ÜNAL
2023-11-18 13:13 ` [PATCH net-next 12/15] net: dsa: mt7530: move enabling port 6 to mt7530_setup_port6() Arınç ÜNAL
2023-11-18 13:13 ` [PATCH net-next 13/15] net: dsa: mt7530: simplify mt7530_setup_port6() and change to void Arınç ÜNAL
2023-11-18 13:13 ` [PATCH net-next 14/15] net: dsa: mt7530: correct port capabilities of MT7988 Arınç ÜNAL
2023-11-18 13:13 ` [PATCH net-next 15/15] net: dsa: mt7530: do not clear config->supported_interfaces Arınç ÜNAL
2023-12-02 8:52 ` [PATCH net-next 00/15] MT7530 DSA subdriver improvements Arınç ÜNAL
2023-12-13 15:19 ` Vladimir Oltean
2023-12-13 16:51 ` Arınç ÜNAL
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=f830ac10-8ab3-4660-8e9f-762bb41aca78@arinc9.com \
--to=arinc.unal@arinc9.com \
--cc=Landen.Chao@mediatek.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bartel.eerdekens@constell8.be \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=erkin.bozoglu@xeront.com \
--cc=f.fainelli@gmail.com \
--cc=frank-w@public-files.de \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=mithat.guner@xeront.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--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
all inboxes | Powered by JetHome®