linux-kernel-mentees.lists.linuxfoundation.org archive mirror
 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 07:44:32 -0500	[thread overview]
Message-ID: <20200424124432.GA100904@google.com> (raw)
In-Reply-To: <CAPBsFfAdXZW3p_WFknvPVbvDhNw2iWt13BTHDXCUjXaSFYAo_w@mail.gmail.com>

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.

Bjorn
_______________________________________________
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 12:44 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 [this message]
2020-04-24 13:00         ` Vaibhav Gupta
2020-04-24 13:59           ` Bjorn Helgaas
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=20200424124432.GA100904@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;
as well as URLs for NNTP newsgroup(s).