From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
"michael@walle.cc" <michael@walle.cc>
Cc: linux-power <linux-power@fi.rohmeurope.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>
Subject: Re: [PATCH v2 1/3] gpio: regmap: Support few IC specific operations
Date: Fri, 21 May 2021 11:41:41 +0000 [thread overview]
Message-ID: <236f3000b2bf90a626c77582c30cf5c62fe4d6ce.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <CAHp75VdbomvbAY42Bje7F8qjWfgeSnU8i2ULJRXpYKA+oTmwrg@mail.gmail.com>
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
next prev parent reply other threads:[~2021-05-21 11:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 6:27 [PATCH v2 0/3] gpio: gpio-regmap: Support few custom operations Matti Vaittinen
2021-05-21 6:27 ` [PATCH v2 1/3] gpio: regmap: Support few IC specific operations Matti Vaittinen
2021-05-21 8:04 ` Michael Walle
2021-05-21 10:09 ` Andy Shevchenko
2021-05-21 10:19 ` Michael Walle
2021-05-21 10:25 ` Vaittinen, Matti
2021-05-21 10:46 ` Michael Walle
2021-05-21 11:36 ` Vaittinen, Matti
2021-05-21 11:19 ` Andy Shevchenko
2021-05-21 11:41 ` Vaittinen, Matti [this message]
2021-05-21 10:20 ` Vaittinen, Matti
2021-05-21 6:28 ` [PATCH v2 2/3] gpio: gpio-regmap: Use devm_add_action() Matti Vaittinen
2021-05-21 8:10 ` Michael Walle
2021-05-21 8:38 ` Bjørn Mork
2021-05-21 10:30 ` Vaittinen, Matti
2021-05-21 16:35 ` Bartosz Golaszewski
2021-05-24 5:01 ` Vaittinen, Matti
2021-05-21 10:10 ` Andy Shevchenko
2021-05-21 6:29 ` [PATCH v2 3/3] gpio: bd71815: Use gpio-regmap Matti Vaittinen
2021-05-21 10:12 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=236f3000b2bf90a626c77582c30cf5c62fe4d6ce.camel@fi.rohmeurope.com \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=andy.shevchenko@gmail.com \
--cc=bgolaszewski@baylibre.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-power@fi.rohmeurope.com \
--cc=michael@walle.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).