From: Thomas Zimmermann <[email protected]> Sent: Thursday, July 2, 2026 2:15 AM
> > Hi > > Am 02.07.26 um 10:52 schrieb Uwe Kleine-König (The Capable Hub): > > Hallo Thomas, > > > > On Thu, Jul 02, 2026 at 08:43:32AM +0200, Thomas Zimmermann wrote: > >> Am 01.07.26 um 19:05 schrieb Uwe Kleine-König (The Capable Hub): > >>> .subvendor and .subdevice were set to 0 implicitly, so only devices with > >>> these two values set to 0 in hardware can probe automatically. Make this > >>> requirement explicit. > >>> > >>> While touching this array item, also make use of the pci macro designed > >>> for that case. > >>> > >>> Signed-off-by: Uwe Kleine-König (The Capable Hub) > >>> <[email protected]> > >>> --- > >>> drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > >>> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > >>> index 2e75fb793495..e766d87b7a9d 100644 > >>> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > >>> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c > >>> @@ -51,8 +51,8 @@ static void hv_drm_pci_remove(struct pci_dev *pdev) > >>> static const struct pci_device_id hv_drm_pci_tbl[] = { > >>> { > >>> - .vendor = PCI_VENDOR_ID_MICROSOFT, > >>> - .device = PCI_DEVICE_ID_HYPERV_VIDEO, > >>> + PCI_VDEVICE_SUB(MICROSOFT, PCI_DEVICE_ID_HYPERV_VIDEO, > >>> + 0, 0), > >> IDK, but it looks like an oversight to me. Setting the sub-fields to ANY > >> seems like the better fix. > > That was my initial reflex, too. However while writing the commit log > > for that change I noticed that since commit d750785f305e ("Staging: hv: > > fix hv_utils module to properly autoload") from 2010 (applied to > > v2.6.35-rc4) the driver never worked for hardware with .subvendor != 0 > > or .subdevice != 0. I cannot believe that something like that is > > discovered 16 years later by chance during a rework by someone who > > didn't try to run that hardware. And if I understand correctly, this is > > emulated hardware and so I guess used quite a lot. > > I wouldn't be surprised. To my knowledge, there's just one > implementation of this device, which is Windows. If they clear their > host-side structures to 0 and pass them to the guest, no one would ever > notice the issue. But let's see what the driver maintainers can comment > on the issue. > Yes, the device is a synthetic device provided by a host that implements VMBus. Historically that's Windows Hyper-V, but alternate VMBus implementations are arising, such as in the paravisor used in some Azure VMs. That paravisor is also provided by Microsoft, though conceptually a customer could provide their own paravisor. Since current code is defaulting to requiring .subvendor and .subdevice to be zero, I think that requirement should continue even with this cleanup. That maintains strict consistency with current code. If there's ever a case where a different implementation of VMBus needs to identify the synthetic frame buffer device differently, that's likely because of other changes in how the device presents itself. Any tweaks to the device id matching can be included then as part of whatever other changes are needed to the driver. Just my $.02 .... As such, Reviewed-by: Michael Kelley <[email protected]>
