Re: [PATCH v2 1/3] drivers/bus: Add Legacy PM OPS usage check and warning to bus_register()

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Jan 06, 2014 at 01:30:31PM -0700, Shuah Khan wrote:
> On 01/06/2014 01:17 PM, Greg KH wrote:
> >On Mon, Jan 06, 2014 at 01:03:21PM -0700, Shuah Khan wrote:
> >>Add Legacy PM OPS usage checks to bus_register() function. If Legacy PM OPS
> >>usage is found, print warning message to indicate that the driver code needs
> >>updating to use Dev PM OPS interfaces. This will help serve as a way to track
> >>drivers that still use Legacy PM OPS and fix them.
> >>
> >>The Legacy PM OPS check looks for suspend(struct device *, pm_message_t) or
> >>resume(struct device *) bus level interfaces.
> >>
> >>Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> >>---
> >>  drivers/base/bus.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >>diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> >>index 73f6c29..e8753a7 100644
> >>--- a/drivers/base/bus.c
> >>+++ b/drivers/base/bus.c
> >>@@ -916,6 +916,9 @@ int bus_register(struct bus_type *bus)
> >>  		goto bus_groups_fail;
> >>
> >>  	pr_debug("bus: '%s': registered\n", bus->name);
> >>+	if (bus->suspend || bus->resume)
> >>+		pr_warn("bus '%s' needs updating - use pm pointer.\n",
> >>+			bus->name);
> >
> >Why can't we just sweep the tree for all of these now, fix them up, and
> >then delete these fields and be done with it?
> >
> >Same for the other ones, putting warnings in the kernel log files
> >doesn't work at all for getting people to fix up their code (see
> >examples of scsi log messages being there for _years_ about obsolete
> >driver interfaces being used.)
> 
> This change is not a simple case of replacing legacy with pm ops. I have
> been working on changing drivers that use legacy, in some cases it is an
> easy change, however in some cases it requires adding new interfaces to port
> over from legacy to pm ops. Legacy suspend/resume is more course grain and
> pm ops offer fine grain control over suspend, hibernate etc. Also it has
> been a challenge without the hardware to test.
> 
> My thinking is adding warning might get the attention of individual driver
> owners.

If it's not a trivial change, and takes a lot of work by someone who
knows this type of thing (i.e. you), then I wouldn't start making kernel
log warnings about this, it's just going to annoy a bunch of people :)

Again, see the SCSI log warnings for examples of this, people just tune
them out, assuming someone else is going to fix the issue, someday.  And
that someday never comes...

thanks,

greg k-h