From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Thu, 30 Mar 2017 11:09:56 +0100 Subject: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer In-Reply-To: <20170330100524.GA22801@red-moon> References: <1490196629-28088-1-git-send-email-ard.biesheuvel@linaro.org> <20170322193111.GA8190@wunner.de> <20170323084819.GA23281@h08.hostsharing.net> <20170323105727.GA2441@red-moon> <466dcd2b-a781-2fe7-6ef0-5a3767c793e0@codeaurora.org> <27f50de3-721e-e8ec-00c8-b7a9d3cff0d6@codeaurora.org> <20170330100524.GA22801@red-moon> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 30 March 2017 at 11:05, Lorenzo Pieralisi wrote: > On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote: > > [...] > >> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead >> > of working around it by quirks. >> > >> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems. >> > >> > Legacy only applies to DT based systems. >> > >> >> I fully agree with this point: ACPI implies firmware, and so we should >> be able to rely on firmware to have initialized the PCIe subsystem by >> the time the kernel gets to access it. > > https://lkml.org/lkml/2016/3/3/458 > I don't think the fact that at least one system existed over a year ago whose UEFI assigned resources incorrectly should prevent us from being normative in this case.