[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MctRhVzmJwquO5pQDjnNP5HTXrG7qLN7r9Ky+aEuSCBDw@mail.gmail.com>
Date: Thu, 29 Oct 2020 16:44:16 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Mark Brown <broonie@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH] regmap: provide regmap_assign_bits()
On Thu, Oct 29, 2020 at 4:18 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Oct 26, 2020 at 04:10:15PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> >
> > Add another bits helper to regmap API: this one sets given bits if value
> > is true and clears them if it's false.
>
> What's the use case?
>
Basically what the function does: set bits if a condition is true,
clear them if false. I think this is a common enough use-case to
warrant a helper.
> > +static inline int regmap_assign_bits(struct regmap *map, unsigned int reg,
> > + unsigned int bits, bool value)
>
> I don't have a great suggestion but this naming feels prone to confusion
> with _update_bits().
This is already used in bitops - we have set_bit(), clear_bit() and
assign_bit(). People are used to it and I thought I'd stay consistent
with this naming.
Bartosz
Powered by blists - more mailing lists