Re: pm_runtime_early_init() defined but not used, except on SuperH which has its own definition ?
Geert Uytterhoeven <[email protected]>
| Newsgroups | gmane.linux.ports.sh.devel,gmane.linux.kernel,gmane.linux.power-management.general |
|---|---|
| Message-ID | <CAMuHMdX2CtKuY5GS=sJL2rYhixzgtXBQQpef-h=2GKRX-cNOjg@mail.gmail.com> |
CC Bartosz On Sun, Mar 3, 2024 at 8:53 PM Hans de Goede <[email protected]> wrote: > > Hi All, > > I noticed that drivers/base/power/power.h defines pm_runtime_early_init() > but nothing under drivers/base uses this. > > A grep over the entire tree shows that arch/sh/drivers/platform_early.c > does use pm_runtime_early_init() but rather then including > drivers/base/power/power.h it has its own definition / private copy > of both device_pm_init_common() and pm_runtime_early_init() from > drivers/base/power/power.h ??? > > Also the private copy of pm_runtime_early_init() in > arch/sh/drivers/platform_early.c differs from the unused one > in drivers/base/power/power.h, but only when CONFIG_PM is not set. > > When CONFIG_PM is not set then the pm_runtime_early_init() in > arch/sh/drivers/platform_early.c is a no-op, where as the one in > drivers/base/power/power.h still calls device_pm_init_common() > in this case ... > > I also wonder if given that pm_runtime_early_init() is not > used with the exception of arch/sh/drivers/platform_early.c > if the dev->power.early_init flag check in > device_pm_init_common() is really necessary ? > > On non SuperH the only (1) caller of device_pm_init_common() > is device_pm_init(), so it seems to me that the code to > avoid doing device_pm_init_common() twice is unnecessary. > > Actually it seems to me that the entire contents of > device_pm_init_common() can be moved inside device_pm_init() > and the dev->power.early_init can be completely dropped (2). > > Regards, > > Hans > > > 1) Well pm_runtime_early_init() calls it too, but that itself > is unused and can be removed, removing it is even ok-ish > for SuperH since that has its own copy anyways. > > 2) With the exception that all of this is still necessary > for SuperH I guess.