From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Subject: Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer To: Ard Biesheuvel , Lorenzo Pieralisi , Bjorn Helgaas 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> From: Sinan Kaya Message-ID: Date: Thu, 30 Mar 2017 09:50:04 -0400 MIME-Version: 1.0 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-efi@vger.kernel.org" , Matt Fleming , linux-pci , Peter Jones , Heyi Guo , Lukas Wunner , Hanjun Guo , Yinghai Lu , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On 3/30/2017 9:38 AM, Ard Biesheuvel wrote: > On 30 March 2017 at 11:09, Ard Biesheuvel wrote: >> 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. > > In any case, given that EFIFB is enabled by default on some distros, > and the fact that DT boot is affected as well, I should get this patch > in to prevent serious potential issues that could arise when someone > with a graphical UEFI stack updates to such a new kernel. > > So I think we are in agreement that this is needed on both ARM and > arm64, since their PCI configuration is usually not preserved. The > open question is whether there is any harm in enabling it for x86 as > well. > Agreed, the other issue is about compatibility with UEFI and future proofing Linux for other potential issues like hotplug reservation. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel