linux-kernel - Re: [PATCH v9 00/11] PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFquOR91qnTcXU63MBSY6m=uhOw+HpGvy_jiRy6_MO3Lbg@mail.gmail.com>
Date:   Fri, 5 Oct 2018 13:49:00 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Mark Rutland <mark.rutland@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Tony Lindgren <tony@...mide.com>,
        Kevin Hilman <khilman@...nel.org>,
        Lina Iyer <ilina@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 00/11] PM / Domains: Support hierarchical CPU
 arrangement (PSCI/ARM) (a subset)

On 5 October 2018 at 12:47, Lorenzo Pieralisi <lorenzo.pieralisi@....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@....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