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: <CAHLCerNoRj6GQRF=NJXwc0U+mJNe=06JGADQr7uT-chD2W-J+A@mail.gmail.com>
Date:   Fri, 24 Aug 2018 01:32:39 +0530
From:   Amit Kucheria <amit.kucheria@...aro.org>
To:     Sudeep Holla <sudeep.holla@....com>, arm@...nel.org
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Liviu Dudau <liviu.dudau@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Orson Zhai <orsonzhai@...il.com>,
        Baolin Wang <baolin.wang@...aro.org>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Michal Simek <michal.simek@...inx.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Hou Zhiqiang <Zhiqiang.Hou@....com>,
        Minghuan Lian <minghuan.Lian@....com>,
        Yuantian Tang <andy.tang@....com>,
        Ran Wang <ran.wang_1@....com>,
        Fabio Estevam <fabio.estevam@....com>,
        Yuan Yao <yao.yuan@....com>, Sumit Garg <sumit.garg@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        Madalin Bucur <madalin.bucur@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Li Yang <leoyang.li@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        lakml <linux-arm-kernel@...ts.infradead.org>,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] arm64: dts: Fix various entry-method properties to
 reflect documentation

(Adding arm-soc folks)

On Thu, Aug 23, 2018 at 9:01 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> Hi Amit,
>
> Thanks for fixing this.
>
> On Thu, Aug 23, 2018 at 02:23:29PM +0530, Amit Kucheria wrote:
>> The idle-states binding documentation[1] mentions that the
>> 'entry-method' property is required on 64-bit platforms and must be
>> set to "psci".
>>
>> commit a13f18f59d26 ("Documentation: arm: Fix typo in the idle-states
>> bindings examples") attempted to fix this earlier but clearly more is
>> needed.
>>
>
> In fact, I assumed I fixed things with commit 978fa436231a ("drivers:
> firmware: psci: unify enable-method binding on ARM {64,32}-bit systems"),
> but I was wrong. I left quite a few instances including juno dtbs.
>
>> Fix the cpu-capacity.txt documentation that uses the incorrect value so
>> we don't get copy-paste errors like these. Clarify the language in
>> idle-states.txt by removing the reference to the psci bindings that
>> might be causing this confusion.
>>
>> Finally, fix devicetrees of various boards to reflect current
>> documentation.
>>
>> [1] Documentation/devicetree/bindings/arm/idle-states.txt (see
>> idle-states node)
>>
>> Signed-off-by: Amit Kucheria <amit.kucheria@...aro.org>
>> ---
>>  Documentation/devicetree/bindings/arm/cpu-capacity.txt | 2 +-
>>  Documentation/devicetree/bindings/arm/idle-states.txt  | 4 ++--
>>  arch/arm64/boot/dts/arm/juno-r1.dts                    | 2 +-
>>  arch/arm64/boot/dts/arm/juno-r2.dts                    | 2 +-
>>  arch/arm64/boot/dts/arm/juno.dts                       | 2 +-
>
> For all the above files,
>
> Acked-by: Sudeep Holla <sudeep.holla@....com>

Thanks for reviewing, Sudeep.

> How do you plan to merge ? I prefer if you can send it via arm-soc as
> fixes for this cycle with all the necessary acks. Otherwise you may have
> to split this to send via platform maintainers which is bit mundane.

I was hoping to get this merged thru arm-soc tree instead of creating
a patch per platform. But if anybody feels strongly about it, I'm
happy to split them up and feed it through the platform maintainer
trees.

Regards,
Amit

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ