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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240109123658.vqftnqsxyd64ik52@skbuf>
Date: Tue, 9 Jan 2024 14:36:58 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Luiz Angelo Daros de Luca <luizluca@...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?

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.