On Tue, Jun 15, 2021 at 06:22:45PM -0600, Alex Williamson wrote: > On Tue, 15 Jun 2021 20:32:57 -0300 > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > On Tue, Jun 15, 2021 at 05:22:42PM -0600, Alex Williamson wrote: > > > > > > > b) alone is a functional, runtime difference. > > > > > > > > I would state b) differently: > > > > > > > > b) Ignore the driver-override-only match entries in the ID table. > > > > > > No, pci_match_device() returns NULL if a match is found that is marked > > > driver-override-only and a driver_override is not specified. That's > > > the same as no match at all. We don't then go on to search past that > > > match in the table, we fail to bind the driver. That's effectively an > > > anti-match when there's no driver_override on the device. > > > > anti-match isn't the intention. The deployment will have match tables > > where all entires are either flags=0 or are driver-override-only. > > I'd expect pci-pf-stub to have one of each, an any-id with > override-only flag and the one device ID currently in the table with > no flag. Oh Hum. Actually I think this shows the anti-match behavior is actually a bug.. :( For something like pci_pf_stub_whitelist, if we add a driver_override-only using the PCI any id then it effectively disables new_id completely because the match search will alway find the driver_override match first and stop searching. There is no chance to see things new_id adds. We have to fix this patch so flags isn't an anti-match to make it work without user regression. Jason
