Re: [PATCH net-next v3 3/8] net: dsa: realtek: common realtek-dsa module

Vladimir Oltean
2024-01-09T12:37:03Z

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?

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?

> > > +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.