Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux