mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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ç

  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®