From: Paul Cercueil <paul@crapouillou.net>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
Lee Jones <lee.jones@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pm <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v2 01/30] pm: Improve EXPORT_*_DEV_PM_OPS macros
Date: Sun, 02 Oct 2022 12:18:00 +0100 [thread overview]
Message-ID: <02I4JR.BHDWVSR51INT1@crapouillou.net> (raw)
In-Reply-To: <20221001180130.73a26c68@jic23-huawei>
Le sam., oct. 1 2022 at 18:01:30 +0100, Jonathan Cameron
<jic23@kernel.org> a écrit :
> On Mon, 26 Sep 2022 15:35:35 +0200
> "Rafael J. Wysocki" <rafael@kernel.org> wrote:
>
>> On Mon, Sep 26, 2022 at 3:27 PM Paul Cercueil
>> <paul@crapouillou.net> wrote:
>> >
>> > Hi,
>> >
>> > Le lun., sept. 26 2022 at 14:00:52 +0200, Rafael J. Wysocki
>> > <rafael@kernel.org> a écrit :
>> > > On Sun, Sep 25, 2022 at 4:52 PM Jonathan Cameron
>> <jic23@kernel.org>
>> > > wrote:
>> > >>
>> > >> On Thu, 25 Aug 2022 23:42:53 +0100
>> > >> Paul Cercueil <paul@crapouillou.net> wrote:
>> > >>
>> > >> > Hi Rafael,
>> > >> >
>> > >> > Le mar., août 23 2022 at 19:47:57 +0200, Rafael J. Wysocki
>> > >> > <rafael@kernel.org> a écrit :
>> > >> > > On Mon, Aug 8, 2022 at 7:41 PM Paul Cercueil
>> > >> <paul@crapouillou.net>
>> > >> > > wrote:
>> > >> > >>
>> > >> > >> Update the _EXPORT_DEV_PM_OPS() internal macro. It was
>> not
>> > >> used
>> > >> > >> anywhere
>> > >> > >> outside pm.h and pm_runtime.h, so it is safe to update
>> it.
>> > >> > >>
>> > >> > >> Before, this macro would take a few parameters to be
>> used as
>> > >> sleep
>> > >> > >> and
>> > >> > >> runtime callbacks. This made it unsuitable to use with
>> > >> different
>> > >> > >> callbacks, for instance the "noirq" ones.
>> > >> > >>
>> > >> > >> It is now semantically different: instead of creating a
>> > >> > >> conditionally
>> > >> > >> exported dev_pm_ops structure, it only contains part of
>> the
>> > >> > >> definition.
>> > >> > >>
>> > >> > >> This macro should however never be used directly (hence
>> the
>> > >> trailing
>> > >> > >> underscore). Instead, the following four macros are
>> provided:
>> > >> > >> - EXPORT_DEV_PM_OPS(name)
>> > >> > >> - EXPORT_GPL_DEV_PM_OPS(name)
>> > >> > >> - EXPORT_NS_DEV_PM_OPS(name, ns)
>> > >> > >> - EXPORT_NS_GPL_DEV_PM_OPS(name, ns)
>> > >> > >>
>> > >> > >> For instance, it is now possible to conditionally
>> export noirq
>> > >> > >> suspend/resume PM functions like this:
>> > >> > >>
>> > >> > >> EXPORT_GPL_DEV_PM_OPS(foo_pm_ops) = {
>> > >> > >> NOIRQ_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
>> > >> > >> };
>> > >> > >>
>> > >> > >> The existing helper macros EXPORT_*_SIMPLE_DEV_PM_OPS()
>> and
>> > >> > >> EXPORT_*_RUNTIME_DEV_PM_OPS() have been updated to use
>> these
>> > >> new
>> > >> > >> macros.
>> > >> > >>
>> > >> > >> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> > >> > >
>> > >> > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> > >> > >
>> > >> > > or please let me know if you need me to pick up this one.
>> > >> >
>> > >> > Could you pick this one up then, and make a branch for
>> Jonathan?
>> > >>
>> > >> Hi Paul, Rafael,
>> > >>
>> > >> What happened to this in the end? I can't immediately find
>> it on
>> > >> any of the pm git tree branches.
>> > >>
>> > >> At this stage in the cycle it would be great if this patch at
>> least
>> > >> makes the merge window, so we can make use of it next cycle.
>> > >
>> > > I thought that this would go in along with the other patches in
>> the
>> > > series.
>> > >
>> > > I can apply it directly, though, if needed.
>> > >
>> > > Thanks!
>> >
>> > I think at this point Jonathan can just take it in his tree with
>> his
>> > own patchset. Then I'll rebase this patchset on v6.1-rc1.
>>
>> Sure.
>>
>> Jonathan, please go ahead and take the patch directly.
>
> Too late for me to take this for this cycle (I route via Greg KH so
> need to have things
> in place a little bit before the merge window). If Lee doesn't pick
> it up, I'll do an
> immutable branch after rc1 is out with just this patch on it, then
> anyone who wants
> it can pick it up.
Rafael or Lee, can you take it now?
Or is it already too late? :(
-Paul
next prev parent reply other threads:[~2022-10-02 11:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 17:40 [PATCH v2 00/30] mfd: Remove #ifdef guards for PM functions Paul Cercueil
2022-08-08 17:40 ` [PATCH v2 01/30] pm: Improve EXPORT_*_DEV_PM_OPS macros Paul Cercueil
2022-08-13 14:49 ` Jonathan Cameron
2022-08-23 17:47 ` Rafael J. Wysocki
2022-08-25 22:42 ` Paul Cercueil
2022-09-25 14:52 ` Jonathan Cameron
2022-09-26 12:00 ` Rafael J. Wysocki
2022-09-26 13:27 ` Paul Cercueil
2022-09-26 13:35 ` Rafael J. Wysocki
2022-10-01 17:01 ` Jonathan Cameron
2022-10-02 11:18 ` Paul Cercueil [this message]
2022-10-04 18:54 ` Rafael J. Wysocki
2022-10-04 19:12 ` Paul Cercueil
2022-08-13 14:50 ` [PATCH v2 00/30] mfd: Remove #ifdef guards for PM functions Jonathan Cameron
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=02I4JR.BHDWVSR51INT1@crapouillou.net \
--to=paul@crapouillou.net \
--cc=jic23@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.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