Messages in this thread |  | | Subject | Re: [PATCH v3 6/8] power: supply: Clean-up few drivers by using managed work init | From | Matti Vaittinen <> | Date | Wed, 24 Mar 2021 09:43:33 +0200 |
| |
Hello Chen-Yu, Hans, Greg,
On Tue, 2021-03-23 at 22:36 +0800, Chen-Yu Tsai wrote: > Hi, > > On Tue, Mar 23, 2021 at 9:58 PM Matti Vaittinen > <matti.vaittinen@fi.rohmeurope.com> wrote: > > Few drivers implement remove call-back only for ensuring a delayed > > work gets cancelled prior driver removal. Clean-up these by > > switching > > to use devm_delayed_work_autocancel() instead. > > > > This change is compile-tested only. All testing is appreciated. > > > > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> > > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> > > --- > > Changelog from RFCv2: > > - RFC dropped. No functional changes. > > > > 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 +++++----------- > > 4 files changed, 23 insertions(+), 46 deletions(-) > > > > diff --git a/drivers/power/supply/axp20x_usb_power.c > > b/drivers/power/supply/axp20x_usb_power.c > > index 8933ae26c3d6..4259709e3491 100644 > > --- a/drivers/power/supply/axp20x_usb_power.c > > +++ b/drivers/power/supply/axp20x_usb_power.c > > @@ -8,6 +8,7 @@ > > > > #include <linux/bitops.h> > > #include <linux/device.h> > > +#include <linux/devm-helpers.h> > > #include <linux/init.h> > > #include <linux/interrupt.h> > > #include <linux/kernel.h> > > @@ -646,21 +647,16 @@ static int axp20x_usb_power_probe(struct > > platform_device *pdev) > > } > > } > > > > + ret = devm_delayed_work_autocancel(&pdev->dev, &power- > > >vbus_detect, > > + axp20x_usb_power_poll_vb > > us); > > + if (ret) > > + return ret; > > This doesn't look right. The IRQ is requested before this, and the > delayed_work > struct is initialized even earlier, so you'd be re-initializing the > struct, > with the work item potentially running or queued up already.
Sigh. The company mail had redirected this to spam... :/ I will check this and send appropriate follow-up fix(es) to Greg. Big thanks for the heads-up!
--Matti
|  |