All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.