On Thu, Oct 02, 2025 at 02:08:27PM +0200, Danilo Krummrich wrote: > Why? What about other upstream drivers that clearly assert that they don't > support VFs?
They shouldn't be doing that either. There is lots of junk in Linux, that doesn't mean it should be made first-class to encourage more people to do the wrong thing. > Why would we want to force them to try to boot to a point where > they "naturally" fail? We want them to work. > https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/realtek/rtase/rtase_main.c#L2195 > https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/ice/ice_main.c#L5266 > https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/igb/igb_main.c#L3221 This usage seems wrong to me: commit 50ac7479846053ca8054be833c1594e64de496bb Author: Anirudh Venkataramanan <[email protected]> Date: Wed Jul 28 12:39:10 2021 -0700 ice: Prevent probing virtual functions The userspace utility "driverctl" can be used to change/override the system's default driver choices. This is useful in some situations (buggy driver, old driver missing a device ID, trying a workaround, etc.) where the user needs to load a different driver. However, this is also prone to user error, where a driver is mapped to a device it's not designed to drive. For example, if the ice driver is mapped to driver iavf devices, the ice driver crashes. Add a check to return an error if the ice driver is being used to probe a virtual function. Decoding this.. There is actually an "iavf" driver, and it does have special PCI IDs for VFs: static const struct pci_device_id iavf_pci_tbl[] = { {PCI_VDEVICE(INTEL, IAVF_DEV_ID_VF), 0}, {PCI_VDEVICE(INTEL, IAVF_DEV_ID_VF_HV), 0}, {PCI_VDEVICE(INTEL, IAVF_DEV_ID_X722_VF), 0}, {PCI_VDEVICE(INTEL, IAVF_DEV_ID_ADAPTIVE_VF), 0}, In normal cases iavf will probe to the SRIOV VFS just fine. The above is saying if the user mis-uses driverctl to bind the ice driver to a function that doesn't have matching PCI IDs then the kernel crashes. Yeah. I'm pretty sure that is true for a lot of drivers. Bind them to HW not in their ID tables and their are not going to work right. I would have rejected a patch like this. The ID table is already correct and properly excludes VFs. Jason
