Linux Kernel Mentees list
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Vaibhav Gupta <vaibhav.varodek@gmail.com>
Cc: linux-kernel-mentees@lists.linuxfoundation.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Vaibhav Gupta <vaibhavgupta40@gmail.com>
Subject: Re: [Linux-kernel-mentees] [PATCH v1 2/2] realtek/8139cp: Remove Legacy Power Management
Date: Fri, 24 Apr 2020 08:59:10 -0500	[thread overview]
Message-ID: <20200424135910.GA118662@google.com> (raw)
In-Reply-To: <CAPBsFfARrVF1Ch-gMT6fbnBhdigY+qQKSZV8P_h3bZw5bXiFrg@mail.gmail.com>

On Fri, Apr 24, 2020 at 06:30:01PM +0530, Vaibhav Gupta wrote:
> On Fri, 24 Apr 2020 at 18:14, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Fri, Apr 24, 2020 at 04:01:43PM +0530, Vaibhav Gupta wrote:
> > > On Fri, 24 Apr 2020 at 09:17, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > On Thu, Apr 23, 2020 at 06:58:01PM +0530, Vaibhav Gupta wrote:
> > > > > Upgrade Power Management from legacy to generic using dev_pm_ops.
> > > > >
> > > > > Remove pci_save_sate(), pci_set_state(), etc. No need of directive
> > > > > '#ifdef CONFIG_PM' as, if CONFIG_PM is not defined, the binding
> > > > > will be by deafult set to NULL.
> > > >
> > > > s/deafult/default/
> > > >
> > > > I didn't quite follow this argument.  SIMPLE_DEV_PM_OPS() is defined
> > > > to SET_SYSTEM_SLEEP_PM_OPS(), and SET_SYSTEM_SLEEP_PM_OPS() is defined
> > > > to nothing unless CONFIG_PM_SLEEP (not CONFIG_PM).
> > > yes, and we can find about CONFIG_PM_SLEEP inside kernel/power/kconfig
> > > It is defined as:
> > > config PM_SLEEP
> > >         def_bool y
> > >         depends on SUSPEND || HIBERNATE_CALLBACKS
> > >         select PM
> > >         select SRCU
> > >
> > > Hence it is selecting CONFIG_PM. So any of the macro check works.So i
> > > should go with
> > > #ifded CONFIG_PM
> > > or
> > > #ifdef CONFIG_PM_SLEEP ?
> >
> > Well, the point was that it's possible to have CONFIG_PM=y but
> > CONFIG_PM_SLEEP unset.  In that case, using "#ifdef CONFIG_PM" will
> > mean those functions will be compiled but not referenced.
> >
> > > > But in any case, we don't want cp_suspend() and cp_resume() to be
> > > > compiled at all if they're not referenced.  So I think converting the
> > > > "#ifdef CONFIG_PM" to "#ifdef CONFIG_PM_SLEEP" is the right thing.
> > > Actually I removed it because Andy also removed them in
> > > 226e6b866d74, thought it has to be done that way.
> >
> > Hmm, yes, I see that.  I wish we had one canonical way to do this.
> >
> > In 226e6b866d74 ("gpio: pch: Convert to dev_pm_ops"), I see that Andy
> > also added "__maybe_unused", which I think turns off the compiler
> > warning about the function being unused.
> >
> > I had been looking at recent additions of SIMPLE_DEV_PM_OPS() via
> >
> >   $ git log -p drivers/
> >
> > and searching with "/^\+.*SIMPLE_DEV_PM_OPS".  There's a mix of using
> > "#ifdef CONFIG_PM_SLEEP" and using "__maybe_unused", but it does look
> > like "__maybe_unused" is winning.  It leaves unusable code in the
> > image but arguably looks a little prettier.
> >
> > So I guess I'm fine with either way.  But I do think we need either
> > "#ifdef CONFIG_PM_SLEEP" or "__maybe_unused" so we don't get compiler
> > warnings.
>
> I totally agree with your argument. But in case of "#ifdef CONFIG_PM_SLEEP",
> neither the suspend() & resume() are compiled and neither ".driver.pm"
> gets bind.
> 
> But in case of "__maybe_unused", we don't keep a check while binding
> ".driver.pm".
> Hence, if CONFIG_PM_SLEEP is not defined, still the ".driver.pm" is
> bind with a structure
> with some random initial values.
>
> We can use the mix of both?
> __maybe_unused xyz_suspend(){}
> __maybe_unused xyz_resume(){}
> ...
> #ifdef CONFIG_PM_SLEEP
> .driver.pm = &xyz_pm_ops;
> #endif

I don't think we need the mix because when CONFIG_PM_SLEEP isn't
defined, SIMPLE_DEV_PM_OPS() compiles to:

  const struct dev_pm_ops xyz_pm_ops = { }

and the xyz_pm_ops struct should be zero-filled.  The #ifdef around
".driver.pm = &xyz_pm_ops" doesn't buy us anything -- the space for
the driver.pm pointer is there regardless, so we don't save any space,
and the default initialization is zero-filled, so the result is the
same.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  reply	other threads:[~2020-04-24 13:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 13:27 [Linux-kernel-mentees] [PATCH v1 1/2] realtek/8139too: Remove Legacy Power Management Vaibhav Gupta
2020-04-23 13:28 ` [Linux-kernel-mentees] [PATCH v1 2/2] realtek/8139cp: " Vaibhav Gupta
2020-04-24  3:47   ` Bjorn Helgaas
2020-04-24 10:31     ` Vaibhav Gupta
2020-04-24 12:44       ` Bjorn Helgaas
2020-04-24 13:00         ` Vaibhav Gupta
2020-04-24 13:59           ` Bjorn Helgaas [this message]
2020-04-24 14:04             ` Vaibhav Gupta
2020-04-24 15:01               ` Bjorn Helgaas
2020-04-24 15:13                 ` Vaibhav Gupta
2020-04-24  3:43 ` [Linux-kernel-mentees] [PATCH v1 1/2] realtek/8139too: " Bjorn Helgaas
2020-04-24 10:00   ` Vaibhav Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200424135910.GA118662@google.com \
    --to=helgaas@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=rjw@rjwysocki.net \
    --cc=vaibhav.varodek@gmail.com \
    --cc=vaibhavgupta40@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox