From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Cc: Linus Walleij <linusw@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
Kent Gibson <warthog618@gmail.com>,
Adrian Ambrozewicz <aambrozewicz@nvidia.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2 5/5] gpio: cdev: don't overwrite the whole flags field when configuring lines
Date: Mon, 9 Nov 2026 23:58:41 +0200 [thread overview]
Message-ID: <avJCETUZidpmICKR@ashevche-desk.local> (raw)
In-Reply-To: <20261109-gpio-desc-flags-atomic-v2-5-c4c54b476628@oss.qualcomm.com>
On Mon, Nov 09, 2026 at 11:27:09AM +0100, Bartosz Golaszewski wrote:
> linehandle_flags_to_desc_flags() and
> gpio_v2_line_config_flags_to_desc_flags() read the flags word with
> READ_ONCE(), modify the local copy and write it back with WRITE_ONCE().
>
> The per-request config_mutex does not exclude sysfs, the irq core or
> drivers touching the same descriptor, so bits they set or clear
> concurrently can be lost.
>
> Build the mask of bits owned by the line configuration and their new
> values locally and apply them with gpiod_update_flags(). The whole
> group changes in a single atomic step.
>
> While at it: rename the functions whose semantics changed from
> "conversion" to "flags update" accordingly.
...
> @@ -3,6 +3,7 @@
> #include <linux/anon_inodes.h>
> #include <linux/atomic.h>
> #include <linux/bitmap.h>
> +#include <linux/bitops.h>
> #include <linux/build_bug.h>
> #include <linux/cdev.h>
> #include <linux/cleanup.h>
Unneeded hunk as explained in the previous reply.
...
> -static void linehandle_flags_to_desc_flags(u32 lflags, unsigned long *flagsp)
> +static void linehandle_update_desc_flags(u32 lflags, struct gpio_desc *desc)
> {
> - unsigned long flags = READ_ONCE(*flagsp);
> + const unsigned long mask = BIT(GPIOD_FLAG_ACTIVE_LOW) |
> + BIT(GPIOD_FLAG_OPEN_DRAIN) |
> + BIT(GPIOD_FLAG_OPEN_SOURCE) |
> + BIT(GPIOD_FLAG_PULL_UP) |
> + BIT(GPIOD_FLAG_PULL_DOWN) |
> + BIT(GPIOD_FLAG_BIAS_DISABLE);
Usually we don't do such an assignments in the definition blocks.
I believe the split will look better.
> + unsigned long flags = 0;
>
mask = ...;
(and with longer line you may combine close bits, like OD/OS or PD,PU, and
DISABLE).
> - assign_bit(GPIOD_FLAG_ACTIVE_LOW, &flags,
> - lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW);
> - assign_bit(GPIOD_FLAG_OPEN_DRAIN, &flags,
> - lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN);
> - assign_bit(GPIOD_FLAG_OPEN_SOURCE, &flags,
> - lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE);
> - assign_bit(GPIOD_FLAG_PULL_UP, &flags,
> - lflags & GPIOHANDLE_REQUEST_BIAS_PULL_UP);
> - assign_bit(GPIOD_FLAG_PULL_DOWN, &flags,
> - lflags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN);
> - assign_bit(GPIOD_FLAG_BIAS_DISABLE, &flags,
> - lflags & GPIOHANDLE_REQUEST_BIAS_DISABLE);
> + __assign_bit(GPIOD_FLAG_ACTIVE_LOW, &flags,
> + lflags & GPIOHANDLE_REQUEST_ACTIVE_LOW);
> + __assign_bit(GPIOD_FLAG_OPEN_DRAIN, &flags,
> + lflags & GPIOHANDLE_REQUEST_OPEN_DRAIN);
> + __assign_bit(GPIOD_FLAG_OPEN_SOURCE, &flags,
> + lflags & GPIOHANDLE_REQUEST_OPEN_SOURCE);
> + __assign_bit(GPIOD_FLAG_PULL_UP, &flags,
> + lflags & GPIOHANDLE_REQUEST_BIAS_PULL_UP);
> + __assign_bit(GPIOD_FLAG_PULL_DOWN, &flags,
> + lflags & GPIOHANDLE_REQUEST_BIAS_PULL_DOWN);
> + __assign_bit(GPIOD_FLAG_BIAS_DISABLE, &flags,
> + lflags & GPIOHANDLE_REQUEST_BIAS_DISABLE);
...
> +static void linereq_update_desc_flags(u64 lflags,
> + struct gpio_desc *desc)
This is ugliest part of this patch in my opinion. Just make it a single line.
`clang-format` is in use I assume?
...
> + const unsigned long mask = BIT(GPIOD_FLAG_ACTIVE_LOW) |
> + BIT(GPIOD_FLAG_EDGE_RISING) |
> + BIT(GPIOD_FLAG_EDGE_FALLING) |
> + BIT(GPIOD_FLAG_OPEN_DRAIN) |
> + BIT(GPIOD_FLAG_OPEN_SOURCE) |
> + BIT(GPIOD_FLAG_PULL_UP) |
> + BIT(GPIOD_FLAG_PULL_DOWN) |
> + BIT(GPIOD_FLAG_BIAS_DISABLE) |
> + BIT(GPIOD_FLAG_EVENT_CLOCK_REALTIME) |
> + BIT(GPIOD_FLAG_EVENT_CLOCK_HTE);
Same comment as before.
> + unsigned long flags = 0;
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2026-11-09 21:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 10:27 [PATCH v2 0/5] gpiolib: improve concurrent access to the flags field of struct gpio_desc Bartosz Golaszewski
2026-11-09 10:27 ` [PATCH v2 1/5] gpiolib: don't overwrite the entire flags field in gpiod_get_direction() Bartosz Golaszewski
2026-11-09 10:27 ` [PATCH v2 2/5] gpio: shared: use atomic set_bit() for descriptor flags Bartosz Golaszewski
2026-11-09 10:34 ` sashiko-bot
2026-11-09 10:27 ` [PATCH v2 3/5] gpiolib: clear debounce period before the "requested" flag Bartosz Golaszewski
2026-11-09 10:37 ` sashiko-bot
2026-11-09 10:27 ` [PATCH v2 4/5] gpiolib: don't overwrite the entire flags field in gpiod_free_commit() Bartosz Golaszewski
2026-11-09 10:32 ` sashiko-bot
2026-11-09 21:53 ` Andy Shevchenko
2026-11-10 8:54 ` Bartosz Golaszewski
2026-11-10 10:06 ` Andy Shevchenko
2026-11-10 11:05 ` Joshua Crofts
2026-11-09 10:27 ` [PATCH v2 5/5] gpio: cdev: don't overwrite the whole flags field when configuring lines Bartosz Golaszewski
2026-11-09 21:58 ` Andy Shevchenko [this message]
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=avJCETUZidpmICKR@ashevche-desk.local \
--to=andriy.shevchenko@linux.intel.com \
--cc=aambrozewicz@nvidia.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=warthog618@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.