linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Paul Cercueil <paul@crapouillou.net>, Pavel Machek <pavel@ucw.cz>,
	Len Brown <len.brown@intel.com>,
	Jonathan Cameron <jic23@kernel.org>,
	list@opendingux.net,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [PATCH 0/5] Rework pm_ptr() and *_PM_OPS macros
Date: Fri, 17 Dec 2021 19:22:34 +0100	[thread overview]
Message-ID: <CAJZ5v0gqVtOhrC72ey8hPSCuP+DfHJk2qK_pemvpmHGLvPSFRQ@mail.gmail.com> (raw)
In-Reply-To: <CAPDyKFpfWZsw+7aZdQVsCsTxoEfUqpkZM6Ozfr5COQNNaqhLhA@mail.gmail.com>

On Fri, Dec 17, 2021 at 6:17 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 17 Dec 2021 at 16:07, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Tue, Dec 7, 2021 at 10:22 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Tue, Dec 7, 2021 at 1:20 AM Paul Cercueil <paul@crapouillou.net> wrote:
> > > >
> > > > This patchset reworks the pm_ptr() macro I introduced a few versions
> > > > ago, so that it is not conditionally defined.
> > > >
> > > > It applies the same treatment to the *_PM_OPS macros. Instead of
> > > > modifying the existing ones, which would mean a 2000+ patch bomb, this
> > > > patchset introduce two new macros to replace the now deprecated
> > > > UNIVERSAL_DEV_PM_OPS() and SIMPLE_DEV_PM_OPS().
> > > >
> > > > The point of all of this, is to progressively switch from a code model
> > > > where PM callbacks are all protected behind CONFIG_PM guards, to a code
> > > > model where PM callbacks are always seen by the compiler, but discarded
> > > > if not used.
> > > >
> > > > Patch [4/5] and [5/5] are just examples to illustrate the use of the new
> > > > macros. As such they don't really have to be merged at the same time as
> > > > the rest and can be delayed until a subsystem-wide patchset is proposed.
> > > >
> > > > - Patch [4/5] modifies a driver that already used the pm_ptr() macro,
> > > >   but had to use the __maybe_unused flag to avoid compiler warnings;
> > > > - Patch [5/5] modifies a driver that used a #ifdef CONFIG_PM guard
> > > >   around its suspend/resume functions.
> > >
> > > This is fantastic, I love the new naming and it should provide a great path
> > > towards converting all drivers eventually. I've added the patches to
> > > my randconfig test build box to see if something breaks, but otherwise
> > > I think these are ready to get into linux-next, at least patches 1-3,
> > > so subsystem
> > > maintainers can start queuing up the conversion patches once the
> > > initial set is merged.
> > >
> > > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Patches [0-3/5] applied as 5.17 material.
> >
> > The mmc patches need ACKs, but I can take them too.
>
> Sure, please add my ack for them!

Both applied as 5.17 material with your ACKs, thanks!

      reply	other threads:[~2021-12-17 18:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07  0:20 [PATCH 0/5] Rework pm_ptr() and *_PM_OPS macros Paul Cercueil
2021-12-07  0:20 ` [PATCH 1/5] r8169: Avoid misuse of pm_ptr() macro Paul Cercueil
2021-12-07  0:20 ` [PATCH 2/5] PM: core: Redefine " Paul Cercueil
2021-12-16 11:10   ` Jonathan Cameron
2021-12-07  0:21 ` [PATCH 3/5] PM: core: Add new *_PM_OPS macros, deprecate old ones Paul Cercueil
2021-12-16 11:09   ` Jonathan Cameron
2021-12-07  0:21 ` [PATCH 4/5] mmc: jz4740: Use the new PM macros Paul Cercueil
2021-12-07  0:21 ` [PATCH 5/5] mmc: mxc: " Paul Cercueil
2021-12-07  9:22 ` [PATCH 0/5] Rework pm_ptr() and *_PM_OPS macros Arnd Bergmann
2021-12-17 15:07   ` Rafael J. Wysocki
2021-12-17 17:16     ` Ulf Hansson
2021-12-17 18:22       ` Rafael J. Wysocki [this message]

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=CAJZ5v0gqVtOhrC72ey8hPSCuP+DfHJk2qK_pemvpmHGLvPSFRQ@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=arnd@arndb.de \
    --cc=jic23@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=list@opendingux.net \
    --cc=netdev@vger.kernel.org \
    --cc=paul@crapouillou.net \
    --cc=pavel@ucw.cz \
    --cc=ulf.hansson@linaro.org \
    /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).