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] [day] [month] [year] [list]
Message-ID: <24673fd9-3c1c-04f6-eb2e-525f8546ebf3@codeaurora.org>
Date:   Thu, 31 Oct 2019 08:17:18 -0600
From:   Jeffrey Hugo <jhugo@...eaurora.org>
To:     Will Deacon <will@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v2] arm64: cpufeature: Enable Qualcomm Falkor errata 1009
 for Kryo

On 10/31/2019 6:29 AM, Will Deacon wrote:
> [+Jeffrey]
> 
> On Tue, Oct 29, 2019 at 04:27:38PM -0700, Bjorn Andersson wrote:
>> The Kryo cores share errata 1009 with Falkor, so add their model
>> definitions and enable it for them as well.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
>> ---
>>
>> Changes since v1:
>> - Use is_kryo_midr(), rather than listing each individual model.
> 
> Cheers, I've queued this up as a fix.
> 
> I also updated the E1009 entry in silicon-errata.rst but, in doing so, I
> noticed that E1041 is listed there which apparently also affects
> Kry^H^H^HHydra [1].
> 
> At which point, maybe we should rename both Kryo and Falkor in the tree
> so that we consistently refer to Hydra as the underlying micro-architecture.
> Obviously not something for 5.4, but it would sure help me to understand
> what's doing on here.
> 
> Thoughts?

Unfortunately, Falkor is also an underlying micro-architecture, it just 
happens to be strongly related to Hydra so a fair amount of the errata 
affect both.

I don't want to be difficult.  For ultimate "correctness", Falkor and 
Hydra should probably be separate, however the Falkor architecture is 
not widespread and unlikely to have much churn going forward.  So I 
think if it makes life easier for you, all the Falkor stuff can probably 
be scrubbed and just merged into Hydra.

> 
> Will
> 
> [1] https://lore.kernel.org/kvmarm/20171115010505.GO11955@codeaurora.org/
> 


-- 
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ