On 22 March 2017 at 19:31, Lukas Wunner <lukas@xxxxxxxxx> wrote: > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote: >> On UEFI systems, the PCI subsystem is enumerated by the firmware, >> and if a graphical framebuffer is exposed by a PCI device, its base >> address and size are exposed to the OS via the Graphics Output >> Protocol (GOP). >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from >> scratch at boot. This may result in the GOP framebuffer address to >> become stale, if the BAR covering the framebuffer is modified. This >> will cause the framebuffer to become unresponsive, and may in some >> cases result in unpredictable behavior if the range is reassigned to >> another device. > > Hm, commit message seems to indicate the issue is restricted to arm64, > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch? > True. I am eager to get some x86 coverage for this, since I would expect this not to do any harm. But I'm fine with making it ARM/arm64 specific in the final version. > >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources); > > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY? > How does one do that with DECLARE_PCI_FIXUP_HEADER?
