linux-kernel - Re: [PATCH 1/8] mfd: ocelot: refactor bus-specific regmap initialization

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87r02qeexm.fsf@prevas.dk>
Date: Fri, 21 Mar 2025 13:39:01 +0100
From: Rasmus Villemoes <ravi@...vas.dk>
To: Lee Jones <lee@...nel.org>
Cc: Colin Foster <colin.foster@...advantage.com>,
  linux-kernel@...r.kernel.org,  devicetree@...r.kernel.org,  Felix Blix
 Everberg <felix.blix@...vas.dk>
Subject: Re: [PATCH 1/8] mfd: ocelot: refactor bus-specific regmap
 initialization

On Fri, Mar 21 2025, Lee Jones <lee@...nel.org> wrote:

> On Wed, 19 Mar 2025, Colin Foster wrote:
>
>> On Wed, Mar 19, 2025 at 01:30:51PM +0100, Rasmus Villemoes wrote:
>> > diff --git a/drivers/mfd/ocelot-core.c b/drivers/mfd/ocelot-core.c
>> > index 41aff27088548..78b5fe15efdd2 100644
>> > --- a/drivers/mfd/ocelot-core.c
>> > +++ b/drivers/mfd/ocelot-core.c
>> > @@ -200,10 +200,12 @@ static const struct mfd_cell vsc7512_devs[] = {
>> >  static void ocelot_core_try_add_regmap(struct device *dev,
>> >                                        const struct resource *res)
>> >  {
>> > +       struct ocelot_ddata *ddata = dev_get_drvdata(dev);
>> > +
>> >         if (dev_get_regmap(dev, res->name))
>> >                 return;
>> > 
>> > -       ocelot_spi_init_regmap(dev, res);
>> > +       ddata->init_regmap(dev, res);
>> 
>> I remember changing this from function pointers to the direct function
>> call during initial development, per Lee's suggestion. I like it though,
>> and I'm glad to see multiple users now.
>
> Yeah, we're still not going to be putting call-backs into device data.

OK. Can you explain why that is such a bad design?

> Either pass the differentiating config through to the core driver

So you mean something like defining a new struct ocelot_backend_ops { } with
those function pointers, and pass an instance of that to
ocelot_core_init (and from there down to the static helper functions)?
That should be doable.

> or handle the differentiation inside the *-i2c.c / *-spi.c files.

I really fail to see how that could be done. Currently, the core file
has a hard-coded call of ocelot_spi_init_regmap(). I don't suppose you
mean to teach that function to realize "hey, this struct device is not
really a struct spi_device, let's delegate to ocelot_mdio_init_regmap()
instead". So _somehow_ the core will need to know to call one or the
other init_regmap implementation. I could add some "enum ocelot_type"
and switch on that and then call the appropriate bus-specific function,
but that's morally equivalent to having the function pointers.

Thanks,
Rasmus