Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1741663
| From | Jon Derrick <jonathan.derrick@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list |
| Date | 2017-09-28 18:00 +0200 |
| Message-ID | <uuJoe-2om-7@gated-at.bofh.it> (permalink) |
| References | <uurrj-7Vl-3@gated-at.bofh.it> <uurrk-7Vl-5@gated-at.bofh.it> <uuCZr-743-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Greg, On 09/28/2017 03:09 AM, Greg Kroah-Hartman wrote: > On Wed, Sep 27, 2017 at 04:40:20PM -0400, Jon Derrick wrote: >> This patch introduces a new kernel command line parameter to mask pci >> device ids from pci driver id tables. This prevents masked devices from >> automatically binding to both built-in and module drivers. >> >> Devices can be later attached through the driver's sysfs new_id >> inteface. >> >> The use cases for this are primarily for debugging, eg, being able to >> prevent attachment before probes are set up. It can also be used to mask >> off faulty built-in hardware or faulty simulated hardware. >> >> Another use case is to prevent attachment of devices which will be >> passed to VMs, shortcutting the detachment effort. > > Is the "shortcut" really that big of a deal? unbind actually causes > problems? Is this an attempt to deal with devices being handled by more > than one driver and then you want to manually bind it later on? > >> The format is similar to the sysfs new_id format. Device ids are >> specified with: >> >> VVVV:DDDD[:SVVV:SDDD][:CCCC][:MMMM] >> >> Where: >> VVVV = Vendor ID >> DDDD = Device ID >> SVVV = Subvendor ID >> SDDD = Subdevice ID >> CCCC = Class >> MMMM = Class Mask >> >> IDs can be chained with commas. >> >> Examples: >> <driver>.delete_id=1234:5678 >> <driver>.delete_id=ffffffff:ffffffff >> <driver>.delete_id=ffffffff:ffffffff:ffffffff:ffffffff:010802 >> <driver>.delete_id=1234:5678,abcd:ef01,2345:ffffffff > > What about drivers that handle more than one bus type (i.e. USB and > PCI?) This format is specific to PCI, yet you are defining it as a > "global" for all drivers :( > I was hoping to extend it to other bus types as well, but just wanted some early feedback on the idea. Pci was the easier implementation for me. Could prepending pci:, usb:, etc on the format be an option? > This feels hacky, what is the real reason for this? It feels like we > have so many different ways to blacklist and unbind and bind devices to > drivers already, why add yet-another way? > I ran into an issue a while back where I needed to disable a device from a built-in driver to perform a regression test. I worked around that issue by doing an initcall_blacklist on the pci-driver declaration, but that also preventing later binding because the driver was never registered. I've also had issues with remote systems where pluggable devices were broken or otherwise non-responsive, and it would have been nice to have been able to keep them from binding on module loading as a temporary workaround until someone could have removed those devices (though impossible on built-in hardware). I'm not sure about hacky; I think the implementation in this patch (1/3) is pretty clean :). I'm not familiar with all the different ways of blacklisting. Is there another way to work around the issues I listed above? I understand the concern about having it exist in the format <driver>. and only supporting one or a few bus types. I have another set that extends the pci= parameter instead. > thanks, > > greg k-h > Best, Jon
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC 0/3] Introduce PCI device blacklisting Jon Derrick <jonathan.derrick@intel.com> - 2017-09-27 22:50 +0200
[RFC 1/3] PCI: pci-driver: Introduce pci device delete list Jon Derrick <jonathan.derrick@intel.com> - 2017-09-27 22:50 +0200
Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-28 11:10 +0200
Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list Dan Williams <dan.j.williams@intel.com> - 2017-09-28 18:00 +0200
Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list Jon Derrick <jonathan.derrick@intel.com> - 2017-09-28 18:00 +0200
[RFC 2/3] module: Ignore delete_id parameter Jon Derrick <jonathan.derrick@intel.com> - 2017-09-27 22:50 +0200
Re: [RFC 2/3] module: Ignore delete_id parameter Dan Williams <dan.j.williams@intel.com> - 2017-09-28 08:10 +0200
Re: [RFC 2/3] module: Ignore delete_id parameter Jon Derrick <jonathan.derrick@intel.com> - 2017-09-28 18:00 +0200
Re: [RFC 2/3] module: Ignore delete_id parameter Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-28 11:10 +0200
Re: [RFC 2/3] module: Ignore delete_id parameter Jon Derrick <jonathan.derrick@intel.com> - 2017-09-28 18:00 +0200
csiph-web