On Wed, Mar 25, 2015 at 03:52:01PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
> > > index e894eb2..a3167fa 100644
> > > --- a/drivers/virtio/virtio_pci_common.c
> > > +++ b/drivers/virtio/virtio_pci_common.c
> > > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_dev,
> > > goto err_enable_device;
> > >
> > > rc = pci_request_regions(pci_dev, "virtio-pci");
> > > - if (rc)
> > > + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA))
> > > goto err_request_regions;
> > >
> > > if (force_legacy) {
> >
> > This is probably what you described as "the only concern?
>
> Ahem, no, forgot that one,
What does the concern refer to then?
> but it is related. With vesafb using and
> registering the vga compat framebuffer bar pci_request_regions will not
> succeed.
>
> vesafb will be unregistered later on (this is what I was refering to) by
> the virtio-gpu driver.
>
> > If we only need to request specific
> > regions, I think we should do exactly that, requesting only parts of
> > regions that are covered by the virtio capabilities.
>
> That should work too.
>
> cheers,
> Gerd
BTW can we teach virtio-gpu to look for framebuffer using
virtio pci caps? Or are there limitations such as only
using IO port BARs, or compatibility with
BIOS code etc that limit us to specific BARs anyway?
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
