From: Mark Brown <broonie@kernel.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
David Laight <David.Laight@aculab.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [RFT PATCH v2 7/8] gpio: exar: switch to using regmap
Date: Fri, 6 Nov 2020 12:17:15 +0000 [thread overview]
Message-ID: <20201106121715.GA49612@sirena.org.uk> (raw)
In-Reply-To: <CAMRc=Mffr4pn+mnuO6WVP9p3JT-G_t8buJBZMBBRFjQDsfLeuw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]
On Fri, Nov 06, 2020 at 12:13:55PM +0100, Bartosz Golaszewski wrote:
> On Thu, Nov 5, 2020 at 6:41 PM Mark Brown <broonie@kernel.org> wrote:
> > AFAICT (and indeed now I dig around assign_bit() only works on a single
> > bit and does both shifts which makes the correspondance with that
> > interface super unclear, we're not mirroring that interface here). If
> > you're trying to clone the bitops function it should probably be an
> > actual clone of the bitops function not something different, that would
> > be clearer and it'd be easier to understand why someone would want the
> > API in the first place. But perhaps I'm missing something here?
> It's true that bitops set/clear/assign bit macros work on single bits
> and take their offsets as arguments. However all regmap helpers
> operate on masks. Two release cycles back we added two helpers
> regmap_set_bits() and regmap_clear_bits() which are just wrappers
> around regmap_update_bits(). The naming was inspired by bitops
> (because how would one name these operations differently anyway?) but
> it was supposed to be able to clear/set multiple bits at once - at
> least this was my use-case in mtk-star-emac driver I was writing at
> the time and for which I wrote these helpers.
Which is fine and not at all unclear since there's no separate value
argument, the value comes along with the name.
> Now the regmap_assign_bits() helper is just an extension to these two
> which allows users to use one line instead of four. I'm not trying to
> clone bitops - it's just that I don't have a better idea for the
> naming.
I really don't see the benefit to the helper, it makes sense in the
context of bitops where the operation does all the shifting and it's
only a single bit but for regmap where it's dealing with bitmasks as
well and the naming doesn't make it crystal clear I can only see this
being confusing to people. Had the set and clear helpers for regmap
been done as single bits it'd be a lot easier but that's not the case
and it'd also be odd to have just this one helper that took a shift
rather than a bitmask.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-11-06 12:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 19:30 [PATCH v2 0/8] gpio: exar: refactor the driver Bartosz Golaszewski
2020-11-04 19:30 ` [PATCH v2 1/8] regmap: provide regmap_assign_bits() Bartosz Golaszewski
2020-11-04 19:30 ` [PATCH v2 2/8] gpio: exar: add a newline after the copyright notice Bartosz Golaszewski
2020-11-04 19:30 ` [PATCH v2 3/8] gpio: exar: include idr.h Bartosz Golaszewski
2020-11-04 19:30 ` [PATCH v2 4/8] gpio: exar: switch to a simpler IDA interface Bartosz Golaszewski
2020-11-04 19:30 ` [PATCH v2 5/8] gpio: exar: use a helper variable for &pdev->dev Bartosz Golaszewski
2020-11-04 19:30 ` [RFT PATCH v2 6/8] gpio: exar: unduplicate address and offset computation Bartosz Golaszewski
2020-11-04 19:30 ` [RFT PATCH v2 7/8] gpio: exar: switch to using regmap Bartosz Golaszewski
2020-11-04 20:35 ` Andy Shevchenko
2020-11-05 8:56 ` Bartosz Golaszewski
2020-11-05 17:40 ` Mark Brown
2020-11-06 11:13 ` Bartosz Golaszewski
2020-11-06 12:17 ` Mark Brown [this message]
2020-11-04 19:30 ` [PATCH v2 8/8] gpio: exar: use devm action for freeing the IDA and drop remove() Bartosz Golaszewski
2020-11-04 20:36 ` [PATCH v2 0/8] gpio: exar: refactor the driver 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=20201106121715.GA49612@sirena.org.uk \
--to=broonie@kernel.org \
--cc=David.Laight@aculab.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=jan.kiszka@siemens.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®