to 12.12.2024 klo 14.04 Joe Hattori (joe@xxxxxxxxxxxxxxxxxxxxx) kirjoitti:
> >
> > Coudln't we have a devm_ version of device_init_wakeup instead?
>
> Yes, I think it is possible. However, for this patch, calling
> device_init_wakeup() at the end of the .probe() would suffice,
I agree. But...
> and I
> think implementing the devm_ function should be in a different patch.
> Please let me know if you think otherwise.
... I just took a very quick glance at the first four RTC drivers calling the
device_init_wakeup(). Two of them seemed to potentially leave the
device_init_wakeup() undone on some occasion. (Either in remove(), or
at exit via error path). I know 4 is not a good set of samples, but assuming
it suffices and extrapolating from there it seems there might be a few cases
to check. Having the devm_ variant should be helpful - and this would be
plenty of beans for those who do count them ;)
After that being said, I am not really sure how this is supposed to
work. Is there
ever a valid reason to keep the wakeup capability information around after a
driver is detached? I'd guess the enable/disable of wakeup is usually handled by
the driver, and if driver is gone, do we still need the wakeup stuff?
If we don't, then
it sounds like a thing that [sh/c]ould be automatically handled by the
core, without
the driver having to explicitly remove it. (But as I said, I am not
sure how this is
supposed to work).
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
Discuss - Estimate - Plan - Report and finally accomplish this:
void do_work(int time) __attribute__ ((const));
