[v9,00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)
mbox series

Message ID 20181003143824.13059-1-ulf.hansson@linaro.org
Headers show
Series
  • PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)
Related show

Message

Ulf Hansson Oct. 3, 2018, 2:38 p.m. UTC
I have digested the review comments so far, including a recent offlist chat
with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
have a plan for how to move forward.

However, to avoid re-posting non-changed patches over and over again, I decided
to withhold the more debatable part from this v9, hence this is not the complete
series to make things play. In v9, I have just included the trivial changes,
which are either already acked/reviewed or hopefully can be rather soon/easily.

My hope is to get this queued for v4.20, to move things forward. I know it's
late, but there are more or less nothing new here since v8.

Kind regards
Ulf Hansson

Changes in v9:
 - Collect only a subset from the changes in v8.
 - Patch 3 is new, documenting existing genpd flags. Future wise, this means
when a new genpd flag is invented, we must also properly document it.
 - No changes have been made to the patches picked from v8.
 - Dropped the text from v8 cover-letter[1], to avoid confusion. When posting v10
(or whatever the next version containing the rest becomes), I am going re-write
the cover-letter to clarify, more exactly, the problems this series intends to
solve. The earlier text was simply too vague.

[1]
https://lwn.net/Articles/758091/

Changes in v8:
 - Added some tags for reviews and acks.
 - Cleanup timer patch (patch6) according to comments from Rafael.
 - Rebased series on top of v4.18rc1 - it applied cleanly, except for patch 5.
 - While adopting patch 5 to new genpd changes, I took the opportunity to
   improve the new function description a bit.
 - Corrected malformed SPDX-License-Identifier in patch20.

Changes in v7:
 - Addressed comments concerning the PSCI changes from Mark Rutland, which moves
   the psci firmware driver to a new firmware subdir and change to force PSCI PC
   mode during boot to cope with kexec'ed booted kernels.
 - Added some maintainers in cc for the timer/nohz patches.
 - Minor update to the new genpd governor, taking into account the state's
   poweroff latency while validating the sleep duration time.
 - Addressed a problem pointed out by Geert Uytterhoeven, around calling
   pm_runtime_get|put() for CPUs that has not been attached to a CPU PM domain.
 - Re-based on Linus' latest master.


Lina Iyer (3):
  dt: psci: Update DT bindings to support hierarchical PSCI states
  cpuidle: dt: Support hierarchical CPU idle states
  drivers: firmware: psci: Support hierarchical CPU idle states

Ulf Hansson (8):
  PM / Domains: Don't treat zero found compatible idle states as an
    error
  PM / Domains: Deal with multiple states but no governor in genpd
  PM / Domains: Document flags for genpd
  of: base: Add of_get_cpu_state_node() to get idle states for a CPU
    node
  drivers: firmware: psci: Move psci to separate directory
  MAINTAINERS: Update files for PSCI
  drivers: firmware: psci: Split psci_dt_cpu_init_idle()
  drivers: firmware: psci: Simplify error path of psci_dt_init()

 .../devicetree/bindings/arm/psci.txt          | 156 ++++++++++++++++++
 MAINTAINERS                                   |   2 +-
 drivers/base/power/domain.c                   |  20 ++-
 drivers/cpuidle/dt_idle_states.c              |   5 +-
 drivers/firmware/Kconfig                      |  15 +-
 drivers/firmware/Makefile                     |   3 +-
 drivers/firmware/psci/Kconfig                 |  13 ++
 drivers/firmware/psci/Makefile                |   4 +
 drivers/firmware/{ => psci}/psci.c            |  70 ++++----
 drivers/firmware/{ => psci}/psci_checker.c    |   0
 drivers/of/base.c                             |  35 ++++
 include/linux/of.h                            |   8 +
 include/linux/pm_domain.h                     |  35 +++-
 13 files changed, 302 insertions(+), 64 deletions(-)
 create mode 100644 drivers/firmware/psci/Kconfig
 create mode 100644 drivers/firmware/psci/Makefile
 rename drivers/firmware/{ => psci}/psci.c (95%)
 rename drivers/firmware/{ => psci}/psci_checker.c (100%)

Comments

Rafael J. Wysocki Oct. 4, 2018, 8:39 a.m. UTC | #1
On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> I have digested the review comments so far, including a recent offlist chat
> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> have a plan for how to move forward.
>
> However, to avoid re-posting non-changed patches over and over again, I decided
> to withhold the more debatable part from this v9, hence this is not the complete
> series to make things play. In v9, I have just included the trivial changes,
> which are either already acked/reviewed or hopefully can be rather soon/easily.
>
> My hope is to get this queued for v4.20, to move things forward. I know it's
> late, but there are more or less nothing new here since v8.

I have no problems with the first three patches in this series, so I
can apply them right away.  Do you want me to do that?

As for the rest, the cpuidle driver patch looks OK to me, but the
PSCI-related ones need ACKs.

Thanks,
Rafael
Ulf Hansson Oct. 4, 2018, 8:58 a.m. UTC | #2
On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> I have digested the review comments so far, including a recent offlist chat
>> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
>> have a plan for how to move forward.
>>
>> However, to avoid re-posting non-changed patches over and over again, I decided
>> to withhold the more debatable part from this v9, hence this is not the complete
>> series to make things play. In v9, I have just included the trivial changes,
>> which are either already acked/reviewed or hopefully can be rather soon/easily.
>>
>> My hope is to get this queued for v4.20, to move things forward. I know it's
>> late, but there are more or less nothing new here since v8.
>
> I have no problems with the first three patches in this series, so I
> can apply them right away.  Do you want me to do that?

Yes, please.

>
> As for the rest, the cpuidle driver patch looks OK to me, but the
> PSCI-related ones need ACKs.

For some yes, but I think you can go ahead with a few more.

Patch 4, 5 is already acked/reviewed.

Patch 6 should be fine (if you are okay with it else wait for an ack
from Daniel)

Patch 7 and 8 should be fine. They were suggested by Mark.

Patch 9 and 10 needs acks.

Patch 11 has been acked, but depends on the other PSCI changes.

Kind regards
Uffe
Rafael J. Wysocki Oct. 4, 2018, 9:01 a.m. UTC | #3
On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >>
> >> I have digested the review comments so far, including a recent offlist chat
> >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> >> have a plan for how to move forward.
> >>
> >> However, to avoid re-posting non-changed patches over and over again, I decided
> >> to withhold the more debatable part from this v9, hence this is not the complete
> >> series to make things play. In v9, I have just included the trivial changes,
> >> which are either already acked/reviewed or hopefully can be rather soon/easily.
> >>
> >> My hope is to get this queued for v4.20, to move things forward. I know it's
> >> late, but there are more or less nothing new here since v8.
> >
> > I have no problems with the first three patches in this series, so I
> > can apply them right away.  Do you want me to do that?
> 
> Yes, please.
> 
> >
> > As for the rest, the cpuidle driver patch looks OK to me, but the
> > PSCI-related ones need ACKs.
> 
> For some yes, but I think you can go ahead with a few more.
> 
> Patch 4, 5 is already acked/reviewed.
> 
> Patch 6 should be fine (if you are okay with it else wait for an ack
> from Daniel)

OK, thanks.

Do the 4-6 depend on the 1-3?

> Patch 7 and 8 should be fine. They were suggested by Mark.

I'd rather have ACKs on these two as well.

> Patch 9 and 10 needs acks.
> 
> Patch 11 has been acked, but depends on the other PSCI changes.

OK
Rafael J. Wysocki Oct. 4, 2018, 9:32 a.m. UTC | #4
On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >>
> > >> I have digested the review comments so far, including a recent offlist chat
> > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> > >> have a plan for how to move forward.
> > >>
> > >> However, to avoid re-posting non-changed patches over and over again, I decided
> > >> to withhold the more debatable part from this v9, hence this is not the complete
> > >> series to make things play. In v9, I have just included the trivial changes,
> > >> which are either already acked/reviewed or hopefully can be rather soon/easily.
> > >>
> > >> My hope is to get this queued for v4.20, to move things forward. I know it's
> > >> late, but there are more or less nothing new here since v8.
> > >
> > > I have no problems with the first three patches in this series, so I
> > > can apply them right away.  Do you want me to do that?
> >
> > Yes, please.
> >
> > >
> > > As for the rest, the cpuidle driver patch looks OK to me, but the
> > > PSCI-related ones need ACKs.
> >
> > For some yes, but I think you can go ahead with a few more.
> >
> > Patch 4, 5 is already acked/reviewed.
> >
> > Patch 6 should be fine (if you are okay with it else wait for an ack
> > from Daniel)
>
> OK, thanks.
>
> Do the 4-6 depend on the 1-3?

I don't see any dependency there, so I'll queue up the 1-3 in
pm-domains and the 4-6 in pm-cpuidle.

Thanks,
Rafael
Ulf Hansson Oct. 4, 2018, 10:10 a.m. UTC | #5
On 4 October 2018 at 11:32, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>>
>> On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
>> > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> > >>
>> > >> I have digested the review comments so far, including a recent offlist chat
>> > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
>> > >> have a plan for how to move forward.
>> > >>
>> > >> However, to avoid re-posting non-changed patches over and over again, I decided
>> > >> to withhold the more debatable part from this v9, hence this is not the complete
>> > >> series to make things play. In v9, I have just included the trivial changes,
>> > >> which are either already acked/reviewed or hopefully can be rather soon/easily.
>> > >>
>> > >> My hope is to get this queued for v4.20, to move things forward. I know it's
>> > >> late, but there are more or less nothing new here since v8.
>> > >
>> > > I have no problems with the first three patches in this series, so I
>> > > can apply them right away.  Do you want me to do that?
>> >
>> > Yes, please.
>> >
>> > >
>> > > As for the rest, the cpuidle driver patch looks OK to me, but the
>> > > PSCI-related ones need ACKs.
>> >
>> > For some yes, but I think you can go ahead with a few more.
>> >
>> > Patch 4, 5 is already acked/reviewed.
>> >
>> > Patch 6 should be fine (if you are okay with it else wait for an ack
>> > from Daniel)
>>
>> OK, thanks.
>>
>> Do the 4-6 depend on the 1-3?
>
> I don't see any dependency there, so I'll queue up the 1-3 in
> pm-domains and the 4-6 in pm-cpuidle.

Great, thanks!

Make sure you put the remaining of the PSCI changes on pm-cpuidle
(once acked), as there are dependency.

Kind regards
Uffe
Lorenzo Pieralisi Oct. 4, 2018, 3:57 p.m. UTC | #6
On Thu, Oct 04, 2018 at 11:32:41AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> > > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >>
> > > >> I have digested the review comments so far, including a recent offlist chat
> > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> > > >> have a plan for how to move forward.
> > > >>
> > > >> However, to avoid re-posting non-changed patches over and over again, I decided
> > > >> to withhold the more debatable part from this v9, hence this is not the complete
> > > >> series to make things play. In v9, I have just included the trivial changes,
> > > >> which are either already acked/reviewed or hopefully can be rather soon/easily.
> > > >>
> > > >> My hope is to get this queued for v4.20, to move things forward. I know it's
> > > >> late, but there are more or less nothing new here since v8.
> > > >
> > > > I have no problems with the first three patches in this series, so I
> > > > can apply them right away.  Do you want me to do that?
> > >
> > > Yes, please.
> > >
> > > >
> > > > As for the rest, the cpuidle driver patch looks OK to me, but the
> > > > PSCI-related ones need ACKs.
> > >
> > > For some yes, but I think you can go ahead with a few more.
> > >
> > > Patch 4, 5 is already acked/reviewed.
> > >
> > > Patch 6 should be fine (if you are okay with it else wait for an ack
> > > from Daniel)
> >
> > OK, thanks.
> >
> > Do the 4-6 depend on the 1-3?
> 
> I don't see any dependency there, so I'll queue up the 1-3 in
> pm-domains and the 4-6 in pm-cpuidle.

I do not see why we should merge patches 4-6 for v4.20; they add legacy
(DT bindings and related parsing code) with no user in the kernel; we
may still want to tweak them, in particular PSCI DT bindings.

Likewise, it makes no sense to merge patches 7-8 without the rest of
the PSCI patches.

Why do not we target v4.20-rc1 for the whole series re-posting and we take
it from there given that we are at -rc6 tail end ?

Thanks,
Lorenzo
Rafael J. Wysocki Oct. 4, 2018, 5:07 p.m. UTC | #7
On Thu, Oct 4, 2018 at 5:58 PM Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Thu, Oct 04, 2018 at 11:32:41AM +0200, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >
> > > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> > > > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > >>
> > > > >> I have digested the review comments so far, including a recent offlist chat
> > > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> > > > >> have a plan for how to move forward.
> > > > >>
> > > > >> However, to avoid re-posting non-changed patches over and over again, I decided
> > > > >> to withhold the more debatable part from this v9, hence this is not the complete
> > > > >> series to make things play. In v9, I have just included the trivial changes,
> > > > >> which are either already acked/reviewed or hopefully can be rather soon/easily.
> > > > >>
> > > > >> My hope is to get this queued for v4.20, to move things forward. I know it's
> > > > >> late, but there are more or less nothing new here since v8.
> > > > >
> > > > > I have no problems with the first three patches in this series, so I
> > > > > can apply them right away.  Do you want me to do that?
> > > >
> > > > Yes, please.
> > > >
> > > > >
> > > > > As for the rest, the cpuidle driver patch looks OK to me, but the
> > > > > PSCI-related ones need ACKs.
> > > >
> > > > For some yes, but I think you can go ahead with a few more.
> > > >
> > > > Patch 4, 5 is already acked/reviewed.
> > > >
> > > > Patch 6 should be fine (if you are okay with it else wait for an ack
> > > > from Daniel)
> > >
> > > OK, thanks.
> > >
> > > Do the 4-6 depend on the 1-3?
> >
> > I don't see any dependency there, so I'll queue up the 1-3 in
> > pm-domains and the 4-6 in pm-cpuidle.
>
> I do not see why we should merge patches 4-6 for v4.20; they add legacy
> (DT bindings and related parsing code) with no user in the kernel; we
> may still want to tweak them, in particular PSCI DT bindings.

My impression was that 4-6 have been agreed on due to the ACKs they
carry.  I'll drop them if that's not the case.

> Likewise, it makes no sense to merge patches 7-8 without the rest of
> the PSCI patches.

OK

I'll let the ARM camp sort out the PSCI material then.

Thanks,
Rafael
Lorenzo Pieralisi Oct. 4, 2018, 5:21 p.m. UTC | #8
On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:

[...]

> > > I don't see any dependency there, so I'll queue up the 1-3 in
> > > pm-domains and the 4-6 in pm-cpuidle.
> >
> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
> > (DT bindings and related parsing code) with no user in the kernel; we
> > may still want to tweak them, in particular PSCI DT bindings.
> 
> My impression was that 4-6 have been agreed on due to the ACKs they
> carry.  I'll drop them if that's not the case.

I have not expressed myself correctly: they have been agreed (even
though as I said they may require some tweaking) but I see no urgency
of merging them in v4.20 since they have no user. They contain DT
bindings, that create ABI/legacy, I think it is better to have code
that uses them in the kernel before merging them and creating a
dependency that is not needed.

> > Likewise, it makes no sense to merge patches 7-8 without the rest of
> > the PSCI patches.
> 
> OK
> 
> I'll let the ARM camp sort out the PSCI material then.

We will do.

Thanks,
Lorenzo
Ulf Hansson Oct. 4, 2018, 6:36 p.m. UTC | #9
On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:
>
> [...]
>
>> > > I don't see any dependency there, so I'll queue up the 1-3 in
>> > > pm-domains and the 4-6 in pm-cpuidle.
>> >
>> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
>> > (DT bindings and related parsing code) with no user in the kernel; we
>> > may still want to tweak them, in particular PSCI DT bindings.
>>
>> My impression was that 4-6 have been agreed on due to the ACKs they
>> carry.  I'll drop them if that's not the case.
>
> I have not expressed myself correctly: they have been agreed (even
> though as I said they may require some tweaking) but I see no urgency
> of merging them in v4.20 since they have no user. They contain DT
> bindings, that create ABI/legacy, I think it is better to have code
> that uses them in the kernel before merging them and creating a
> dependency that is not needed.

There is already code using the new bindings, for the idle states.
Please have look at patch 5, 6 and 11.

Moreover, you have had plenty on time to look at the series, as those
patches haven't changed since a very long time.

May I suggest you do the review instead, so we can move things
forward, please. The changes in the v9 series should be trivial to
review.

>
>> > Likewise, it makes no sense to merge patches 7-8 without the rest of
>> > the PSCI patches.

Well, those patches are part of this series, because Mark wanted me to
move the files. Is really such a big deal? I think it makes sense, no
matter what happens afterwards.

[...]

Kind regards
Uffe
Ulf Hansson Oct. 4, 2018, 6:38 p.m. UTC | #10
On 4 October 2018 at 20:36, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:
>>
>> [...]
>>
>>> > > I don't see any dependency there, so I'll queue up the 1-3 in
>>> > > pm-domains and the 4-6 in pm-cpuidle.
>>> >
>>> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
>>> > (DT bindings and related parsing code) with no user in the kernel; we
>>> > may still want to tweak them, in particular PSCI DT bindings.
>>>
>>> My impression was that 4-6 have been agreed on due to the ACKs they
>>> carry.  I'll drop them if that's not the case.
>>
>> I have not expressed myself correctly: they have been agreed (even
>> though as I said they may require some tweaking) but I see no urgency
>> of merging them in v4.20 since they have no user. They contain DT
>> bindings, that create ABI/legacy, I think it is better to have code
>> that uses them in the kernel before merging them and creating a
>> dependency that is not needed.
>
> There is already code using the new bindings, for the idle states.
> Please have look at patch 5, 6 and 11.

Should be 5, 6 and 10, sorry.

>
> Moreover, you have had plenty on time to look at the series, as those
> patches haven't changed since a very long time.
>
> May I suggest you do the review instead, so we can move things
> forward, please. The changes in the v9 series should be trivial to
> review.
>
>>
>>> > Likewise, it makes no sense to merge patches 7-8 without the rest of
>>> > the PSCI patches.
>
> Well, those patches are part of this series, because Mark wanted me to
> move the files. Is really such a big deal? I think it makes sense, no
> matter what happens afterwards.
>
> [...]
>
> Kind regards
> Uffe
Lorenzo Pieralisi Oct. 5, 2018, 10:47 a.m. UTC | #11
On Thu, Oct 04, 2018 at 08:36:24PM +0200, Ulf Hansson wrote:
> On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> > On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> >> > > I don't see any dependency there, so I'll queue up the 1-3 in
> >> > > pm-domains and the 4-6 in pm-cpuidle.
> >> >
> >> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
> >> > (DT bindings and related parsing code) with no user in the kernel; we
> >> > may still want to tweak them, in particular PSCI DT bindings.
> >>
> >> My impression was that 4-6 have been agreed on due to the ACKs they
> >> carry.  I'll drop them if that's not the case.
> >
> > I have not expressed myself correctly: they have been agreed (even
> > though as I said they may require some tweaking) but I see no urgency
> > of merging them in v4.20 since they have no user. They contain DT
> > bindings, that create ABI/legacy, I think it is better to have code
> > that uses them in the kernel before merging them and creating a
> > dependency that is not needed.
> 
> There is already code using the new bindings, for the idle states.
> Please have look at patch 5, 6 and 11.

I had a look before replying and I reiterate the point, there is
no reason to merge those patches without the rest of the series,
none. There is already a way to describe idle states in the kernel
and it works very well, we will add one when we need it not before.

> Moreover, you have had plenty on time to look at the series, as those
> patches haven't changed since a very long time.

So ?

> May I suggest you do the review instead, so we can move things
> forward, please. The changes in the v9 series should be trivial to
> review.

There is no reason to merge patches [4, 5, 6, 10] stand-alone, they
are not solving any problem and they do not provide any benefit
other than adding useless ABI/legacy, they make sense when we look
at the whole series.

> >> > Likewise, it makes no sense to merge patches 7-8 without the rest of
> >> > the PSCI patches.
> 
> Well, those patches are part of this series, because Mark wanted me to
> move the files. Is really such a big deal? I think it makes sense, no
> matter what happens afterwards.

We can merge patches [7-8] even if there is no urgency at all to do so,
usually PSCI patches go via arm-soc whose patches queue is now closed
and I do not think that's a problem at all.

Lorenzo
Ulf Hansson Oct. 5, 2018, 11:49 a.m. UTC | #12
On 5 October 2018 at 12:47, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Oct 04, 2018 at 08:36:24PM +0200, Ulf Hansson wrote:
>> On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> > On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote:
>> >
>> > [...]
>> >
>> >> > > I don't see any dependency there, so I'll queue up the 1-3 in
>> >> > > pm-domains and the 4-6 in pm-cpuidle.
>> >> >
>> >> > I do not see why we should merge patches 4-6 for v4.20; they add legacy
>> >> > (DT bindings and related parsing code) with no user in the kernel; we
>> >> > may still want to tweak them, in particular PSCI DT bindings.
>> >>
>> >> My impression was that 4-6 have been agreed on due to the ACKs they
>> >> carry.  I'll drop them if that's not the case.
>> >
>> > I have not expressed myself correctly: they have been agreed (even
>> > though as I said they may require some tweaking) but I see no urgency
>> > of merging them in v4.20 since they have no user. They contain DT
>> > bindings, that create ABI/legacy, I think it is better to have code
>> > that uses them in the kernel before merging them and creating a
>> > dependency that is not needed.
>>
>> There is already code using the new bindings, for the idle states.
>> Please have look at patch 5, 6 and 11.
>
> I had a look before replying and I reiterate the point, there is
> no reason to merge those patches without the rest of the series,
> none. There is already a way to describe idle states in the kernel
> and it works very well, we will add one when we need it not before.

Okay, let's defer them.

>
>> Moreover, you have had plenty on time to look at the series, as those
>> patches haven't changed since a very long time.
>
> So ?
>
>> May I suggest you do the review instead, so we can move things
>> forward, please. The changes in the v9 series should be trivial to
>> review.
>
> There is no reason to merge patches [4, 5, 6, 10] stand-alone, they
> are not solving any problem and they do not provide any benefit
> other than adding useless ABI/legacy, they make sense when we look
> at the whole series.

Okay, let's defer them.

>
>> >> > Likewise, it makes no sense to merge patches 7-8 without the rest of
>> >> > the PSCI patches.
>>
>> Well, those patches are part of this series, because Mark wanted me to
>> move the files. Is really such a big deal? I think it makes sense, no
>> matter what happens afterwards.
>
> We can merge patches [7-8] even if there is no urgency at all to do so,
> usually PSCI patches go via arm-soc whose patches queue is now closed
> and I do not think that's a problem at all.

Okay, let's defer them.

That said, can please review the patches?

Kind regards
Uffe