mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 --]

  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®