This may be a total corner-case but for consistency and completeness I
think it makes sense to also send out line state change events on actions
triggered from the GPIO sysfs class.

The first two patches use cleanup helpers in sysfs code. The next three
change the code to emit notifications on line export (unexport is
already handled) and active_low & edge changes.

One last thing I considered was also notifying user-space whenever
gpiochip_un/lock_as_irq() is called but that doesn't make much sense as
it's largely independent from the GPIO core and can be called for both
requested and available lines whenever someone requests an interrupt
from a GPIO controller.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Changes in v4:
- don't use __free() in patch 2/5 as it causes issues when we jump over
  the initialization of the managed pointer
- Link to v3: https://lore.kernel.org/r/20241026-gpio-notify-sysfs-v3-0-ad8f127d12f5@linaro.org

Changes in v3:
- Keep the unusual order of operations in value_store()
- Link to v2: https://lore.kernel.org/r/20241025-gpio-notify-sysfs-v2-0-5bd1b1b0b3e6@linaro.org

Changes in v2:
- Streamline the code even more by dropping unnecessary return code
  assignments
- use normal guards where scoped ones are overkill
- Link to v1: https://lore.kernel.org/r/20241024-gpio-notify-sysfs-v1-0-981f2773e785@linaro.org

---
Bartosz Golaszewski (5):
      gpio: sysfs: use cleanup guards for gpiod_data::mutex
      gpio: sysfs: use cleanup guards for the sysfs_lock mutex
      gpio: sysfs: emit chardev line-state events on GPIO export
      gpio: sysfs: emit chardev line-state events on active-low changes
      gpio: sysfs: emit chardev line-state events on edge store

 drivers/gpio/gpiolib-sysfs.c | 161 +++++++++++++++++++------------------------
 1 file changed, 72 insertions(+), 89 deletions(-)
---
base-commit: f9f24ca362a4d84dd8aeb4b8f3ec28cb6c43dd06
change-id: 20241022-gpio-notify-sysfs-3bddf9ecca9f

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Thu, 31 Oct 2024 21:01:50 +0100, Bartosz Golaszewski wrote:
> This may be a total corner-case but for consistency and completeness I
> think it makes sense to also send out line state change events on actions
> triggered from the GPIO sysfs class.
> 
> The first two patches use cleanup helpers in sysfs code. The next three
> change the code to emit notifications on line export (unexport is
> already handled) and active_low & edge changes.
> 
> [...]

Applied, thanks!

[1/5] gpio: sysfs: use cleanup guards for gpiod_data::mutex
      commit: d99c980cfe9423cd1ac719a73ae52437da29a45e
[2/5] gpio: sysfs: use cleanup guards for the sysfs_lock mutex
      commit: f4af1671c28854bb0a400740a9c6ebacb8b9aa6b
[3/5] gpio: sysfs: emit chardev line-state events on GPIO export
      commit: 285678c947197b0a071328f9344b0312e5545e92
[4/5] gpio: sysfs: emit chardev line-state events on active-low changes
      commit: 5a7119e0d951fdf7ebcc25a77565ac184798639a
[5/5] gpio: sysfs: emit chardev line-state events on edge store
      commit: 7b925098c937599c8ad1bc757db80743a990f57e

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

On Thu, Oct 31, 2024 at 09:01:50PM +0100, Bartosz Golaszewski wrote:
> This may be a total corner-case but for consistency and completeness I
> think it makes sense to also send out line state change events on actions
> triggered from the GPIO sysfs class.
>
> The first two patches use cleanup helpers in sysfs code. The next three
> change the code to emit notifications on line export (unexport is
> already handled) and active_low & edge changes.
>
> One last thing I considered was also notifying user-space whenever
> gpiochip_un/lock_as_irq() is called but that doesn't make much sense as
> it's largely independent from the GPIO core and can be called for both
> requested and available lines whenever someone requests an interrupt
> from a GPIO controller.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Looks good to me, though I'm sure there are a few places Andy would like
to tidy up the ret/error handling :).

Reviewed-by: Kent Gibson <warthog618@gmail.com>

Cheers,
Kent.