On Fri, 2021-05-21 at 14:19 +0300, Andy Shevchenko wrote:

On Fri, May 21, 2021 at 1:19 PM Michael Walle [off-list ref]
wrote:

quoted

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

quoted

On Fri, May 21, 2021 at 12:53 PM Matti Vaittinen
[off-list ref] wrote:

quoted

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