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: <b1462fb5-df86-45d9-9f67-697321e2b7dc@linaro.org>
Date: Mon, 15 Apr 2024 22:00:05 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Rob Herring <robh@...nel.org>
Cc: Bjorn Andersson <quic_bjorande@...cinc.com>, soc@...nel.org,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Dinh Nguyen <dinguyen@...nel.org>,
 Tsahee Zidenberg <tsahee@...apurnalabs.com>,
 Antoine Tenart <atenart@...nel.org>,
 Khuong Dinh <khuong@...amperecomputing.com>,
 Liviu Dudau <liviu.dudau@....com>, Sudeep Holla <sudeep.holla@....com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>, Ray Jui <rjui@...adcom.com>,
 Scott Branden <sbranden@...adcom.com>, Robert Richter <rric@...nel.org>,
 Shawn Guo <shawnguo@...nel.org>, Li Yang <leoyang.li@....com>,
 Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, "Paul J. Murphy"
 <paul.j.murphy@...el.com>,
 Daniele Alessandrelli <daniele.alessandrelli@...el.com>,
 Andrew Lunn <andrew@...n.ch>, Gregory Clement <gregory.clement@...tlin.com>,
 Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Thierry Reding <thierry.reding@...il.com>,
 Jonathan Hunter <jonathanh@...dia.com>,
 Bjorn Andersson <andersson@...nel.org>, Andreas Färber
 <afaerber@...e.de>, Heiko Stuebner <heiko@...ech.de>,
 Orson Zhai <orsonzhai@...il.com>, Baolin Wang
 <baolin.wang@...ux.alibaba.com>, Chunyan Zhang <zhang.lyra@...il.com>,
 Jisheng Zhang <jszhang@...nel.org>, Alim Akhtar <alim.akhtar@...sung.com>,
 linux-fsd@...la.com, Michal Simek <michal.simek@....com>,
 devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 imx@...ts.linux.dev, linux-mediatek@...ts.infradead.org,
 linux-tegra@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 linux-realtek-soc@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH] arm/arm64: dts: Drop "arm,armv8-pmuv3" compatible usage



On 4/15/24 19:41, Dmitry Baryshkov wrote:
> On Mon, 15 Apr 2024 at 20:15, Rob Herring <robh@...nel.org> wrote:
>>
>> On Mon, Apr 15, 2024 at 12:05 PM Rob Herring <robh@...nel.org> wrote:
>>>
>>> On Mon, Apr 15, 2024 at 11:52 AM Dmitry Baryshkov
>>> <dmitry.baryshkov@...aro.org> wrote:
>>>>
>>>> On Mon, 15 Apr 2024 at 16:46, Bjorn Andersson <quic_bjorande@...cinc.com> wrote:
>>>>>
>>>>> On Fri, Apr 12, 2024 at 05:28:51PM -0500, Rob Herring wrote:
>>>>> [..]
>>>>>>   arch/arm64/boot/dts/qcom/qcm2290.dtsi                | 2 +-
>>>>>>   arch/arm64/boot/dts/qcom/qdu1000.dtsi                | 2 +-
>>>>>>   arch/arm64/boot/dts/qcom/sdm630.dtsi                 | 2 +-
>>>>>>   arch/arm64/boot/dts/qcom/sdx75.dtsi                  | 2 +-
>>>>>
>>>>> Acked-by: Bjorn Andersson <andersson@...nel.org>
>>>>
>>>> Note, we'd need to override PMU compatibles in sdm636.dtsi and
>>>> sdm660.dtsi. Ideally it should come as the same patch.
>>>
>>> Uh, that's an A for reuse, but an F for readability... It's sdm632 as
>>> well. Will drop sdm630.
>>
>> Actually, aren't those Kryo cores just Cortex-A53 derivatives? So the
>> A53 PMU compatible is an improvement over the generic one still. We
>> can't just add kryo260-pmu compatibles because that breaks
>> compatibility. We could have a fallback, but then that introduces a
>> pattern we don't want.
> 
> I think it is believed that Gold cores are A73-derivatives.

8xA53 on 630
4xA53+4xA73 on 636/660

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ