Message-ID: <CAJq09z6JF0K==fO53RcimoRgujHjEkvmDKWGK3pYQAig58j__g@mail.gmail.com>
Date: Thu, 11 Jan 2024 03:20:10 -0300
From: Luiz Angelo Daros de Luca <luizluca@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, linus.walleij@...aro.org, alsi@...g-olufsen.dk, 
	andrew@...n.ch, f.fainelli@...il.com, davem@...emloft.net, 
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	arinc.unal@...nc9.com
Subject: Re: [PATCH net-next v3 3/8] net: dsa: realtek: common realtek-dsa module

> On Tue, Jan 09, 2024 at 02:05:29AM -0300, Luiz Angelo Daros de Luca wrote:
> > > > +struct realtek_priv *
> > > > +realtek_common_probe(struct device *dev, struct regmap_config rc,
> > > > +                  struct regmap_config rc_nolock)
> > >
> > > Could you use "const struct regmap_config *" as the data types here, to
> > > avoid two on-stack variable copies? Regmap will copy the config structures
> > > anyway.
> >
> > I could do that for rc_nolock but not for rc as we need to modify it
> > before passing to regmap. I would still need to duplicate rc, either
> > using the stack or heap. What would be the best option?
> >
> > 1) pass two pointers and copy one to stack
> > 2) pass two pointers and copy one to heap
> > 3) pass two structs (as it is today)
> > 4) pass one pointer and one struct
> >
> > The old code was using 1) and I'm inclined to adopt it and save a
> > hundred and so bytes from the stack, although 2) would save even more.
>
> I didn't notice the "rc.lock_arg = priv" assignment...
>
> I'm not sure what you mean by "copy to heap". Perform a dynamic memory
> allocation?

Yes. However, I guess the stack can handle that structure in this context.

> Also, the old code was not using exactly 1). It copied both the normal
> and the nolock regmap config to an on-stack local variable, even though
> only the normal regmap config had to be copied (to be fixed up).
>
> I went back to study the 4 regmap configs, and only the reg_read() and
> reg_write() methods differ between SMI and MDIO. The rest seems boilerplate
> that can be dynamically constructed by realtek_common_probe(). Sure,
> spelling out 4 regmap_config structures is more flexible, but do we need
> that flexibility? What if realtek_common_probe() takes just the
> reg_read() and reg_write() function prototypes as arguments, rather than
> pointers to regmap_config structures it then has to fix up?

IMHO, the constant regmap_config looks cleaner than a sequence of
assignments. However, we don't actually need 4 of them.
As we already have a writable regmap_config in stack (to assign
lock_arg), we can reuse the same struct and simply set
disable_locking.
It makes the regmap ignore all locking fields and we don't even need
to unset them for map_nolock. Something like this:

realtek_common_probe(struct device *dev, const struct regmap_config *rc_base)
{

       (...)

       rc = *rc_base;
       rc.lock_arg = priv;
       priv->map = devm_regmap_init(dev, NULL, priv, &rc);
       if (IS_ERR(priv->map)) {
               ret = PTR_ERR(priv->map);
               dev_err(dev, "regmap init failed: %d\n", ret);
               return ERR_PTR(ret);
       }

       rc.disable_locking = true;
       priv->map_nolock = devm_regmap_init(dev, NULL, priv, &rc);
       if (IS_ERR(priv->map_nolock)) {
               ret = PTR_ERR(priv->map_nolock);
               dev_err(dev, "regmap init failed: %d\n", ret);
               return ERR_PTR(ret);
       }

It has a cleaner function signature and we can remove the _nolock
constants as well.

The regmap configs still have some room for improvement, like moving
from interfaces to variants, but this series is already too big. We
can leave that as it is.

> > > > +EXPORT_SYMBOL(realtek_common_probe);
> > > > diff --git a/drivers/net/dsa/realtek/realtek.h b/drivers/net/dsa/realtek/realtek.h
> > > > index e9ee778665b2..fbd0616c1df3 100644
> > > > --- a/drivers/net/dsa/realtek/realtek.h
> > > > +++ b/drivers/net/dsa/realtek/realtek.h
> > > > @@ -58,11 +58,9 @@ struct realtek_priv {
> > > >       struct mii_bus          *bus;
> > > >       int                     mdio_addr;
> > > >
> > > > -     unsigned int            clk_delay;
> > > > -     u8                      cmd_read;
> > > > -     u8                      cmd_write;
> > > >       spinlock_t              lock; /* Locks around command writes */
> > > >       struct dsa_switch       *ds;
> > > > +     const struct dsa_switch_ops *ds_ops;
> > > >       struct irq_domain       *irqdomain;
> > > >       bool                    leds_disabled;
> > > >
> > > > @@ -79,6 +77,8 @@ struct realtek_priv {
> > > >       int                     vlan_enabled;
> > > >       int                     vlan4k_enabled;
> > > >
> > > > +     const struct realtek_variant *variant;
> > > > +
> > > >       char                    buf[4096];
> > > >       void                    *chip_data; /* Per-chip extra variant data */
> > > >  };
> > >
> > > Can the changes to struct realtek_priv be a separate patch, to
> > > clarify what is being changed, and to leave the noisy code movement
> > > more isolated?
> >
> > Sure, although it will not be a patch that makes sense by itself. If
> > it helps with the review, I'll split it. We can fold it back if
> > needed.
>
> Well, I don't mean only the changes to the private structure, but also
> the code changes that accompany them.
>
> As Andrew usually says, what you want is lots of small patches that are
> each obviously correct, where there is only one thing being changed.
> Code movement with small renames is trivial to review. Consolidation of
> two identical code paths in a single function is also possible to follow.
> The insertion of a new variable and its usage is also easy to review.
> The removal of a variable, the same. But superimposing them all into a
> single patch makes everything much more difficult to follow.

This case in particular might be hard to justify in the commit message
other than "preliminary work". I'll split it as it makes review much
easier. this series will grow from 7 to 10 patches, even after
dropping the revert patch.

Regards,

Luiz

Powered by blists - more mailing lists