Many drivers repeat the same boilerplate when registering notifiers with
device lifetime:
1. Register the notifier with *_notifier_chain_register()
2. Check for error
3. Register a devm action to unregister on teardown
4. Implement a per-driver static unregister callback
This series adds devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound, then converts 11 drivers to use
them.
Each conversion eliminates a per-driver unregister callback and the
associated devm_add_action_or_reset() call, reducing code by ~15 lines
per driver.
The implementation follows the established devres pattern used by other
device-managed kernel APIs.
Changes in v5:
- Patch 1: rename notifier_block parameter from 'n' to 'nb' to match
the devres struct field name (Uwe Kleine-König)
- Patch 2: remove extra blank line left after deleting the unregister
callback (Uwe Kleine-König)
Changes in v4:
- Patch 8: split the removal of unused
ghes_register_vendor_record_notifier() and
ghes_unregister_vendor_record_notifier() into a separate preceding
patch (Andy Shevchenko)
Changes in v3:
- Patch 1: drop devm_raw_notifier_chain_register() since raw notifiers
require caller-provided locking which is incompatible with the devres
teardown callback (Sashiko)
- Patch 12: fix commit message to accurately describe the old code as
using devres_alloc() + register_reboot_notifier() (Sashiko)
Changes in v2:
- Patch 1: drop 'extern' from new function prototypes (Bart Van Assche)
- Patch 1: fix kerneldoc to use 'Return:' format (Bart Van Assche)
- Patch 1: use <linux/device/devres.h> instead of <linux/device.h>
(Andy Shevchenko)
- Patch 8: also remove unused ghes_register_vendor_record_notifier() and
ghes_unregister_vendor_record_notifier() along with their exports and
ghes.h declarations (Jonathan Cameron)
Eliav Farber (13):
notifier: add device-managed registration APIs
pwm: iqs620a: use devm_blocking_notifier_chain_register()
iio: light: iqs621-als: use devm_blocking_notifier_chain_register()
iio: position: iqs624: use devm_blocking_notifier_chain_register()
gpio: adp5585: use devm_blocking_notifier_chain_register()
platform/x86: bitland-mifs-wmi: use
devm_blocking_notifier_chain_register()
Input: adp5585: use devm_blocking_notifier_chain_register()
ACPI: APEI: GHES: remove unused
ghes_{,un}register_vendor_record_notifier()
ACPI: APEI: GHES: use devm_blocking_notifier_chain_register()
platform/x86: uniwill-wmi: use devm_blocking_notifier_chain_register()
gpio: eic-sprd: use devm_atomic_notifier_chain_register()
gpio: gpiolib-kunit: use devm_blocking_notifier_chain_register()
reboot: use devm_blocking_notifier_chain_register()
drivers/acpi/apei/ghes.c | 27 +-----
drivers/gpio/gpio-adp5585.c | 20 +---
drivers/gpio/gpio-eic-sprd.c | 17 +---
drivers/gpio/gpiolib-kunit.c | 14 +--
drivers/iio/light/iqs621-als.c | 24 +----
drivers/iio/position/iqs624-pos.c | 24 +----
drivers/input/keyboard/adp5585-keys.c | 18 +---
drivers/platform/x86/bitland-mifs-wmi.c | 17 +---
drivers/platform/x86/uniwill/uniwill-wmi.c | 17 +---
drivers/pwm/pwm-iqs620a.c | 23 +----
include/acpi/ghes.h | 16 ----
include/linux/notifier.h | 7 ++
kernel/notifier.c | 103 +++++++++++++++++++++
kernel/reboot.c | 24 +----
14 files changed, 140 insertions(+), 211 deletions(-)
--
2.47.3
Add devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound.
Many drivers repeat the same boilerplate pattern:
1. Register the notifier with *_notifier_chain_register()
2. Check for error
3. Register a devm action to unregister on teardown
4. Implement a per-driver static unregister callback
With the new devm_*_notifier_chain_register() APIs, this reduces to a
single call with one error path, eliminating per-driver unregister
callbacks entirely.
The implementation follows the established devres pattern used by other
device-managed kernel APIs.
A devm variant for raw notifier chains is intentionally not included
because raw notifiers require the caller to provide all locking. The
devres teardown callback has no way to acquire the caller's lock, and
devres_alloc() with GFP_KERNEL cannot be used if the caller's lock is a
spinlock.
Signed-off-by: Eliav Farber <redacted>
---
Changes in v5:
- Rename notifier_block parameter from 'n' to 'nb' to match the devres
struct field name (Uwe Kleine-König)
Changes in v3:
- Drop devm_raw_notifier_chain_register() since raw notifiers require
caller-provided locking which is incompatible with the devres teardown
callback (Sashiko)
Changes in v2:
- Drop 'extern' from new function prototypes (Bart Van Assche)
- Fix kerneldoc to use 'Return:' format (Bart Van Assche)
- Use <linux/device/devres.h> instead of <linux/device.h> (Andy Shevchenko)
include/linux/notifier.h | 7 +++
kernel/notifier.c | 103 +++++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+)
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
iqs620_pwm_notifier_unregister() callback.
Signed-off-by: Eliav Farber <redacted>
---
Changes in v5:
- Remove extra blank line left after deleting the unregister callback
(Uwe Kleine-König)
drivers/pwm/pwm-iqs620a.c | 23 +++--------------------
1 file changed, 3 insertions(+), 20 deletions(-)
Remove ghes_register_vendor_record_notifier() and
ghes_unregister_vendor_record_notifier() along with their
EXPORT_SYMBOL_GPL()s and ghes.h declarations, since there are no
remaining in-tree callers — all users go through
devm_ghes_register_vendor_record_notifier() instead.
Inline the register/unregister calls directly into
devm_ghes_register_vendor_record_notifier() and its destroy callback.
Signed-off-by: Eliav Farber <redacted>
Reviewed-by: Jonathan Cameron <redacted>
---
Changes in v4:
- Split from the devm conversion patch into its own commit
(Andy Shevchenko)
Changes in v2:
- New patch: remove unused ghes_register_vendor_record_notifier() and
ghes_unregister_vendor_record_notifier() along with their
EXPORT_SYMBOL_GPL()s and ghes.h declarations, since there are no
in-tree callers (Jonathan Cameron)
drivers/acpi/apei/ghes.c | 16 +++-------------
include/acpi/ghes.h | 16 ----------------
2 files changed, 3 insertions(+), 29 deletions(-)
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
ghes_vendor_record_notifier_destroy() callback.
Signed-off-by: Eliav Farber <redacted>
Reviewed-by: Jonathan Cameron <redacted>
---
Changes in v4:
- Split removal of unused code into a separate preceding patch
(Andy Shevchenko)
drivers/acpi/apei/ghes.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
@@ -690,14 +683,8 @@ static int sprd_eic_probe(struct platform_device *pdev)}sprd_eic->irq_nb.notifier_call=sprd_eic_irq_notify;-ret=atomic_notifier_chain_register(&sprd_eic_irq_notifier,-&sprd_eic->irq_nb);-if(ret)-returndev_err_probe(dev,ret,-"Failed to register with the interrupt notifier");--returndevm_add_action_or_reset(dev,sprd_eic_unregister_notifier,-&sprd_eic->irq_nb);+returndevm_atomic_notifier_chain_register(dev,&sprd_eic_irq_notifier,+&sprd_eic->irq_nb);}staticconststructof_device_idsprd_eic_of_match[]={
Replace the manual devres_alloc() + register_reboot_notifier() pattern
with a single call to devm_blocking_notifier_chain_register(), removing
the devm_unregister_reboot_notifier() callback.
Signed-off-by: Eliav Farber <redacted>
---
Changes in v3:
- Fix commit message to accurately describe the old code as using
devres_alloc() + register_reboot_notifier() (Sashiko)
kernel/reboot.c | 24 ++----------------------
1 file changed, 2 insertions(+), 22 deletions(-)
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but there is a potential NULL pointer dereference due to an unchecked `platform_get_device_id()` return value.
--
commit 7fdada2980ba610dca31ca2b97c993a21524a85f
Author: Eliav Farber [off-list ref]
Input: adp5585: use devm_blocking_notifier_chain_register()
This commit replaces the manual registration and devm cleanup of the
blocking notifier chain with a single call to
devm_blocking_notifier_chain_register().
[Severity: High]
This isn't a bug introduced by this patch, but is it possible for
platform_get_device_id() to return a null pointer here and cause a panic
when id->driver_data is dereferenced?
Looking at adp5585_keys_probe(), the returned id is not checked before
accessing id->driver_data:
drivers/input/keyboard/adp5585-keys.c:adp5585_keys_probe() {
const struct platform_device_id *id = platform_get_device_id(pdev);
...
kpad->info = (const struct adp5585_kpad_chip *)id->driver_data;
}
If a privileged user writes an arbitrary string to the driver_override
sysfs attribute of a platform device and binds it to this driver,
platform_get_device_id() will return null because the bound device
name doesn't match the driver's id_table. Does this code need a null
pointer check to prevent a local denial of service?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260816060648.4030-1-farbere@amazon.com?part=7
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The device-managed event notifier is registered before the gpiochip is added, leading to a Use-After-Free of the IRQ domain during device teardown.
--
commit c5fe212287473e8e21c8d2bae802d7b8fa665fcd
Author: Eliav Farber [off-list ref]
gpio: adp5585: use devm_blocking_notifier_chain_register()
This commit replaces the manual registration of a blocking notifier and
its associated devm_add_action_or_reset() cleanup with the new
devm_blocking_notifier_chain_register() helper.
@@ -450,13 +440,9 @@ static int adp5585_gpio_probe(struct platform_device *pdev) girq->threaded = true; adp5585_gpio->nb.notifier_call = adp5585_gpio_key_event;- ret = blocking_notifier_chain_register(&adp5585->event_notifier,- &adp5585_gpio->nb);- if (ret)- return ret;-- ret = devm_add_action_or_reset(dev, adp5585_gpio_unreg_notifier,- adp5585_gpio);+ ret = devm_blocking_notifier_chain_register(dev,+ &adp5585->event_notifier,+ &adp5585_gpio->nb);
[Severity: High]
This is a pre-existing issue, but does this devres registration order
leave a use-after-free window during device unbind?
Because devm_blocking_notifier_chain_register() is called before
devm_gpiochip_add_data() (which happens later in adp5585_gpio_probe),
devres will destroy the gpiochip and its IRQ domain before unregistering
this notifier during device teardown.
If the user unbinds the adp5585-gpio child device via sysfs while the
parent device remains bound, and a hardware interrupt fires on the
parent device during this teardown window, the parent's IRQ handler
executes adp5585_gpio_key_event(). This dereferences the already freed
irq.domain pointer:
adp5585_gpio_key_event() {
...
irq = irq_find_mapping(adp5585_gpio->gpio_chip.irq.domain, off);
...
}
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The patch omits explicitly callable devm_*_unregister() functions, preventing safe early unregistration in drivers.
- [Medium] devm_atomic_notifier_chain_register() is implicitly restricted to process context but its documentation does not state this.
- [Low] Device-managed registration for SRCU notifiers is omitted without justification.
--
commit 123931abf8d80f91fce35443259e0df9e2736a4e
Author: Eliav Farber [off-list ref]
notifier: add device-managed registration APIs
This patch adds devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound. This reduces boilerplate in
drivers by eliminating per-driver unregister callbacks.
[Severity: Medium]
Should there be corresponding devm_atomic_notifier_chain_unregister() and
devm_blocking_notifier_chain_unregister() functions provided?
If a driver needs to unregister early to quiesce hardware, manually calling
the non-devm unregister function leaves a stale devres action. This performs
a useless double-unregister during devres_release_all(), which
unconditionally hits the slow synchronize_rcu() and delays unbind.
[Severity: Low]
Is there a reason the devm variant for SRCU notifiers was omitted?
The commit message justifies omitting raw notifiers due to locking
constraints, but SRCU notifiers manage their own internal mutex which should
be safe to lock in the devres teardown context.
@@ -197,6 +198,56 @@ int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh, } EXPORT_SYMBOL_GPL(atomic_notifier_chain_unregister);+struct atomic_notifier_chain_devres {+ struct atomic_notifier_head *nh;+ struct notifier_block *nb;+};++static void devm_atomic_notifier_chain_unregister(struct device *dev, void *res)+{+ struct atomic_notifier_chain_devres *dr = res;++ atomic_notifier_chain_unregister(dr->nh, dr->nb);+}++/**+ * devm_atomic_notifier_chain_register - Device-managed atomic notifier registration+ * @dev: Device to tie the notifier lifetime to+ * @nh: Pointer to head of the atomic notifier chain+ * @nb: New entry in notifier chain+ *+ * Adds a notifier to an atomic notifier chain and registers a cleanup+ * action to automatically unregister it when @dev is unbound.+ *+ * Return:+ * 0 on success, negative errno on error.+ */
[Severity: Medium]
Should this kerneldoc include a context warning like "Must be called in
process context."?
Unlike atomic_notifier_chain_register() which is safe in atomic context,
this function uses devres_alloc() with GFP_KERNEL which can sleep, making it
unsafe to call from atomic context.
Hello Eliav,
On Sun, Aug 16, 2026 at 06:19:06AM +0000, sashiko-bot@kernel.org wrote:
quoted hunk
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The patch omits explicitly callable devm_*_unregister() functions, preventing safe early unregistration in drivers.
- [Medium] devm_atomic_notifier_chain_register() is implicitly restricted to process context but its documentation does not state this.
- [Low] Device-managed registration for SRCU notifiers is omitted without justification.
--
commit 123931abf8d80f91fce35443259e0df9e2736a4e
Author: Eliav Farber [off-list ref]
notifier: add device-managed registration APIs
This patch adds devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound. This reduces boilerplate in
drivers by eliminating per-driver unregister callbacks.
[Severity: Medium]
Should there be corresponding devm_atomic_notifier_chain_unregister() and
devm_blocking_notifier_chain_unregister() functions provided?
I think these can be added once they are needed.
If a driver needs to unregister early to quiesce hardware, manually calling
the non-devm unregister function leaves a stale devres action. This performs
a useless double-unregister during devres_release_all(), which
unconditionally hits the slow synchronize_rcu() and delays unbind.
[Severity: Low]
Is there a reason the devm variant for SRCU notifiers was omitted?
The commit message justifies omitting raw notifiers due to locking
constraints, but SRCU notifiers manage their own internal mutex which should
be safe to lock in the devres teardown context.
@@ -197,6 +198,56 @@ int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh, } EXPORT_SYMBOL_GPL(atomic_notifier_chain_unregister);+struct atomic_notifier_chain_devres {+ struct atomic_notifier_head *nh;+ struct notifier_block *nb;+};++static void devm_atomic_notifier_chain_unregister(struct device *dev, void *res)+{+ struct atomic_notifier_chain_devres *dr = res;++ atomic_notifier_chain_unregister(dr->nh, dr->nb);+}++/**+ * devm_atomic_notifier_chain_register - Device-managed atomic notifier registration+ * @dev: Device to tie the notifier lifetime to+ * @nh: Pointer to head of the atomic notifier chain+ * @nb: New entry in notifier chain+ *+ * Adds a notifier to an atomic notifier chain and registers a cleanup+ * action to automatically unregister it when @dev is unbound.+ *+ * Return:+ * 0 on success, negative errno on error.+ */
[Severity: Medium]
Should this kerneldoc include a context warning like "Must be called in
process context."?
Unlike atomic_notifier_chain_register() which is safe in atomic context,
this function uses devres_alloc() with GFP_KERNEL which can sleep, making it
unsafe to call from atomic context.
That sounds like a good suggestion.
You didn't specify a merge plan for this series. Given there is no
explicit maintainer for kernel/notifier.c, I can apply patch #1 (with
adding the comment suggested by Sashiko) and provide an immutable branch
for subsystem maintainers to pull into their tree as base to apply their
patches. I'd wait till say Wednesday with that to maybe let reviews
tickle in.
Sounds good?
Best regards
Uwe
Hello,
I already replied to Sashiko's review and only noticed afterwards that
this way most recipients are stripped. So here again for the wide
audience:
I suggested to add "Must be called in process context." to the kdoc for
devm_atomic_notifier_chain_register() as this is a relevant difference
to atomic_notifier_chain_register() and create an immutable branch for
it as a base for subsystems to apply their follow-up patches. I'd wait
till Wednesday for concerns and review tags to tickle in.
Best regards
Uwe
From: Bradley Morgan <hidden> Date: 2026-08-16 14:48:42
🤷, I don't care much.
I'm surprised how emojis can be used in the lkml...
btw I can't review this series (much) because this seems to be like for
something
else
But the least I can do:
Tested-by: Bradley Morgan <redacted>
Acked-by: Bradley Morgan <redacted> # kernel/
A-B instead of R-B because I haven't done vigorous review.
Also, I added akpm because he (sorta) maintains reboot.c for instance...
We should really add a formal maintainer/reviewer slot for these files. I
don't mind taking it up, but reboot.c ATM is quite nuts.....
Btw, thanks for your patch Eliav
Thanks!
On Sun, Aug 16, 2026 at 9:04 AM Uwe Kleine-König [off-list ref] wrote:
I suggested to add "Must be called in process context." to the kdoc for
devm_atomic_notifier_chain_register() as this is a relevant difference
to atomic_notifier_chain_register() and create an immutable branch for
it as a base for subsystems to apply their follow-up patches. I'd wait
till Wednesday for concerns and review tags to tickle in.
I think this is a good approach, but we are in the merge window,
don't you wanna wait for v7.3-rc1 and create the immutable branch
based on that?
(But Bartosz will be the one pulling the immutable branch...)
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
On Sun, Aug 16, 2026 at 8:08 AM Eliav Farber [off-list ref] wrote:
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
adp5585_gpio_unreg_notifier() callback.
Signed-off-by: Eliav Farber <redacted>
Acked-by: Bartosz Golaszewski <redacted>
Sashikos comment is probably correct but can be fixed in another
patch by whoever wants to.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
On Sun, Aug 16, 2026 at 8:09 AM Eliav Farber [off-list ref] wrote:
Replace the atomic_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_atomic_notifier_chain_register(), removing the
sprd_eic_unregister_notifier() callback.
Signed-off-by: Eliav Farber <redacted>
Acked-by: Bartosz Golaszewski <redacted>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
On Sun, Aug 16, 2026 at 8:09 AM Eliav Farber [off-list ref] wrote:
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
gpio_unbind_unregister_notifier() callback.
Signed-off-by: Eliav Farber <redacted>
Acked-by: Bartosz Golaszewski <redacted>
Hello Linus,
On Mon, Aug 17, 2026 at 02:10:13PM +0200, Linus Walleij wrote:
On Sun, Aug 16, 2026 at 9:04 AM Uwe Kleine-König [off-list ref] wrote:
quoted
I suggested to add "Must be called in process context." to the kdoc for
devm_atomic_notifier_chain_register() as this is a relevant difference
to atomic_notifier_chain_register() and create an immutable branch for
it as a base for subsystems to apply their follow-up patches. I'd wait
till Wednesday for concerns and review tags to tickle in.
I think this is a good approach, but we are in the merge window,
don't you wanna wait for v7.3-rc1 and create the immutable branch
based on that?
My thought was to base on v7.2, and then consider the topic done for me.
(But Bartosz will be the one pulling the immutable branch...)
It shouldn't make a difference for him if the branch's base is v7.2 or
v7.3-rc1, still more given that there are no changes staged in next to
the affected files (`git log v7.2..next/master --
include/linux/notifier.h kernel/notifier.c`).
Best regards
Uwe
Hello,
On Sun, Aug 16, 2026 at 06:05:59AM +0000, Eliav Farber wrote:
Many drivers repeat the same boilerplate when registering notifiers with
device lifetime:
1. Register the notifier with *_notifier_chain_register()
2. Check for error
3. Register a devm action to unregister on teardown
4. Implement a per-driver static unregister callback
This series adds devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound, then converts 11 drivers to use
them.
I applied the first patch on top of v7.2 for you to merge into your
subsystem trees as base for applying the patch(es) from this series that
should go via your tree.
Find it at
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/devm_notifier_chain_register-for-7.3
This tag only contains this single commit e38b9eda475f ("notifier: add
device-managed registration APIs"). I intend to include it in my PR for
v7.3-rc1, feel free to do the same.
Best regards
Uwe
On Fri, Aug 21, 2026 at 04:07:18PM +0200, Uwe Kleine-König wrote:
On Sun, Aug 16, 2026 at 06:05:59AM +0000, Eliav Farber wrote:
quoted
Many drivers repeat the same boilerplate when registering notifiers with
device lifetime:
1. Register the notifier with *_notifier_chain_register()
2. Check for error
3. Register a devm action to unregister on teardown
4. Implement a per-driver static unregister callback
This series adds devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound, then converts 11 drivers to use
them.
I applied the first patch on top of v7.2 for you to merge into your
subsystem trees as base for applying the patch(es) from this series that
should go via your tree.
Find it at
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/devm_notifier_chain_register-for-7.3
This tag only contains this single commit e38b9eda475f ("notifier: add
device-managed registration APIs"). I intend to include it in my PR for
v7.3-rc1, feel free to do the same.
While I tried to pick up the pwm patch in this series I noticed my
Arithmetic error here 🙄. It should be 7.4 of course. I created
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/devm_notifier_chain_register-for-7.4
with a fixed tag message and dropped the 7.3 tag. (Even is someone
already pulled it, nothing bad happens as it points to the same commit.)
Sorry for the confusion.
Uwe
Hello,
On Sun, Aug 16, 2026 at 06:06:01AM +0000, Eliav Farber wrote:
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
iqs620_pwm_notifier_unregister() callback.
Signed-off-by: Eliav Farber <redacted>
I applied this to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-nexxt
(with $Subject ~= s/use/Use/ to match the usual style in pwm land) as
7.4 material. Note this branch isn't stable and I intend to rebase it to
7.3-rc1 once that is available. Until then it will also not be part of
linux-next.
Best regards
Uwe
On Sun, 16 Aug 2026 06:05:59 +0000, Eliav Farber wrote:
Many drivers repeat the same boilerplate when registering notifiers with
device lifetime:
1. Register the notifier with *_notifier_chain_register()
2. Check for error
3. Register a devm action to unregister on teardown
4. Implement a per-driver static unregister callback
[...]
From: Jonathan Cameron <jic23@kernel.org> Date: 2026-09-04 02:56:41
On Sun, 16 Aug 2026 06:06:02 +0000
Eliav Farber [off-list ref] wrote:
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
iqs621_als_notifier_unregister() callback.
Signed-off-by: Eliav Farber <redacted>
Acked-by: Jonathan Cameron <redacted>
Applied (on top of merging the branch) to the testing branch of iio.git
Upgraded that ack to an SoB as a result.
From: Jonathan Cameron <jic23@kernel.org> Date: 2026-09-04 02:57:30
On Sun, 16 Aug 2026 06:06:03 +0000
Eliav Farber [off-list ref] wrote:
Replace the blocking_notifier_chain_register() +
devm_add_action_or_reset() pattern with a single call to
devm_blocking_notifier_chain_register(), removing the
iqs624_pos_notifier_unregister() callback.
Signed-off-by: Eliav Farber <redacted>
Acked-by: Jonathan Cameron <redacted>
Applied to the testing branch of iio.git
Thanks,
Jonathan