From: Ulf Hansson <ulf.hansson@linaro.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Sudeep Holla <sudeep.holla@arm.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Lina Iyer <ilina@codeaurora.org>,
Linux PM <linux-pm@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/7] drivers: firmware: psci: Simplify state node parsing
Date: Fri, 8 Mar 2019 14:07:51 +0100 [thread overview]
Message-ID: <CAPDyKFry_ZQXA-bj6gA8npdqkMmg8AUOZ+Kr4mnOaS8=xZ+MwA@mail.gmail.com> (raw)
In-Reply-To: <20190308114943.GA27731@e107981-ln.cambridge.arm.com>
On Fri, 8 Mar 2019 at 12:49, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Fri, Mar 08, 2019 at 11:36:49AM +0100, Ulf Hansson wrote:
>
> [...]
>
> > Instead, my suggestion is according to what I propose in patch 4 and
> > $subject patch, which means minor adjustments to be able to pass the
> > struct cpuidle_driver * to the init functions. This, I need it for
> > next steps, but already at this point it improves things as it avoids
> > some of the OF parsing, and that's good, isn't it?
>
> I will take the patches Mark ACKed and send them for v5.2 as
> early as it gets in v5.1-rc* cycle.
Actually, may I suggest we funnel these through Rafael's tree, unless
you are expecting other PSCI changes for v.5.2, which could cause
conflicts?
The reason is, other PM core changes, to genpd for example, needs to
go via Rafael's tree. Those would then potentially block us for
applying any other changes to your tree (arm-soc?) for PSCI (as there
is dependency) until v5.3.
How about if you provides your explicit acks for those PSCI changes
your are happy with, then Rafael can pick them?
>
> For this one maybe you can post the changes on top and see what's
> the best way forward ?
>
> I agree that duplicating idle state parsing code across back-ends
> is silly - we just want to keep PSCI and kernel data structure
> decoupled.
Right. Let's continue this discussion later on and move forward here.
Make sense.
>
> Post the code on top and we will find a way forward, OK ?
Sure, let me do that.
Thanks and kind regards
Uffe
next prev parent reply other threads:[~2019-03-08 13:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 13:59 [PATCH 0/7] drivers: firmware: psci: Some cleanup and refactoring Ulf Hansson
2019-02-28 13:59 ` [PATCH 1/7] drivers: firmware: psci: Move psci to separate directory Ulf Hansson
2019-02-28 14:34 ` Daniel Lezcano
2019-03-01 17:03 ` Mark Rutland
2019-02-28 13:59 ` [PATCH 2/7] MAINTAINERS: Update files for PSCI Ulf Hansson
2019-02-28 14:35 ` Daniel Lezcano
2019-03-01 17:04 ` Mark Rutland
2019-02-28 13:59 ` [PATCH 3/7] drivers: firmware: psci: Split psci_dt_cpu_init_idle() Ulf Hansson
2019-02-28 14:42 ` Daniel Lezcano
2019-02-28 22:13 ` Ulf Hansson
2019-03-01 17:07 ` Mark Rutland
2019-02-28 13:59 ` [PATCH 4/7] ARM/ARM64: cpuidle: Let back-end init ops take the driver as input Ulf Hansson
2019-02-28 15:30 ` Daniel Lezcano
2019-03-01 17:31 ` Mark Rutland
2019-02-28 13:59 ` [PATCH 5/7] drivers: firmware: psci: Simplify state node parsing Ulf Hansson
2019-02-28 15:40 ` Daniel Lezcano
2019-02-28 22:26 ` Ulf Hansson
2019-02-28 22:41 ` Daniel Lezcano
2019-03-01 17:28 ` Mark Rutland
2019-03-04 10:14 ` Ulf Hansson
2019-03-06 18:15 ` Lorenzo Pieralisi
2019-03-08 10:36 ` Ulf Hansson
2019-03-08 11:49 ` Lorenzo Pieralisi
2019-03-08 13:07 ` Ulf Hansson [this message]
2019-03-08 13:17 ` Lorenzo Pieralisi
2019-03-08 13:23 ` Ulf Hansson
2019-03-08 13:31 ` Lorenzo Pieralisi
2019-03-08 13:43 ` Ulf Hansson
2019-02-28 13:59 ` [PATCH 6/7] drivers: firmware: psci: Simplify error path of psci_dt_init() Ulf Hansson
2019-02-28 13:59 ` [PATCH 7/7] drivers: firmware: psci: Announce support for OS initiated suspend mode Ulf Hansson
2019-03-01 17:28 ` Stephen Boyd
2019-03-04 10:25 ` Ulf Hansson
2019-03-01 17:32 ` Mark Rutland
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='CAPDyKFry_ZQXA-bj6gA8npdqkMmg8AUOZ+Kr4mnOaS8=xZ+MwA@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=ilina@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.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).