> From: Daniel Vetter <daniel@xxxxxxxx>
> Sent: Tuesday, April 4, 2023 6:21 AM
> ...
> On Sat, 2 Jan 2021 at 07:03, Deepak Rawat <drawat.floss@xxxxxxxxx> wrote:
> > +/*
> > + * PCI/vmbus interface
> > + */
> > +
> > +static int hyperv_pci_probe(struct pci_dev *pdev,
> > + const struct pci_device_id *ent)
> > +{
> > + return 0;
> > +}
>
> Why do you have this dummy driver when it does nothing? Can it just be
> deleted? If it's just to have a driver, then we really don't need that
> on linux, there's no requirement to have a device driver for every
> device in a system.
>
> If you actually need to make sure that this pci device isn't passed to
> a guest vm or something like that, then the main driver must ensure
> that the pci driver is bound (ideally with component.c because
> otherwise you'll get the unbind/rebind dance wrong in one of the
> bazillion of subtle ways). Just having a driver doesn't stop anyone
> from unbinding it and then wreaking havoc.
> -Daniel
The hyperv_drm driver is a DRM version of the device driver for the
Hyper-V synthetic framebuffer VMBus device. Originally the device's
driver is hyperv_fb (drivers/video/fbdev/hyperv_fb.c), and commit
7ad968472160 ("hyperv-fb: add pci stub") introduced the dummy
pci_probe function in hyperv_fb:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7ad9684721606efbfb9b347346816e1e6baff8bb
hyperv_drm just copied the dummy pci_probe function from
hyperv_fb.
When a Linux VM runs on Hyper-V, it can be a Generation-1 VM
(legacy BIOS) or a Generation-2 VM (UEFI). In a Generation-1 VM,
the framebuffer device is presented to the VM both as a Hyper-V
synthetic framebuffer VMBus device and as a legacy PCI graphics
device. We'd like to let hyperv_fb or hyeprv_drm control the device,
and would like to avoid any PCI device driver for the legacy PCI
device, so commit 7ad968472160 uses the dummy pci_probe
function as a trick for this purpose. The commit says "Another
effect is that the xorg vesa driver will not attach to the device
and thus the Xorg server will automatically use the fbdev
driver instead."
As you pointed out, I suspect the unbind/rebind scenario is
still problematic, but AFAIK normally nobody would like to
do that.
Thanks,
Dexuan
