[{"id":1776897,"web_url":"http://patchwork.ozlabs.org/comment/1776897/","msgid":"<20170928090901.GC12599@kroah.com>","list_archive_url":null,"date":"2017-09-28T09:09:01","subject":"Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list","submitter":{"id":11800,"url":"http://patchwork.ozlabs.org/api/people/11800/","name":"Greg Kroah-Hartman","email":"gregkh@linuxfoundation.org"},"content":"On Wed, Sep 27, 2017 at 04:40:20PM -0400, Jon Derrick wrote:\n> This patch introduces a new kernel command line parameter to mask pci\n> device ids from pci driver id tables. This prevents masked devices from\n> automatically binding to both built-in and module drivers.\n> \n> Devices can be later attached through the driver's sysfs new_id\n> inteface.\n> \n> The use cases for this are primarily for debugging, eg, being able to\n> prevent attachment before probes are set up. It can also be used to mask\n> off faulty built-in hardware or faulty simulated hardware.\n> \n> Another use case is to prevent attachment of devices which will be\n> passed to VMs, shortcutting the detachment effort.\n\nIs the \"shortcut\" really that big of a deal? unbind actually causes\nproblems? Is this an attempt to deal with devices being handled by more\nthan one driver and then you want to manually bind it later on?\n\n> The format is similar to the sysfs new_id format. Device ids are\n> specified with:\n> \n> VVVV:DDDD[:SVVV:SDDD][:CCCC][:MMMM]\n> \n> Where:\n> VVVV = Vendor ID\n> DDDD = Device ID\n> SVVV = Subvendor ID\n> SDDD = Subdevice ID\n> CCCC = Class\n> MMMM = Class Mask\n> \n> IDs can be chained with commas.\n> \n> Examples:\n> \t.delete_id=1234:5678\n> \t.delete_id=ffffffff:ffffffff\n> \t.delete_id=ffffffff:ffffffff:ffffffff:ffffffff:010802\n> \t.delete_id=1234:5678,abcd:ef01,2345:ffffffff\n\nWhat about drivers that handle more than one bus type (i.e. USB and\nPCI?) This format is specific to PCI, yet you are defining it as a\n\"global\" for all drivers :(\n\nThis feels hacky, what is the real reason for this? It feels like we\nhave so many different ways to blacklist and unbind and bind devices to\ndrivers already, why add yet-another way?\n\nthanks,\n\ngreg k-h","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2plw2dfjz9t30\n\tfor ;\n\tThu, 28 Sep 2017 19:09:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752387AbdI1JJG (ORCPT );\n\tThu, 28 Sep 2017 05:09:06 -0400","from mail.linuxfoundation.org ([140.211.169.12]:57086 \"EHLO\n\tmail.linuxfoundation.org\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752217AbdI1JJE (ORCPT\n\t); Thu, 28 Sep 2017 05:09:04 -0400","from localhost (unknown [195.81.232.10])\n\tby mail.linuxfoundation.org (Postfix) with ESMTPSA id 6F1E6727;\n\tThu, 28 Sep 2017 09:09:03 +0000 (UTC)"],"Date":"Thu, 28 Sep 2017 11:09:01 +0200","From":"Greg Kroah-Hartman ","To":"Jon Derrick ","Cc":"Bjorn Helgaas , linux-pci@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, Arjan van de Ven ,\n\tAlan Cox ,\n\tDan J Williams ","Subject":"Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list","Message-ID":"<20170928090901.GC12599@kroah.com>","References":"<1506544822-2632-1-git-send-email-jonathan.derrick@intel.com>\n\t<1506544822-2632-2-git-send-email-jonathan.derrick@intel.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1506544822-2632-2-git-send-email-jonathan.derrick@intel.com>","User-Agent":"Mutt/1.9.1 (2017-09-22)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1777125,"web_url":"http://patchwork.ozlabs.org/comment/1777125/","msgid":"","list_archive_url":null,"date":"2017-09-28T15:53:18","subject":"Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list","submitter":{"id":68102,"url":"http://patchwork.ozlabs.org/api/people/68102/","name":"Jon Derrick","email":"jonathan.derrick@intel.com"},"content":"Hi Greg,\n\nOn 09/28/2017 03:09 AM, Greg Kroah-Hartman wrote:\n> On Wed, Sep 27, 2017 at 04:40:20PM -0400, Jon Derrick wrote:\n>> This patch introduces a new kernel command line parameter to mask pci\n>> device ids from pci driver id tables. This prevents masked devices from\n>> automatically binding to both built-in and module drivers.\n>>\n>> Devices can be later attached through the driver's sysfs new_id\n>> inteface.\n>>\n>> The use cases for this are primarily for debugging, eg, being able to\n>> prevent attachment before probes are set up. It can also be used to mask\n>> off faulty built-in hardware or faulty simulated hardware.\n>>\n>> Another use case is to prevent attachment of devices which will be\n>> passed to VMs, shortcutting the detachment effort.\n> \n> Is the \"shortcut\" really that big of a deal? unbind actually causes\n> problems? Is this an attempt to deal with devices being handled by more\n> than one driver and then you want to manually bind it later on?\n> \n>> The format is similar to the sysfs new_id format. Device ids are\n>> specified with:\n>>\n>> VVVV:DDDD[:SVVV:SDDD][:CCCC][:MMMM]\n>>\n>> Where:\n>> VVVV = Vendor ID\n>> DDDD = Device ID\n>> SVVV = Subvendor ID\n>> SDDD = Subdevice ID\n>> CCCC = Class\n>> MMMM = Class Mask\n>>\n>> IDs can be chained with commas.\n>>\n>> Examples:\n>> \t.delete_id=1234:5678\n>> \t.delete_id=ffffffff:ffffffff\n>> \t.delete_id=ffffffff:ffffffff:ffffffff:ffffffff:010802\n>> \t.delete_id=1234:5678,abcd:ef01,2345:ffffffff\n> \n> What about drivers that handle more than one bus type (i.e. USB and\n> PCI?) This format is specific to PCI, yet you are defining it as a\n> \"global\" for all drivers :(\n> \nI was hoping to extend it to other bus types as well, but just wanted\nsome early feedback on the idea. Pci was the easier implementation for\nme. Could prepending pci:, usb:, etc on the format be an option?\n\n> This feels hacky, what is the real reason for this? It feels like we\n> have so many different ways to blacklist and unbind and bind devices to\n> drivers already, why add yet-another way?\n> \nI ran into an issue a while back where I needed to disable a device from\na built-in driver to perform a regression test. I worked around that\nissue by doing an initcall_blacklist on the pci-driver declaration, but\nthat also preventing later binding because the driver was never registered.\n\nI've also had issues with remote systems where pluggable devices were\nbroken or otherwise non-responsive, and it would have been nice to have\nbeen able to keep them from binding on module loading as a temporary\nworkaround until someone could have removed those devices (though\nimpossible on built-in hardware).\n\nI'm not sure about hacky; I think the implementation in this patch (1/3)\nis pretty clean :). I'm not familiar with all the different ways of\nblacklisting. Is there another way to work around the issues I listed above?\n\nI understand the concern about having it exist in the format .\nand only supporting one or a few bus types. I have another set that\nextends the pci= parameter instead.\n\n> thanks,\n> \n> greg k-h\n> \n\nBest,\nJon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2zkC2654z9sDB\n\tfor ;\n\tFri, 29 Sep 2017 01:53:23 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751649AbdI1PxV (ORCPT );\n\tThu, 28 Sep 2017 11:53:21 -0400","from mga03.intel.com ([134.134.136.65]:47361 \"EHLO mga03.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751360AbdI1PxU (ORCPT );\n\tThu, 28 Sep 2017 11:53:20 -0400","from orsmga002.jf.intel.com ([10.7.209.21])\n\tby orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t28 Sep 2017 08:53:20 -0700","from jderrick-mobl1.amr.corp.intel.com (HELO\n\tlocalhost.localdomain) ([10.232.112.166])\n\tby orsmga002.jf.intel.com with ESMTP; 28 Sep 2017 08:53:18 -0700"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,450,1500966000\"; d=\"scan'208\";a=\"140544450\"","Subject":"Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list","To":"Greg Kroah-Hartman ","Cc":"Bjorn Helgaas , linux-pci@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, Arjan van de Ven ,\n\tAlan Cox ,\n\tDan J Williams ","References":"<1506544822-2632-1-git-send-email-jonathan.derrick@intel.com>\n\t<1506544822-2632-2-git-send-email-jonathan.derrick@intel.com>\n\t<20170928090901.GC12599@kroah.com>","From":"Jon Derrick ","Message-ID":"","Date":"Thu, 28 Sep 2017 09:53:18 -0600","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170928090901.GC12599@kroah.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1777130,"web_url":"http://patchwork.ozlabs.org/comment/1777130/","msgid":"","list_archive_url":null,"date":"2017-09-28T15:58:29","subject":"Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list","submitter":{"id":347,"url":"http://patchwork.ozlabs.org/api/people/347/","name":"Dan Williams","email":"dan.j.williams@intel.com"},"content":"On Thu, Sep 28, 2017 at 2:09 AM, Greg Kroah-Hartman\n wrote:\n> On Wed, Sep 27, 2017 at 04:40:20PM -0400, Jon Derrick wrote:\n>> This patch introduces a new kernel command line parameter to mask pci\n>> device ids from pci driver id tables. This prevents masked devices from\n>> automatically binding to both built-in and module drivers.\n>>\n>> Devices can be later attached through the driver's sysfs new_id\n>> inteface.\n>>\n>> The use cases for this are primarily for debugging, eg, being able to\n>> prevent attachment before probes are set up. It can also be used to mask\n>> off faulty built-in hardware or faulty simulated hardware.\n>>\n>> Another use case is to prevent attachment of devices which will be\n>> passed to VMs, shortcutting the detachment effort.\n>\n> Is the \"shortcut\" really that big of a deal? unbind actually causes\n> problems? Is this an attempt to deal with devices being handled by more\n> than one driver and then you want to manually bind it later on?\n>\n>> The format is similar to the sysfs new_id format. Device ids are\n>> specified with:\n>>\n>> VVVV:DDDD[:SVVV:SDDD][:CCCC][:MMMM]\n>>\n>> Where:\n>> VVVV = Vendor ID\n>> DDDD = Device ID\n>> SVVV = Subvendor ID\n>> SDDD = Subdevice ID\n>> CCCC = Class\n>> MMMM = Class Mask\n>>\n>> IDs can be chained with commas.\n>>\n>> Examples:\n>> .delete_id=1234:5678\n>> .delete_id=ffffffff:ffffffff\n>> .delete_id=ffffffff:ffffffff:ffffffff:ffffffff:010802\n>> .delete_id=1234:5678,abcd:ef01,2345:ffffffff\n>\n> What about drivers that handle more than one bus type (i.e. USB and\n> PCI?) This format is specific to PCI, yet you are defining it as a\n> \"global\" for all drivers :(\n\nI assume other buses could define their own \"delete_id\" format and\nit's up to those bus_type implementations to check for \"delete_id\"\nstatements for the drivers attached to it. Somewhat similar to what we\nhave for \"new_id\" where it appears to be global sysfs attribute, but\nimplemented per-bus.\n\n> This feels hacky, what is the real reason for this? It feels like we\n> have so many different ways to blacklist and unbind and bind devices to\n> drivers already, why add yet-another way?\n\nUnbind after the fact may be too late, and builtin-drivers eliminate\nmodprobe blacklisting. I've missed having this functionality in the\npast for platform bring up.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=intel-com.20150623.gappssmtp.com\n\theader.i=@intel-com.20150623.gappssmtp.com\n\theader.b=\"0VElMpc6\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y2zr84nRBz9t3h\n\tfor ;\n\tFri, 29 Sep 2017 01:58:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751484AbdI1P6a (ORCPT );\n\tThu, 28 Sep 2017 11:58:30 -0400","from mail-oi0-f41.google.com ([209.85.218.41]:46921 \"EHLO\n\tmail-oi0-f41.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751436AbdI1P6a (ORCPT\n\t); Thu, 28 Sep 2017 11:58:30 -0400","by mail-oi0-f41.google.com with SMTP id a74so3015741oib.3\n\tfor ; Thu, 28 Sep 2017 08:58:29 -0700 (PDT)","by 10.157.12.212 with HTTP; Thu, 28 Sep 2017 08:58:29 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=intel-com.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=8MYVoKGS/AXQb6X27ywvm46E3ztjQXm8Q4EEdb8cbBE=;\n\tb=0VElMpc6g9R9EYS0cMtkST8Hoxi/pAaV/cWjOMZPCTjYuxjksIj52oHsyI5EM8CBH+\n\tkG3Azqs0sDbL08hEYcjUbDbcbb4EtQt1KGdYV+kRJ8APj5xWAY+0ks2KSVM5RSDhjZA+\n\tcmjjYyEYp2hLodSuMQz531dVwp1hO8Mn8MphdOxzGlF/LscOBPg/xzzUYcG9tFRWhn1o\n\tszRezFLnT5e3rICnx7KLouwQqBX/NIGBCYNQhXHWBwxKRAcOGSb5jPRFhkOwhH6n4w1H\n\tdL02FjYkyp/IQdApMK1WuylfWlR0GnIxWjoTLap/P6oiHVOpDAOjE4gsnqLB2rX2XHzY\n\tPr1A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=8MYVoKGS/AXQb6X27ywvm46E3ztjQXm8Q4EEdb8cbBE=;\n\tb=ean9Accgoxvx6s8wDu9Ou9L/+0hUBGEj42o0JEai2mBlAUp1X38KeZYK67YMaN8zsu\n\tgU85Xsm7AKfcpK0HSR2YrXLVOgE6Qqx1Fz3onNZdNrB43QZcdoQnHrhgx6TBwydOp/4t\n\t6gzTo59ETBhPsWFLcnaVfN0aBepTWvPOce7fvTQLrX5DKX2IgwKRYUz9kyIlux68qfNx\n\tQUHwDhYEMdVvEr4rX9lejQ6SO6fq1EIFBtulOA0HXGEMUFotJH3/KC0Sceq88e0m6zZz\n\tuoAOsfawROaU9iqLlcSjnRg5r4QkeTH3u56j8Hu/8Qc9KnN4rIp8EiO5zlGxYBuoMxhZ\n\t0svw==","X-Gm-Message-State":"AMCzsaVT4PWSxdjIhtmVraB4wQZlGYW+pQ4elssBxWRJ3c+D/LkL9ZQ2\n\tkIevH4V1lvoUI5cdbczYm1tLwM7vnfjTq91mAOq4Tg==","X-Google-Smtp-Source":"AOwi7QD2O3TEUb4ODi6xTiyHrBOiz8jaDY61Qmz6A+as+qShELCEptHvttiKk911WgaaODfbVCATiUlmuGBECVg2lik=","X-Received":"by 10.157.14.52 with SMTP id c49mr1195746otc.444.1506614309462; \n\tThu, 28 Sep 2017 08:58:29 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170928090901.GC12599@kroah.com>","References":"<1506544822-2632-1-git-send-email-jonathan.derrick@intel.com>\n\t<1506544822-2632-2-git-send-email-jonathan.derrick@intel.com>\n\t<20170928090901.GC12599@kroah.com>","From":"Dan Williams ","Date":"Thu, 28 Sep 2017 08:58:29 -0700","Message-ID":"","Subject":"Re: [RFC 1/3] PCI: pci-driver: Introduce pci device delete list","To":"Greg Kroah-Hartman ","Cc":"Jon Derrick ,\n\tBjorn Helgaas , linux-pci@vger.kernel.org,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tArjan van de Ven , Alan Cox ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}}]