Re: [PATCH v1 2/4] drm/hyperv: Explicitly set subvendor and subdevice for pci match array
Thomas Zimmermann <[email protected]>
| Newsgroups | org.kernel.vger.linux-hyperv,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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. Best regards Thomas > > Best regards > Uwe -- -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)