| Message ID | cover.1616395565.git.matti.vaittinen@fi.rohmeurope.com |
|---|---|
| Headers | show |
| Series | Add managed version of delayed work init | expand |
Hi Greg, On Tue, 2021-03-23 at 13:43 +0100, Greg KH wrote: > On Mon, Mar 22, 2021 at 09:41:13AM +0200, Matti Vaittinen wrote: > > It's not rare that device drivers need delayed work. > > It's not rare that this work needs driver's data. > > I don't normally comment on "RFC" patch series as I can't take them > and > the submitter doesn't feel right with them being merged at this point > in > time. > > So if you think this is all correct now, please resubmit without that > so > we can review it properly :) Thanks for the guidance :) I'll drop the RFC and resubmit. Others - sorry for the noise. Best Regards Matti Vaittinen
It's not rare that device drivers need delayed work. It's not rare that this work needs driver's data. Often this means that driver must ensure the work is not queued when driver is detached. Often it is done by ensuring new work is not added and then calling cancel_delayed_work_sync() at remove(). In many cases this may also require cleanup at probe error path - which is easy to forget. Also the "by ensuring new work is not added" has a gotcha. It is not strange to see devm managed IRQs scheduling (delayed) work. Mixing this with manua wq clean-up is hard to do correctly because the devm is likely to free the IRQ only after the remove() is ran. So manual wq cancellation and devm-based IRQ management do not mix well - there is a short(?) time-window after the wq clean-up when IRQs are still not freed and may schedule new work. When both WQs and IRQs are managed by devm things are likely to just work. WQs should be initialized before IRQs (when IRQs need to schedule work) and devm unwinds things in "FILO" order. This series implements delayed wq cancellation on top of devm and replaces the obvious cases where only thing remove call-back in a driver does is cancelling the work. There might be other cases where we could switch more than just work cancellation to use managed version and thus get rid of remove or mixed (manual and devm) resource management. This RFC does also introduce include/linux/devm-helpers.h file which hopefully works as a place where this kind of helpers can be inlined. Please see previous discussion here: RFC v1: https://lore.kernel.org/lkml/cover.1613216412.git.matti.vaittinen@fi.rohmeurope.com/ Changelog v2 resend: - rebased on 5.12-rc4 Changelog v2: - used correct terminology ("driver detach" instead of "exit, ...") - inlined the devm_delayed_work_autocancel() in a header - added Hans as a maintainer for the new header + myself as a reviewer - used devm_add_action() instead of using plain devres_add() --- Matti Vaittinen (8): workqueue: Add resource managed version of delayed work init MAINTAINERS: Add entry for devm helpers extconn: Clean-up few drivers by using managed work init hwmon: raspberry-pi: Clean-up few drivers by using managed work init platform/x86: gpd pocket fan: Clean-up by using managed work init power: supply: Clean-up few drivers by using managed work init regulator: qcom_spmi-regulator: Clean-up by using managed work init watchdog: retu_wdt: Clean-up by using managed work init MAINTAINERS | 6 +++ drivers/extcon/extcon-gpio.c | 15 ++---- drivers/extcon/extcon-intel-int3496.c | 16 ++---- drivers/extcon/extcon-palmas.c | 17 +++---- drivers/extcon/extcon-qcom-spmi-misc.c | 17 +++---- drivers/hwmon/raspberrypi-hwmon.c | 17 +++---- drivers/platform/x86/gpd-pocket-fan.c | 17 +++---- drivers/power/supply/axp20x_usb_power.c | 15 ++---- drivers/power/supply/bq24735-charger.c | 18 +++---- drivers/power/supply/ltc2941-battery-gauge.c | 20 +++----- drivers/power/supply/sbs-battery.c | 16 ++---- drivers/regulator/qcom_spmi-regulator.c | 34 +++---------- drivers/watchdog/retu_wdt.c | 22 +++----- include/linux/devm-helpers.h | 53 ++++++++++++++++++++ 14 files changed, 128 insertions(+), 155 deletions(-) create mode 100644 include/linux/devm-helpers.h base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b