linux-kernel - Re: [PATCH 1/2] gpio: regmap: Support few IC specific operations

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: <75c35a7d5561ec3b206351849e2b89f2@walle.cc>
Date:   Fri, 21 May 2021 09:10:57 +0200
From:   Michael Walle <michael@...le.cc>
To:     "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     linux-power <linux-power@...rohmeurope.com>,
        linux-gpio@...r.kernel.org, bgolaszewski@...libre.com,
        linux-kernel@...r.kernel.org, linus.walleij@...aro.org
Subject: Re: [PATCH 1/2] gpio: regmap: Support few IC specific operations

Am 2021-05-20 14:42, schrieb Vaittinen, Matti:
> On Thu, 2021-05-20 at 14:22 +0200, Michael Walle wrote:
>> Am 2021-05-20 14:00, schrieb Matti Vaittinen:
>> > On Thu, 2021-05-20 at 13:42 +0200, Michael Walle wrote:
>> > > Am 2021-05-20 13:28, schrieb Matti Vaittinen:
>> > > > The set_config and init_valid_mask GPIO operations are usually
>> > > > very
>> > > > IC
>> > > > specific. Allow IC drivers to provide these custom operations
>> > > > at
>> > > > gpio-regmap registration.
>> > > >
>> > > > Signed-off-by: Matti Vaittinen <
>> > > > matti.vaittinen@...rohmeurope.com>
>> > > > ---
>> > > >  drivers/gpio/gpio-regmap.c  | 49
>> > > > +++++++++++++++++++++++++++++++++++++
>> > > >  include/linux/gpio/regmap.h | 13 ++++++++++
>> > > >  2 files changed, 62 insertions(+)
>> > > >
>> > > > diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-
>> > > > regmap.c
>> > > > index 134cedf151a7..315285cacd3f 100644
>> > > > --- a/drivers/gpio/gpio-regmap.c
>> > > > +++ b/drivers/gpio/gpio-regmap.c
>> > > > @@ -27,6 +27,10 @@ struct gpio_regmap {
>> > > >  	int (*reg_mask_xlate)(struct gpio_regmap *gpio,
>> > > > unsigned int
>> > > > base,
>> > > >  			      unsigned int offset, unsigned int
>> > > > *reg,
>> > > >  			      unsigned int *mask);
>> > > > +	int (*set_config)(struct regmap *regmap, void *drvdata,
>> > > > +			  unsigned int offset, unsigned long
>> > > > config);
>> > > > +	int (*init_valid_mask)(struct regmap *regmap, void
>> > > > *drvdata,
>> > > > +				unsigned long *valid_mask,
>> > > > unsigned int
>> > > > ngpios);
>> > >
>> > > Maybe we should also make the first argument a "struct
>> > > gpio_regmap"
>> > > and provide a new gpio_regmap_get_regmap(struct gpio_regmap).
>> > > Thus
>> > > having a similar api as for the reg_mask_xlate(). Andy?
>> >
>> > I don't really see the reason of making this any more complicated
>> > for
>> > IC drivers. If we don't open the struct gpio_regmap to IC drivers -
>> > then they never need the struct gpio_regmap pointer itself but each
>> > IC
>> > driver would need to do some unnecessary function call
>> > (gpio_regmap_get_regmap() in this case). I'd say that would be
>> > unnecessary bloat.
>> 
>> If there is ever the need of additional parameters, you'll have to
>> modify that parameter list. Otherwise you'll just have to add a new
>> function. Thus might be more future proof.
> 
> I do hope the "void *drvdata" allows enough flexibility so that there
> is no need to add new parameters.

Thats for information passed from the user of gpio_regmap to the
callbacks.

> And if there is, then I don't see how
> the struct gpio_regmap pointer would have saved us - unless we open the
> contents of struct gpio_regmap to IC drivers. (Which might make sense
> because that already contains plenty of register details which may need
> to be duplicated to drvdata for some IC-specific callbacks. Here we
> again have analogy to regulator_desc - which I have often used also in
> IC-specific custom callbacks. But as long as we hope to keep the struct
> gpio_regmap private I would not add it in arguments).

Because that (opaque) argument is then used for the helper functions
of gpio_regmap.

-michael