[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3014DA56-84D8-474B-94FE-6FDBB6241F9F@infradead.org>
Date: Wed, 17 Mar 2021 13:37:16 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Joerg Roedel <joro@...tes.org>
CC: iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Huang Rui <ray.huang@....com>,
Suravee Suthikulpanit <suravee.suthikulpanit@....com>,
Alex Deucher <alexander.deucher@....com>,
Xiaojian Du <xiaojian.du@....com>,
Joerg Roedel <jroedel@...e.de>, stable@...r.kernel.org
Subject: Re: [PATCH 2/3] iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled
On 17 March 2021 13:32:35 GMT, Joerg Roedel <joro@...tes.org> wrote:
>On Wed, Mar 17, 2021 at 11:47:11AM +0000, David Woodhouse wrote:
>> If you've already moved the Stoney Ridge check out of the way,
>there's
>> no real reason why you can't just set
>init_state=IOMMU_CMDLINE_DISABLED
>> directly from parse_amd_iommu_options(), is there? Then you don't
>need
>> the condition here at all?
>
>True, there is even more room for optimization. The amd_iommu_disabled
>variable can go away entirely, including its checks in
>early_amd_iommu_init(). I will do a patch-set on-top of this for v5.13
>which does more cleanups.
If we can get to the point where we don't even need to check amd_iommu_irq_remap in the ...select() function because the IRQ domain is never even registered in the case where the flag ends up false, all the better :)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists