[PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

[Ard Biesheuvel]

> On 29 apr. 2016, at 22:06, Bjorn Helgaas <helgaas at kernel.org> wrote:
> 
>> On Fri, Apr 29, 2016 at 03:51:49PM +0200, Ard Biesheuvel wrote:
>>> On 29 April 2016 at 15:41, Bjorn Helgaas <helgaas at kernel.org> wrote:
>>>> On Thu, Apr 28, 2016 at 11:39:35PM +0200, Alexander Graf wrote:
>>>> On 28.04.16 20:06, Bjorn Helgaas wrote:
> 
>>>>> If firmware is giving us a bare address of something, that seems like
>>>>> a clue that it might depend on that address staying the same.
>>>> 
>>>> Well, I'd look at it from the other side. It gives us a correct address
>>>> on entry with the system configured at exactly the state it's in on
>>>> entry. If Linux changes the system, some guarantees obviously don't work
>>>> anymore.
>>> 
>>> Can you point me to the part of the EFI spec that communicates this?
>>> I'm curious what the intent is and whether there's any indication that
>>> EFI expects the OS to preserve some configuration.  I don't think it's
>>> reasonable for the OS to preserve this sort of configuration because
>>> it limits how well we can support hotplug.
>>> 
>>> I wonder if we're using this frame buffer address as more than what
>>> EFI intended.  For example, maybe it was intended for use by an early
>>> console driver, but there's some other mechanism we should be using
>>> after that.
>> 
>> The UEFI spec describes this as follows (UEFIv2.6 section 11.9)
>> 
>> """
>> Graphics output may also be required as part of the startup of an
>> operating system. There are
>> potentially times in modern operating systems prior to the loading of
>> a high performance OS
>> graphics driver where access to graphics output device is required.
>> The Graphics Output Protocol
>> supports this capability by providing the EFI OS loader access to a
>> hardware frame buffer and
>> enough information to allow the OS to draw directly to the graphics
>> output device.
>> """
>> 
>> So the intent is to provide minimal framebuffer services until the
>> 'real' driver takes over.
> 
> Makes sense.  A 'real' driver for a PCI device would use
> pci_register_driver() and use pci_resource_start() or similar to
> locate the framebuffer, which would avoid the problem because the PCI
> core doesn't change BARs while a driver owns the device.
> 
>> The GOP protocol only describes the base and size of the framebuffer,
>> and the pixel format. At boot time, the early UEFI code in the kernel
>> could potentially figure out which PCI device it is related to, if
>> necessary, but i am not sure if this would solve the x86 case as well.
> 
> Does drivers/video/fbdev/efifb.c support only a single framebuffer
> device?  If a system has several, how does it decide which to use?  I
> assume UEFI would provide GOP for all the framebuffers?
> 

Yes. The early efi code iterates over all gop instances to figure out which one is connected to the efi console.

> If we could fix this by making efifb claim a PCI device, I think that
> would be cleaner.  I don't know how to figure out the correct device,
> but that would solve the "BAR changed" problem, and it would have
> cleaner ownership semantics, too.

If the bus layout is static, the efi init code can record the segment/bus/device and match it with the kernel's view. is that guaranteed to be sufficient for all implementations of pci?

> It looks like the current situation is that a device-specific driver
> (radeon, i915, etc.) could claim the device via the usual
> pci_register_driver() path, and the efifb driver could think it owns
> the device at the same time.  This seems like too obvious a problem,
> so maybe there's some ad hoc mechanism that resolves this?