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

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

 



On Wed, Mar 22, 2017 at 12:39:57PM +0000, Ard Biesheuvel wrote:

[...]

> >> Well, it turned out that this does not actually work: the BAR is not
> >> reassigned, but the same range ends up being given to another device
> >> in some cases.
> >
> > Ok, that's because the PCI core just prevent assigning that resource
> > but it does not request it (ie insert it in the resource tree) which
> > is what you do when claiming it.
> >
> 
> Yes, that seems to be what is happening.
> 
> > I wonder how IORESOURCE_PCI_FIXED works on eg x86, I think it is time
> > to have a proper look into resources allocation code because there
> > are bits and pieces that are quite obscure to me.
> >
> 
> I did a quick test with calling request_mem_region(), in which case we
> end up with something like
> 
> 10000000-3efeffff : PCI Bus 0000:00
>   10000000-101d4bff : efifb:pci
>   101d5000-101d5fff : 0000:00:01.0
>   101d6000-101d6fff : 0000:00:02.0
>   101d7000-101d7fff : 0000:00:04.0
>     101d7000-101d7fff : ehci_hcd
>   101d8000-101d8fff : 0000:00:05.0
>   101e0000-101effff : 0000:00:05.0
>   10200000-1023ffff : 0000:00:02.0
> 
> which works, because the region is no longer assigned to another BAR.
> 
> But I think claiming the resource via the PCI subsystem is probably
> more appropriate, because then we get

Yes it is.

> 10000000-3efeffff : PCI Bus 0000:00
>   10000000-10ffffff : 0000:00:05.0
>     10000000-101d4fff : efifb
>   11000000-1103ffff : 0000:00:02.0
>   11040000-1104ffff : 0000:00:05.0
>   11050000-11050fff : 0000:00:01.0
>   11051000-11051fff : 0000:00:02.0
>   11052000-11052fff : 0000:00:04.0
>     11052000-11052fff : ehci_hcd
>   11053000-11053fff : 0000:00:05.0
> 
> (Note that efifb does not use the entire BAR resource)
> 
> > I think I would reverse the order in which you carry out the BAR
> > reservation anyway (first check if the device is enabled second request
> > the resource ie claim it).
> >
> 
> I will spin a v3 with the check and the claim in reverse order. But I
> think we should keep the pci_claim() call.

Agreed.

Thanks,
Lorenzo



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux