[lkml]   [2017]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list
On Thu, Sep 28, 2017 at 2: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:
>> 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 assume other buses could define their own "delete_id" format and
it's up to those bus_type implementations to check for "delete_id"
statements for the drivers attached to it. Somewhat similar to what we
have for "new_id" where it appears to be global sysfs attribute, but
implemented per-bus.

> 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?

Unbind after the fact may be too late, and builtin-drivers eliminate
modprobe blacklisting. I've missed having this functionality in the
past for platform bring up.

 \ /
  Last update: 2017-09-28 17:59    [W:0.064 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site