linux-kernel - Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 5 May 2017 11:33:47 -0400
From:   Jon Masters <jcm@...hat.com>
To:     Will Deacon <will.deacon@....com>,
        David Daney <ddaney.cavm@...il.com>
Cc:     Hanjun Guo <hanjun.guo@...aro.org>,
        Geetha sowjanya <gakula@...iumnetworks.com>,
        robin.murphy@....com, lorenzo.pieralisi@....com,
        sudeep.holla@....com, iommu@...ts.linux-foundation.org,
        Geetha Sowjanya <geethasowjanya.akula@...ium.com>,
        linu.cherian@...ium.com, linux-kernel@...r.kernel.org,
        geethasowjanya.akula@...il.com, linux-acpi@...r.kernel.org,
        robert.richter@...ium.com, catalin.marinas@....com,
        sgoutham@...ium.com, linux-arm-kernel@...ts.infradead.org,
        Charles.Garcia-Tobin@....com
Subject: Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model
 definition.

On 05/05/2017 10:58 AM, Will Deacon wrote:
> On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote:
>> On 05/05/2017 06:53 AM, Hanjun Guo wrote:
>>> On 2017/5/5 20:08, Geetha sowjanya wrote:
>>>> From: Linu Cherian <linu.cherian@...ium.com>

>>>> +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x00000002 /* Cavium ThunderX2
>>>> SMMUv3 */
>>>
>>> There are some other model numbers in the unreleased spec,
>>> I think we need to wait for the updated IORT spec to
>>> be released.

Indeed. I've synced with the author on this and he's got it in hand.

>> ... or if we are fairly confident that the identifier will not need to
>> change, we can merge this as is and establish a de facto specification that
>> the Real IORT specification will then be forced to follow.

Can't do that - this always causes trouble ;) But if there's any delay
I'll ask that the IDs at least be listed somewhere public or something.

>> Is there anything other than bureaucratic inertia holding up the real
>> specification?
> 
> My understanding is that IORT is going to be published imminently (i.e.
> before the next kernel release), so it makes sense to wait rather than fork
> the spec.

Let's track this and get the updated patches posted next week once the
new ID drops. Meanwhile, I suggest reviewing them as-is for other
issues. I'm tracking this for internal purposes and require this to be
upstream asap so I'll be sitting on this thread for updates ;)

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop