[v2,0/3] gpio: gpio-regmap: Support few custom operations

Support providing some IC specific operations at gpio_regmap registration.

Implementation of few GPIO related functionalities are likely to be
very IC specific. For example the pin-configuration registers and the
pin validity checks. Allow IC driver to provide IC specific functions
which gpio-regmap can utilize for these IC specific configurations.
This should help broaden the gpio-regmap IC coverage without the need
of exposing the registered gpio_chip or struct gpio_regmap to IC drivers.

The set_config and init_valid_mask are used by ROHM BD71815 GPIO driver.
Convert the BD71815 GPIO driver to use gpio-regmap and get rid of some
code. Rest of the ROHM GPIO drivers are to be reworked after the
mechanism of adding IC specific functions is settled.

Some preliminary discussion can be seen here:
https://lore.kernel.org/linux-gpio/c4faac648d3e0c7f3dcb50f7e24c8b322e8c6974.camel@fi.rohmeurope.com/

Changelog v2:
 - Add cover-letter
 - Drop unnecessary checks for callback function validity
 - drop driver_data setting function as it is likely to be a
   race-condition-by-design

---

Matti Vaittinen (3):
  gpio: regmap: Support few IC specific operations
  gpio: gpio-regmap: Use devm_add_action()
  gpio: bd71815: Use gpio-regmap

 drivers/gpio/Kconfig        |   1 +
 drivers/gpio/gpio-bd71815.c | 106 ++++++++++--------------------------
 drivers/gpio/gpio-regmap.c  |  62 ++++++++++++++-------
 include/linux/gpio/regmap.h |  14 ++++-
 4 files changed, 84 insertions(+), 99 deletions(-)


base-commit: d07f6ca923ea0927a1024dfccafc5b53b61cfecc

Am 2021-05-21 12:09, schrieb Andy Shevchenko:
> On Fri, May 21, 2021 at 12:53 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
>> Changelog v2: (based on suggestions by Michael Walle)
>>   - drop gpio_regmap_set_drvdata()
> 
> But why do we have gpio_regmap_get_drvdata() and why is it different
> now to the new member handling?

Eg. the reg_mask_xlate() callback is just passed a "struct 
gpio_regmap*".
If someone needs to access private data there, gpio_regmap_get_drvdata()
is used. At least that was its intention.

Thus I was also suggesting to use "struct gpio_regmap*" in the newer
callbacks.

I don't get what you mean by "different to the new member handling"?

-michael

On Fri, May 21, 2021 at 1:19 PM Michael Walle <michael@walle.cc> wrote:
>
> Am 2021-05-21 12:09, schrieb Andy Shevchenko:
> > On Fri, May 21, 2021 at 12:53 PM Matti Vaittinen
> > <matti.vaittinen@fi.rohmeurope.com> wrote:
> >> Changelog v2: (based on suggestions by Michael Walle)
> >>   - drop gpio_regmap_set_drvdata()
> >
> > But why do we have gpio_regmap_get_drvdata() and why is it different
> > now to the new member handling?
>
> Eg. the reg_mask_xlate() callback is just passed a "struct
> gpio_regmap*".
> If someone needs to access private data there, gpio_regmap_get_drvdata()
> is used. At least that was its intention.
>
> Thus I was also suggesting to use "struct gpio_regmap*" in the newer
> callbacks.
>
> I don't get what you mean by "different to the new member handling"?

Currently we have a symmetrical API that is getter and setter against
a certain field.
Now this change drops the setter and introduces some other field somewhere else.
Sounds to me:
 - either this has to be split into two changes with explanation of
what's going on
 - or something odd is happening here which I do not understand.

On Fri, 2021-05-21 at 14:19 +0300, Andy Shevchenko wrote:
> On Fri, May 21, 2021 at 1:19 PM Michael Walle <michael@walle.cc>

> wrote:

> > Am 2021-05-21 12:09, schrieb Andy Shevchenko:

> > > On Fri, May 21, 2021 at 12:53 PM Matti Vaittinen

> > > <matti.vaittinen@fi.rohmeurope.com> wrote:

> > > > Changelog v2: (based on suggestions by Michael Walle)

> > > >   - drop gpio_regmap_set_drvdata()

> > > 

> > > But why do we have gpio_regmap_get_drvdata() and why is it

> > > different

> > > now to the new member handling?

> > 

> > Eg. the reg_mask_xlate() callback is just passed a "struct

> > gpio_regmap*".

> > If someone needs to access private data there,

> > gpio_regmap_get_drvdata()

> > is used. At least that was its intention.

> > 

> > Thus I was also suggesting to use "struct gpio_regmap*" in the

> > newer

> > callbacks.

> > 

> > I don't get what you mean by "different to the new member

> > handling"?

> 

> Currently we have a symmetrical API that is getter and setter against

> a certain field.

> Now this change drops the setter and introduces some other field

> somewhere else.

> Sounds to me:

>  - either this has to be split into two changes with explanation of

> what's going on

>  - or something odd is happening here which I do not understand.

> 

The rationale beind placing the drvdata pointer / setting in the config
struct is avoiding races in case the drvdata is needed by operations
called during the gpio_chip registration. (If the drvdata is needed for
example at the set_config() or init_valid_mask()). Providing the
drvdata only after we get the gpio_regmap from registration is too
late.

It's actually hard to see am use-case for drvdata where providing it
after gpio registration would not be racy.

Getting the drvdata does not have similar race condition as setting it.
Thus the API for getting it is Ok.

Best Regards
	Matti Vaittinen