linux-kernel - RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

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: <BYAPR12MB282210175D43BF649E2C5F87B36C0@BYAPR12MB2822.namprd12.prod.outlook.com>
Date:   Wed, 1 Jul 2020 19:12:58 +0000
From:   Krishna Reddy <vdumpa@...dia.com>
To:     Robin Murphy <robin.murphy@....com>,
        Jonathan Hunter <jonathanh@...dia.com>
CC:     Sachin Nikam <Snikam@...dia.com>,
        "nicoleotsuka@...il.com" <nicoleotsuka@...il.com>,
        Mikko Perttunen <mperttunen@...dia.com>,
        "Bryan Huntsman" <bhuntsman@...dia.com>,
        "will@...nel.org" <will@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Pritesh Raithatha" <praithatha@...dia.com>,
        Timo Alho <talho@...dia.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Nicolin Chen <nicolinc@...dia.com>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Yu-Huan Hsu <YHsu@...dia.com>,
        Thierry Reding <treding@...dia.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Bitan Biswas <bbiswas@...dia.com>
Subject: RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual
 ARM MMU-500 usage

>Yeah, I realised later last night that this probably originated from forking the whole driver downstream. But even then you could have treated the other one as a separate nsmmu with a single instance ;)

True, But the initial nvidia implementation had limitation that it can only handle one instance of usage. With your implementation hooks design, it should be able to handle multiple instances of usage now.

>Since it does add a bit of confusion to the code and comments, let's just keep things simple. I do like Jon's suggestion of actually enforcing that the number of "reg" regions exactly matches the number expected for the given compatible - I guess for now that means just hard-coding 2 and hoping the hardware folks don't cook up any more of these...

For T194, reg can just be forced to 2. No future plan to use more than two MMU-500s together as of now. 

-KR