On Fri, Jan 24, 2020 at 1:01 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Fri, Jan 24, 2020 at 10:42:48PM +0800, Chen Yu wrote: > > It was found that on some platforms the bogus pci device might bring > > troubles to the system. For example, on a MacBookPro the system could > > not be power off or suspended due to internal pci resource confliction > > between bogus pci device and [io 0x1804]. Another case is that, once > > resumed from hibernation on a VM, the pci config space of a pci device > > is corrupt. > > > > To narrow down and benefit future debugging for such kind of issues, > > introduce the command line blacklist_dev=<vendor:device_id>> to blacklist > > such pci devices thus they will not be scanned thus not visible after > > bootup. For example, > > > > pci.blacklist_dev=8086:293e > > > > forbid the audio device to be exposed to the OS. > > I'm not really a fan of this. I'd rather see some details about what > the problem is so we can actually fix it. > > Ignoring the device doesn't mean the device is removed or even > inactive. It may still be consuming address space that we need to > avoid. > > Can you point us to bug reports about the issues you mentioned? I'm not sure which issues Chen Yu is referring to, but a proposal like has come up before [1], and didn't go anywhere. I think this is useful to people doing new / pre-release hardware bring up, but it's unlikely that such hardware makes it into a production to make this feature useful upstream. Hardware bring-up efforts can just use local hacks to workaround problems, if broken hardware actually makes it into production it needs precise quirks to be developed/applied. [1]: http://lore.kernel.org/r/1506544822-2632-2-git-send-email-jonathan.derrick@xxxxxxxxx
