[{"id":1774928,"web_url":"http://patchwork.ozlabs.org/comment/1774928/","msgid":"<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-09-25T18:55:23","subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"Hi Filippo,\n\nOn Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote:\n> +static ssize_t sriov_vf_did_show(struct device *dev,\n> +\t\t\t\t struct device_attribute *attr,\n> +\t\t\t\t char *buf)\n> +{\n> +\tstruct pci_dev *pdev = to_pci_dev(dev);\n> +\n> +\treturn sprintf(buf, \"%x\\n\", pdev->sriov->vf_did);\n> +}\n\nWhat does the vf_did part look like in sysfs?  Do we have a directory with\nboth \"device\" and \"vf_did\" in it?  If so, why do we have both and do we\nneed both?  Could we put the vf_did in the \"device\" file?\n\n>  static ssize_t sriov_drivers_autoprobe_show(struct device *dev,\n>  \t\t\t\t\t    struct device_attribute *attr,\n>  \t\t\t\t\t    char *buf)\n> @@ -676,6 +703,9 @@ static struct device_attribute sriov_totalvfs_attr = __ATTR_RO(sriov_totalvfs);\n>  static struct device_attribute sriov_numvfs_attr =\n>  \t\t__ATTR(sriov_numvfs, (S_IRUGO|S_IWUSR|S_IWGRP),\n>  \t\t       sriov_numvfs_show, sriov_numvfs_store);\n> +static struct device_attribute sriov_offset_attr = __ATTR_RO(sriov_offset);\n> +static struct device_attribute sriov_stride_attr = __ATTR_RO(sriov_stride);\n> +static struct device_attribute sriov_vf_did_attr = __ATTR_RO(sriov_vf_did);\n>  static struct device_attribute sriov_drivers_autoprobe_attr =\n>  \t\t__ATTR(sriov_drivers_autoprobe, (S_IRUGO|S_IWUSR|S_IWGRP),\n>  \t\t       sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);\n> @@ -1744,6 +1774,9 @@ static struct attribute_group pci_dev_hp_attr_group = {\n>  static struct attribute *sriov_dev_attrs[] = {\n>  \t&sriov_totalvfs_attr.attr,\n>  \t&sriov_numvfs_attr.attr,\n> +\t&sriov_offset_attr.attr,\n> +\t&sriov_stride_attr.attr,\n> +\t&sriov_vf_did_attr.attr,\n>  \t&sriov_drivers_autoprobe_attr.attr,\n>  \tNULL,\n>  };\n> -- \n> 2.7.4\n>","headers":{"Return-Path":"<linux-pci-owner@vger.kernel.org>","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=<UNKNOWN>)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1Cvh6rDBz9sNr\n\tfor <incoming@patchwork.ozlabs.org>;\n\tTue, 26 Sep 2017 04:55:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S935062AbdIYSz0 (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tMon, 25 Sep 2017 14:55:26 -0400","from mail.kernel.org ([198.145.29.99]:34062 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S933306AbdIYSzZ (ORCPT <rfc822;linux-pci@vger.kernel.org>);\n\tMon, 25 Sep 2017 14:55:25 -0400","from localhost (unknown [64.22.249.253])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 9E65321894;\n\tMon, 25 Sep 2017 18:55:24 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 9E65321894","Date":"Mon, 25 Sep 2017 13:55:23 -0500","From":"Bjorn Helgaas <helgaas@kernel.org>","To":"Filippo Sironi <sironi@amazon.de>","Cc":"linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org","Subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Message-ID":"<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>","References":"<1503927530-26076-1-git-send-email-sironi@amazon.de>\n\t<1503927530-26076-2-git-send-email-sironi@amazon.de>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1503927530-26076-2-git-send-email-sironi@amazon.de>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-pci.vger.kernel.org>","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1777398,"web_url":"http://patchwork.ozlabs.org/comment/1777398/","msgid":"<922D0B9C-4900-4226-9FB3-1BF3EA103708@amazon.de>","list_archive_url":null,"date":"2017-09-29T07:53:31","subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","submitter":{"id":72242,"url":"http://patchwork.ozlabs.org/api/people/72242/","name":"Filippo Sironi","email":"sironi@amazon.de"},"content":"Hi Bjorn,\n\n> On 25. Sep 2017, at 20:55, Bjorn Helgaas <helgaas@kernel.org> wrote:\n> \n> Hi Filippo,\n> \n> On Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote:\n>> +static ssize_t sriov_vf_did_show(struct device *dev,\n>> +\t\t\t\t struct device_attribute *attr,\n>> +\t\t\t\t char *buf)\n>> +{\n>> +\tstruct pci_dev *pdev = to_pci_dev(dev);\n>> +\n>> +\treturn sprintf(buf, \"%x\\n\", pdev->sriov->vf_did);\n>> +}\n> \n> What does the vf_did part look like in sysfs?  Do we have a directory with\n> both \"device\" and \"vf_did\" in it?  If so, why do we have both and do we\n> need both?  Could we put the vf_did in the \"device\" file?\n\nOn my machine:\n\n/sys/bus/pci/devices/0000:03:00.0# ls -l  # this is the PF\ntotal 0\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 broken_parity_status\n-r--r--r-- 1 root root    4096 Sep 28 19:41 class\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 config\n-r--r--r-- 1 root root    4096 Sep 28 19:41 consistent_dma_mask_bits\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 d3cold_allowed\n-r--r--r-- 1 root root    4096 Sep 28 19:41 device\n-r--r--r-- 1 root root    4096 Sep 28 19:41 dma_mask_bits\nlrwxrwxrwx 1 root root       0 Sep 28 19:41 driver -> ../../../../bus/pci/drivers/igb\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 driver_override\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 enable\nlrwxrwxrwx 1 root root       0 Sep 28 19:41 firmware_node -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/device:4c\n-r--r--r-- 1 root root    4096 Sep 28 19:41 irq\n-r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpulist\n-r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpus\n-r--r--r-- 1 root root    4096 Sep 28 19:41 modalias\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 msi_bus\ndrwxr-xr-x 2 root root       0 Sep 29 09:44 msi_irqs\ndrwxr-xr-x 3 root root       0 Sep 28 19:41 net\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 numa_node\n-r--r--r-- 1 root root    4096 Sep 28 19:41 offset  # this is new\ndrwxr-xr-x 2 root root       0 Sep 28 19:41 power\ndrwxr-xr-x 3 root root       0 Sep 28 19:41 ptp\n--w--w---- 1 root root    4096 Sep 28 19:41 remove\n--w--w---- 1 root root    4096 Sep 28 19:41 rescan\n--w------- 1 root root    4096 Sep 28 19:41 reset\n-r--r--r-- 1 root root    4096 Sep 28 19:41 resource\n-rw------- 1 root root  131072 Sep 28 19:41 resource0\n-rw------- 1 root root 4194304 Sep 28 19:41 resource1\n-rw------- 1 root root      32 Sep 28 19:41 resource2\n-rw------- 1 root root   16384 Sep 28 19:41 resource3\n-r--r--r-- 1 root root    4096 Sep 28 19:41 revision\n-rw-rw-r-- 1 root root    4096 Sep 29 09:44 sriov_numvfs\n-r--r--r-- 1 root root    4096 Sep 28 19:41 sriov_totalvfs\n-r--r--r-- 1 root root    4096 Sep 28 19:41 stride  # this is new\nlrwxrwxrwx 1 root root       0 Sep 28 19:41 subsystem -> ../../../../bus/pci\n-r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_device\n-r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_vendor\n-rw-r--r-- 1 root root    4096 Sep 28 19:41 uevent\n-r--r--r-- 1 root root    4096 Sep 28 19:41 vendor\n-r--r--r-- 1 root root    4096 Sep 28 19:41 vf_did  # this is new\nlrwxrwxrwx 1 root root       0 Sep 29 09:44 virtfn0 -> ../0000:03:10.0\n\nnothing changes on for VFs.\nThen:\n\n/sys/bus/pci/devices/0000:03:00.0# cat device \n0x10c9\n\n/sys/bus/pci/devices/0000:03:00.0# cat vf_did\n0x10ca\n\nPutting the VF device ID in the PF device file would be a change of\nthat we expose to userspace.  Something might break.\n\nvf_did provides a easy way to retrieve the VF device ID without reading\nthe PF config (looking up the SR-IOV capability and reading it) or without\nenabling SR-IOV to read for example virtfn0/device.\n\nSimilar considerations (ease of access) apply to offset and stride.\n\n\n>> static ssize_t sriov_drivers_autoprobe_show(struct device *dev,\n>> \t\t\t\t\t    struct device_attribute *attr,\n>> \t\t\t\t\t    char *buf)\n>> @@ -676,6 +703,9 @@ static struct device_attribute sriov_totalvfs_attr = __ATTR_RO(sriov_totalvfs);\n>> static struct device_attribute sriov_numvfs_attr =\n>> \t\t__ATTR(sriov_numvfs, (S_IRUGO|S_IWUSR|S_IWGRP),\n>> \t\t       sriov_numvfs_show, sriov_numvfs_store);\n>> +static struct device_attribute sriov_offset_attr = __ATTR_RO(sriov_offset);\n>> +static struct device_attribute sriov_stride_attr = __ATTR_RO(sriov_stride);\n>> +static struct device_attribute sriov_vf_did_attr = __ATTR_RO(sriov_vf_did);\n>> static struct device_attribute sriov_drivers_autoprobe_attr =\n>> \t\t__ATTR(sriov_drivers_autoprobe, (S_IRUGO|S_IWUSR|S_IWGRP),\n>> \t\t       sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);\n>> @@ -1744,6 +1774,9 @@ static struct attribute_group pci_dev_hp_attr_group = {\n>> static struct attribute *sriov_dev_attrs[] = {\n>> \t&sriov_totalvfs_attr.attr,\n>> \t&sriov_numvfs_attr.attr,\n>> +\t&sriov_offset_attr.attr,\n>> +\t&sriov_stride_attr.attr,\n>> +\t&sriov_vf_did_attr.attr,\n>> \t&sriov_drivers_autoprobe_attr.attr,\n>> \tNULL,\n>> };\n>> -- \n>> 2.7.4\n>> \n> \n\nAmazon Development Center Germany GmbH\nBerlin - Dresden - Aachen\nmain office: Krausenstr. 38, 10117 Berlin\nGeschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger\nUst-ID: DE289237879\nEingetragen am Amtsgericht Charlottenburg HRB 149173 B","headers":{"Return-Path":"<linux-pci-owner@vger.kernel.org>","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=<UNKNOWN>)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=amazon.de header.i=@amazon.de\n\theader.b=\"lEYcHx7/\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y3P2J56Kyz9sPk\n\tfor <incoming@patchwork.ozlabs.org>;\n\tFri, 29 Sep 2017 17:53:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751315AbdI2Hxm (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tFri, 29 Sep 2017 03:53:42 -0400","from smtp-fw-6001.amazon.com ([52.95.48.154]:47985 \"EHLO\n\tsmtp-fw-6001.amazon.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751027AbdI2Hxl (ORCPT\n\t<rfc822; linux-pci@vger.kernel.org>); Fri, 29 Sep 2017 03:53:41 -0400","from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO\n\temail-inbound-relay-2b-859fe132.us-west-2.amazon.com) ([10.43.8.6])\n\tby smtp-border-fw-out-6001.iad6.amazon.com with\n\tESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2017 07:53:33 +0000","from EX13MTAUEA001.ant.amazon.com\n\t(pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198])\n\tby email-inbound-relay-2b-859fe132.us-west-2.amazon.com\n\t(8.14.7/8.14.7) with ESMTP id v8T7rUR4024948\n\t(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL);\n\tFri, 29 Sep 2017 07:53:32 GMT","from EX13D02EUC003.ant.amazon.com (10.43.164.10) by\n\tEX13MTAUEA001.ant.amazon.com (10.43.61.243) with Microsoft SMTP\n\tServer (TLS) id 15.0.1236.3; Fri, 29 Sep 2017 07:53:32 +0000","from EX13D02EUC001.ant.amazon.com (10.43.164.92) by\n\tEX13D02EUC003.ant.amazon.com (10.43.164.10) with Microsoft SMTP\n\tServer (TLS) id 15.0.1236.3; Fri, 29 Sep 2017 07:53:31 +0000","from EX13D02EUC001.ant.amazon.com ([10.43.164.92]) by\n\tEX13D02EUC001.ant.amazon.com ([10.43.164.92]) with mapi id\n\t15.00.1236.000; Fri, 29 Sep 2017 07:53:31 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;\n\tt=1506671621; x=1538207621;\n\th=from:to:cc:subject:date:message-id:references:\n\tin-reply-to:content-id:mime-version:\n\tcontent-transfer-encoding;\n\tbh=7G66mdalcdi2I01MqFg+yIZI//2KCQ/fmmN93HUuQqM=;\n\tb=lEYcHx7/d076NjOSk5jRPBG4W4gFOjh3YOZ4OWMqzIkDlZnGdLLOh8vg\n\tRov/DeAAEXu6orQLh9RvcwlwGP9E5F/tbzBXlAp8GWxIdHNRz93nv3sUp\n\tLFamtyWoxTWVC6Xs/GXOjUhXhvzW1abOVpHGUc37LXGFn+lq5OiGk2qvZ A=;","X-IronPort-AV":"E=Sophos;i=\"5.42,451,1500940800\"; d=\"scan'208\";a=\"311400787\"","From":"\"Sironi, Filippo\" <sironi@amazon.de>","To":"Bjorn Helgaas <helgaas@kernel.org>","CC":"\"linux-pci@vger.kernel.org\" <linux-pci@vger.kernel.org>,\n\t\"linux-kernel@vger.kernel.org\" <linux-kernel@vger.kernel.org>","Subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Thread-Topic":"[PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Thread-Index":"AQHTIAMI7hPeU/MVWEyGqeRDF3b/sKLGH6iAgAWQZ4A=","Date":"Fri, 29 Sep 2017 07:53:31 +0000","Message-ID":"<922D0B9C-4900-4226-9FB3-1BF3EA103708@amazon.de>","References":"<1503927530-26076-1-git-send-email-sironi@amazon.de>\n\t<1503927530-26076-2-git-send-email-sironi@amazon.de>\n\t<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>","In-Reply-To":"<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-ms-exchange-messagesentrepresentingtype":"1","x-ms-exchange-transport-fromentityheader":"Hosted","x-originating-ip":"[10.43.166.75]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-ID":"<5E1D95FF7D230C41A67B13759BD12C09@amazon.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-pci.vger.kernel.org>","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1779217,"web_url":"http://patchwork.ozlabs.org/comment/1779217/","msgid":"<20171003193114.GE25517@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-10-03T19:31:14","subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Fri, Sep 29, 2017 at 07:53:31AM +0000, Sironi, Filippo wrote:\n> \n> Hi Bjorn,\n> \n> > On 25. Sep 2017, at 20:55, Bjorn Helgaas <helgaas@kernel.org> wrote:\n> > \n> > Hi Filippo,\n> > \n> > On Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote:\n> >> +static ssize_t sriov_vf_did_show(struct device *dev,\n> >> +\t\t\t\t struct device_attribute *attr,\n> >> +\t\t\t\t char *buf)\n> >> +{\n> >> +\tstruct pci_dev *pdev = to_pci_dev(dev);\n> >> +\n> >> +\treturn sprintf(buf, \"%x\\n\", pdev->sriov->vf_did);\n> >> +}\n> > \n> > What does the vf_did part look like in sysfs?  Do we have a directory with\n> > both \"device\" and \"vf_did\" in it?  If so, why do we have both and do we\n> > need both?  Could we put the vf_did in the \"device\" file?\n> \n> On my machine:\n> \n> /sys/bus/pci/devices/0000:03:00.0# ls -l  # this is the PF\n> total 0\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 broken_parity_status\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 class\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 config\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 consistent_dma_mask_bits\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 d3cold_allowed\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 device\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 dma_mask_bits\n> lrwxrwxrwx 1 root root       0 Sep 28 19:41 driver -> ../../../../bus/pci/drivers/igb\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 driver_override\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 enable\n> lrwxrwxrwx 1 root root       0 Sep 28 19:41 firmware_node -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/device:4c\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 irq\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpulist\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpus\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 modalias\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 msi_bus\n> drwxr-xr-x 2 root root       0 Sep 29 09:44 msi_irqs\n> drwxr-xr-x 3 root root       0 Sep 28 19:41 net\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 numa_node\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 offset  # this is new\n> drwxr-xr-x 2 root root       0 Sep 28 19:41 power\n> drwxr-xr-x 3 root root       0 Sep 28 19:41 ptp\n> --w--w---- 1 root root    4096 Sep 28 19:41 remove\n> --w--w---- 1 root root    4096 Sep 28 19:41 rescan\n> --w------- 1 root root    4096 Sep 28 19:41 reset\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 resource\n> -rw------- 1 root root  131072 Sep 28 19:41 resource0\n> -rw------- 1 root root 4194304 Sep 28 19:41 resource1\n> -rw------- 1 root root      32 Sep 28 19:41 resource2\n> -rw------- 1 root root   16384 Sep 28 19:41 resource3\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 revision\n> -rw-rw-r-- 1 root root    4096 Sep 29 09:44 sriov_numvfs\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 sriov_totalvfs\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 stride  # this is new\n> lrwxrwxrwx 1 root root       0 Sep 28 19:41 subsystem -> ../../../../bus/pci\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_device\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_vendor\n> -rw-r--r-- 1 root root    4096 Sep 28 19:41 uevent\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 vendor\n> -r--r--r-- 1 root root    4096 Sep 28 19:41 vf_did  # this is new\n> lrwxrwxrwx 1 root root       0 Sep 29 09:44 virtfn0 -> ../0000:03:10.0\n> \n> nothing changes on for VFs.\n> Then:\n> \n> /sys/bus/pci/devices/0000:03:00.0# cat device \n> 0x10c9\n> \n> /sys/bus/pci/devices/0000:03:00.0# cat vf_did\n> 0x10ca\n> \n> Putting the VF device ID in the PF device file would be a change of\n> that we expose to userspace.  Something might break.\n\nOh, sorry, I misunderstood!  I was thinking that you were adding\n\"vf_did\" to the VF directory, not the PF directory.\n\nThen I guess my only issue is that \"vf_did\" doesn't match the pattern\nof other names.  I think \"virtfn_device\" would give more of a hint and\nwould match \"device\" and \"subsystem_device\".\n\nBjorn\n\n> vf_did provides a easy way to retrieve the VF device ID without reading\n> the PF config (looking up the SR-IOV capability and reading it) or without\n> enabling SR-IOV to read for example virtfn0/device.\n> \n> Similar considerations (ease of access) apply to offset and stride.\n> \n> \n> >> static ssize_t sriov_drivers_autoprobe_show(struct device *dev,\n> >> \t\t\t\t\t    struct device_attribute *attr,\n> >> \t\t\t\t\t    char *buf)\n> >> @@ -676,6 +703,9 @@ static struct device_attribute sriov_totalvfs_attr = __ATTR_RO(sriov_totalvfs);\n> >> static struct device_attribute sriov_numvfs_attr =\n> >> \t\t__ATTR(sriov_numvfs, (S_IRUGO|S_IWUSR|S_IWGRP),\n> >> \t\t       sriov_numvfs_show, sriov_numvfs_store);\n> >> +static struct device_attribute sriov_offset_attr = __ATTR_RO(sriov_offset);\n> >> +static struct device_attribute sriov_stride_attr = __ATTR_RO(sriov_stride);\n> >> +static struct device_attribute sriov_vf_did_attr = __ATTR_RO(sriov_vf_did);\n> >> static struct device_attribute sriov_drivers_autoprobe_attr =\n> >> \t\t__ATTR(sriov_drivers_autoprobe, (S_IRUGO|S_IWUSR|S_IWGRP),\n> >> \t\t       sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);\n> >> @@ -1744,6 +1774,9 @@ static struct attribute_group pci_dev_hp_attr_group = {\n> >> static struct attribute *sriov_dev_attrs[] = {\n> >> \t&sriov_totalvfs_attr.attr,\n> >> \t&sriov_numvfs_attr.attr,\n> >> +\t&sriov_offset_attr.attr,\n> >> +\t&sriov_stride_attr.attr,\n> >> +\t&sriov_vf_did_attr.attr,\n> >> \t&sriov_drivers_autoprobe_attr.attr,\n> >> \tNULL,\n> >> };\n> >> -- \n> >> 2.7.4\n> >> \n> > \n> \n> Amazon Development Center Germany GmbH\n> Berlin - Dresden - Aachen\n> main office: Krausenstr. 38, 10117 Berlin\n> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger\n> Ust-ID: DE289237879\n> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B\n>","headers":{"Return-Path":"<linux-pci-owner@vger.kernel.org>","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=<UNKNOWN>)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y68KP67qzz9t5C\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed,  4 Oct 2017 06:31:21 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751642AbdJCTbT (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 3 Oct 2017 15:31:19 -0400","from mail.kernel.org ([198.145.29.99]:33698 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751609AbdJCTbQ (ORCPT <rfc822;linux-pci@vger.kernel.org>);\n\tTue, 3 Oct 2017 15:31:16 -0400","from localhost (173-25-0-147.client.mchsi.com [173.25.0.147])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id E3F322188A;\n\tTue,  3 Oct 2017 19:31:15 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org E3F322188A","Date":"Tue, 3 Oct 2017 14:31:14 -0500","From":"Bjorn Helgaas <helgaas@kernel.org>","To":"\"Sironi, Filippo\" <sironi@amazon.de>","Cc":"\"linux-pci@vger.kernel.org\" <linux-pci@vger.kernel.org>,\n\t\"linux-kernel@vger.kernel.org\" <linux-kernel@vger.kernel.org>","Subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Message-ID":"<20171003193114.GE25517@bhelgaas-glaptop.roam.corp.google.com>","References":"<1503927530-26076-1-git-send-email-sironi@amazon.de>\n\t<1503927530-26076-2-git-send-email-sironi@amazon.de>\n\t<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>\n\t<922D0B9C-4900-4226-9FB3-1BF3EA103708@amazon.de>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<922D0B9C-4900-4226-9FB3-1BF3EA103708@amazon.de>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-pci.vger.kernel.org>","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1779225,"web_url":"http://patchwork.ozlabs.org/comment/1779225/","msgid":"<20171003194855.GG25517@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-10-03T19:48:56","subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Tue, Oct 03, 2017 at 02:31:14PM -0500, Bjorn Helgaas wrote:\n> On Fri, Sep 29, 2017 at 07:53:31AM +0000, Sironi, Filippo wrote:\n> > \n> > Hi Bjorn,\n> > \n> > > On 25. Sep 2017, at 20:55, Bjorn Helgaas <helgaas@kernel.org> wrote:\n> > > \n> > > Hi Filippo,\n> > > \n> > > On Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote:\n> > >> +static ssize_t sriov_vf_did_show(struct device *dev,\n> > >> +\t\t\t\t struct device_attribute *attr,\n> > >> +\t\t\t\t char *buf)\n> > >> +{\n> > >> +\tstruct pci_dev *pdev = to_pci_dev(dev);\n> > >> +\n> > >> +\treturn sprintf(buf, \"%x\\n\", pdev->sriov->vf_did);\n> > >> +}\n> > > \n> > > What does the vf_did part look like in sysfs?  Do we have a directory with\n> > > both \"device\" and \"vf_did\" in it?  If so, why do we have both and do we\n> > > need both?  Could we put the vf_did in the \"device\" file?\n> > \n> > On my machine:\n> > \n> > /sys/bus/pci/devices/0000:03:00.0# ls -l  # this is the PF\n> > total 0\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 broken_parity_status\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 class\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 config\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 consistent_dma_mask_bits\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 d3cold_allowed\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 device\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 dma_mask_bits\n> > lrwxrwxrwx 1 root root       0 Sep 28 19:41 driver -> ../../../../bus/pci/drivers/igb\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 driver_override\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 enable\n> > lrwxrwxrwx 1 root root       0 Sep 28 19:41 firmware_node -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/device:4c\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 irq\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpulist\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpus\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 modalias\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 msi_bus\n> > drwxr-xr-x 2 root root       0 Sep 29 09:44 msi_irqs\n> > drwxr-xr-x 3 root root       0 Sep 28 19:41 net\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 numa_node\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 offset  # this is new\n> > drwxr-xr-x 2 root root       0 Sep 28 19:41 power\n> > drwxr-xr-x 3 root root       0 Sep 28 19:41 ptp\n> > --w--w---- 1 root root    4096 Sep 28 19:41 remove\n> > --w--w---- 1 root root    4096 Sep 28 19:41 rescan\n> > --w------- 1 root root    4096 Sep 28 19:41 reset\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 resource\n> > -rw------- 1 root root  131072 Sep 28 19:41 resource0\n> > -rw------- 1 root root 4194304 Sep 28 19:41 resource1\n> > -rw------- 1 root root      32 Sep 28 19:41 resource2\n> > -rw------- 1 root root   16384 Sep 28 19:41 resource3\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 revision\n> > -rw-rw-r-- 1 root root    4096 Sep 29 09:44 sriov_numvfs\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 sriov_totalvfs\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 stride  # this is new\n> > lrwxrwxrwx 1 root root       0 Sep 28 19:41 subsystem -> ../../../../bus/pci\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_device\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_vendor\n> > -rw-r--r-- 1 root root    4096 Sep 28 19:41 uevent\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 vendor\n> > -r--r--r-- 1 root root    4096 Sep 28 19:41 vf_did  # this is new\n> > lrwxrwxrwx 1 root root       0 Sep 29 09:44 virtfn0 -> ../0000:03:10.0\n> > \n> > nothing changes on for VFs.\n> > Then:\n> > \n> > /sys/bus/pci/devices/0000:03:00.0# cat device \n> > 0x10c9\n> > \n> > /sys/bus/pci/devices/0000:03:00.0# cat vf_did\n> > 0x10ca\n> > \n> > Putting the VF device ID in the PF device file would be a change of\n> > that we expose to userspace.  Something might break.\n> \n> Oh, sorry, I misunderstood!  I was thinking that you were adding\n> \"vf_did\" to the VF directory, not the PF directory.\n> \n> Then I guess my only issue is that \"vf_did\" doesn't match the pattern\n> of other names.  I think \"virtfn_device\" would give more of a hint and\n> would match \"device\" and \"subsystem_device\".\n\nI was going to just make this tweak myself, but realized I'd actually\npropose these changes as well:\n\n  offset -> sriov_offset\n  stride -> sriov_stride\n  vf_did -> virtfn_device (could be sriov_device as well)\n\nand I can't really test it to make sure I get all the details right.\nCan you update those and repost this?\n\nBjorn\n\n> > vf_did provides a easy way to retrieve the VF device ID without reading\n> > the PF config (looking up the SR-IOV capability and reading it) or without\n> > enabling SR-IOV to read for example virtfn0/device.\n> > \n> > Similar considerations (ease of access) apply to offset and stride.\n> > \n> > \n> > >> static ssize_t sriov_drivers_autoprobe_show(struct device *dev,\n> > >> \t\t\t\t\t    struct device_attribute *attr,\n> > >> \t\t\t\t\t    char *buf)\n> > >> @@ -676,6 +703,9 @@ static struct device_attribute sriov_totalvfs_attr = __ATTR_RO(sriov_totalvfs);\n> > >> static struct device_attribute sriov_numvfs_attr =\n> > >> \t\t__ATTR(sriov_numvfs, (S_IRUGO|S_IWUSR|S_IWGRP),\n> > >> \t\t       sriov_numvfs_show, sriov_numvfs_store);\n> > >> +static struct device_attribute sriov_offset_attr = __ATTR_RO(sriov_offset);\n> > >> +static struct device_attribute sriov_stride_attr = __ATTR_RO(sriov_stride);\n> > >> +static struct device_attribute sriov_vf_did_attr = __ATTR_RO(sriov_vf_did);\n> > >> static struct device_attribute sriov_drivers_autoprobe_attr =\n> > >> \t\t__ATTR(sriov_drivers_autoprobe, (S_IRUGO|S_IWUSR|S_IWGRP),\n> > >> \t\t       sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);\n> > >> @@ -1744,6 +1774,9 @@ static struct attribute_group pci_dev_hp_attr_group = {\n> > >> static struct attribute *sriov_dev_attrs[] = {\n> > >> \t&sriov_totalvfs_attr.attr,\n> > >> \t&sriov_numvfs_attr.attr,\n> > >> +\t&sriov_offset_attr.attr,\n> > >> +\t&sriov_stride_attr.attr,\n> > >> +\t&sriov_vf_did_attr.attr,\n> > >> \t&sriov_drivers_autoprobe_attr.attr,\n> > >> \tNULL,\n> > >> };\n> > >> -- \n> > >> 2.7.4\n> > >> \n> > > \n> > \n> > Amazon Development Center Germany GmbH\n> > Berlin - Dresden - Aachen\n> > main office: Krausenstr. 38, 10117 Berlin\n> > Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger\n> > Ust-ID: DE289237879\n> > Eingetragen am Amtsgericht Charlottenburg HRB 149173 B\n> >","headers":{"Return-Path":"<linux-pci-owner@vger.kernel.org>","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=<UNKNOWN>)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y68kB31Tyz9s0Z\n\tfor <incoming@patchwork.ozlabs.org>;\n\tWed,  4 Oct 2017 06:49:22 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750961AbdJCTs7 (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tTue, 3 Oct 2017 15:48:59 -0400","from mail.kernel.org ([198.145.29.99]:34260 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751188AbdJCTs6 (ORCPT <rfc822;linux-pci@vger.kernel.org>);\n\tTue, 3 Oct 2017 15:48:58 -0400","from localhost (173-25-0-147.client.mchsi.com [173.25.0.147])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id A51BC2188D;\n\tTue,  3 Oct 2017 19:48:57 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org A51BC2188D","Date":"Tue, 3 Oct 2017 14:48:56 -0500","From":"Bjorn Helgaas <helgaas@kernel.org>","To":"\"Sironi, Filippo\" <sironi@amazon.de>","Cc":"\"linux-pci@vger.kernel.org\" <linux-pci@vger.kernel.org>,\n\t\"linux-kernel@vger.kernel.org\" <linux-kernel@vger.kernel.org>","Subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Message-ID":"<20171003194855.GG25517@bhelgaas-glaptop.roam.corp.google.com>","References":"<1503927530-26076-1-git-send-email-sironi@amazon.de>\n\t<1503927530-26076-2-git-send-email-sironi@amazon.de>\n\t<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>\n\t<922D0B9C-4900-4226-9FB3-1BF3EA103708@amazon.de>\n\t<20171003193114.GE25517@bhelgaas-glaptop.roam.corp.google.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20171003193114.GE25517@bhelgaas-glaptop.roam.corp.google.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-pci.vger.kernel.org>","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1780009,"web_url":"http://patchwork.ozlabs.org/comment/1780009/","msgid":"<38998983-95AF-468B-885B-F56D63E57E54@amazon.de>","list_archive_url":null,"date":"2017-10-04T17:32:20","subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","submitter":{"id":72242,"url":"http://patchwork.ozlabs.org/api/people/72242/","name":"Filippo Sironi","email":"sironi@amazon.de"},"content":"> On 3. Oct 2017, at 21:48, Bjorn Helgaas <helgaas@kernel.org> wrote:\n> \n> On Tue, Oct 03, 2017 at 02:31:14PM -0500, Bjorn Helgaas wrote:\n>> On Fri, Sep 29, 2017 at 07:53:31AM +0000, Sironi, Filippo wrote:\n>>> \n>>> Hi Bjorn,\n>>> \n>>>> On 25. Sep 2017, at 20:55, Bjorn Helgaas <helgaas@kernel.org> wrote:\n>>>> \n>>>> Hi Filippo,\n>>>> \n>>>> On Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote:\n>>>>> +static ssize_t sriov_vf_did_show(struct device *dev,\n>>>>> +\t\t\t\t struct device_attribute *attr,\n>>>>> +\t\t\t\t char *buf)\n>>>>> +{\n>>>>> +\tstruct pci_dev *pdev = to_pci_dev(dev);\n>>>>> +\n>>>>> +\treturn sprintf(buf, \"%x\\n\", pdev->sriov->vf_did);\n>>>>> +}\n>>>> \n>>>> What does the vf_did part look like in sysfs?  Do we have a directory with\n>>>> both \"device\" and \"vf_did\" in it?  If so, why do we have both and do we\n>>>> need both?  Could we put the vf_did in the \"device\" file?\n>>> \n>>> On my machine:\n>>> \n>>> /sys/bus/pci/devices/0000:03:00.0# ls -l  # this is the PF\n>>> total 0\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 broken_parity_status\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 class\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 config\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 consistent_dma_mask_bits\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 d3cold_allowed\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 device\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 dma_mask_bits\n>>> lrwxrwxrwx 1 root root       0 Sep 28 19:41 driver -> ../../../../bus/pci/drivers/igb\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 driver_override\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 enable\n>>> lrwxrwxrwx 1 root root       0 Sep 28 19:41 firmware_node -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4b/device:4c\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 irq\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpulist\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 local_cpus\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 modalias\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 msi_bus\n>>> drwxr-xr-x 2 root root       0 Sep 29 09:44 msi_irqs\n>>> drwxr-xr-x 3 root root       0 Sep 28 19:41 net\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 numa_node\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 offset  # this is new\n>>> drwxr-xr-x 2 root root       0 Sep 28 19:41 power\n>>> drwxr-xr-x 3 root root       0 Sep 28 19:41 ptp\n>>> --w--w---- 1 root root    4096 Sep 28 19:41 remove\n>>> --w--w---- 1 root root    4096 Sep 28 19:41 rescan\n>>> --w------- 1 root root    4096 Sep 28 19:41 reset\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 resource\n>>> -rw------- 1 root root  131072 Sep 28 19:41 resource0\n>>> -rw------- 1 root root 4194304 Sep 28 19:41 resource1\n>>> -rw------- 1 root root      32 Sep 28 19:41 resource2\n>>> -rw------- 1 root root   16384 Sep 28 19:41 resource3\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 revision\n>>> -rw-rw-r-- 1 root root    4096 Sep 29 09:44 sriov_numvfs\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 sriov_totalvfs\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 stride  # this is new\n>>> lrwxrwxrwx 1 root root       0 Sep 28 19:41 subsystem -> ../../../../bus/pci\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_device\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 subsystem_vendor\n>>> -rw-r--r-- 1 root root    4096 Sep 28 19:41 uevent\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 vendor\n>>> -r--r--r-- 1 root root    4096 Sep 28 19:41 vf_did  # this is new\n>>> lrwxrwxrwx 1 root root       0 Sep 29 09:44 virtfn0 -> ../0000:03:10.0\n>>> \n>>> nothing changes on for VFs.\n>>> Then:\n>>> \n>>> /sys/bus/pci/devices/0000:03:00.0# cat device \n>>> 0x10c9\n>>> \n>>> /sys/bus/pci/devices/0000:03:00.0# cat vf_did\n>>> 0x10ca\n>>> \n>>> Putting the VF device ID in the PF device file would be a change of\n>>> that we expose to userspace.  Something might break.\n>> \n>> Oh, sorry, I misunderstood!  I was thinking that you were adding\n>> \"vf_did\" to the VF directory, not the PF directory.\n>> \n>> Then I guess my only issue is that \"vf_did\" doesn't match the pattern\n>> of other names.  I think \"virtfn_device\" would give more of a hint and\n>> would match \"device\" and \"subsystem_device\".\n> \n> I was going to just make this tweak myself, but realized I'd actually\n> propose these changes as well:\n> \n>  offset -> sriov_offset\n>  stride -> sriov_stride\n>  vf_did -> virtfn_device (could be sriov_device as well)\n> \n> and I can't really test it to make sure I get all the details right.\n> Can you update those and repost this?\n> \n> Bjorn\n\nI'll give this a spin tomorrow.\n\nThanks,\nFilippo\n\n\n>>> vf_did provides a easy way to retrieve the VF device ID without reading\n>>> the PF config (looking up the SR-IOV capability and reading it) or without\n>>> enabling SR-IOV to read for example virtfn0/device.\n>>> \n>>> Similar considerations (ease of access) apply to offset and stride.\n>>> \n>>> \n>>>>> static ssize_t sriov_drivers_autoprobe_show(struct device *dev,\n>>>>> \t\t\t\t\t    struct device_attribute *attr,\n>>>>> \t\t\t\t\t    char *buf)\n>>>>> @@ -676,6 +703,9 @@ static struct device_attribute sriov_totalvfs_attr = __ATTR_RO(sriov_totalvfs);\n>>>>> static struct device_attribute sriov_numvfs_attr =\n>>>>> \t\t__ATTR(sriov_numvfs, (S_IRUGO|S_IWUSR|S_IWGRP),\n>>>>> \t\t       sriov_numvfs_show, sriov_numvfs_store);\n>>>>> +static struct device_attribute sriov_offset_attr = __ATTR_RO(sriov_offset);\n>>>>> +static struct device_attribute sriov_stride_attr = __ATTR_RO(sriov_stride);\n>>>>> +static struct device_attribute sriov_vf_did_attr = __ATTR_RO(sriov_vf_did);\n>>>>> static struct device_attribute sriov_drivers_autoprobe_attr =\n>>>>> \t\t__ATTR(sriov_drivers_autoprobe, (S_IRUGO|S_IWUSR|S_IWGRP),\n>>>>> \t\t       sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);\n>>>>> @@ -1744,6 +1774,9 @@ static struct attribute_group pci_dev_hp_attr_group = {\n>>>>> static struct attribute *sriov_dev_attrs[] = {\n>>>>> \t&sriov_totalvfs_attr.attr,\n>>>>> \t&sriov_numvfs_attr.attr,\n>>>>> +\t&sriov_offset_attr.attr,\n>>>>> +\t&sriov_stride_attr.attr,\n>>>>> +\t&sriov_vf_did_attr.attr,\n>>>>> \t&sriov_drivers_autoprobe_attr.attr,\n>>>>> \tNULL,\n>>>>> };\n>>>>> -- \n>>>>> 2.7.4\n>>>>> \n>>>> \n>>> \n>>> Amazon Development Center Germany GmbH\n>>> Berlin - Dresden - Aachen\n>>> main office: Krausenstr. 38, 10117 Berlin\n>>> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger\n>>> Ust-ID: DE289237879\n>>> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B\n\nAmazon Development Center Germany GmbH\nBerlin - Dresden - Aachen\nmain office: Krausenstr. 38, 10117 Berlin\nGeschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger\nUst-ID: DE289237879\nEingetragen am Amtsgericht Charlottenburg HRB 149173 B","headers":{"Return-Path":"<linux-pci-owner@vger.kernel.org>","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=<UNKNOWN>)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=amazon.de header.i=@amazon.de\n\theader.b=\"v8aPoKPP\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y6jf32zqxz9t44\n\tfor <incoming@patchwork.ozlabs.org>;\n\tThu,  5 Oct 2017 04:32:43 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751198AbdJDRcl (ORCPT <rfc822;incoming@patchwork.ozlabs.org>);\n\tWed, 4 Oct 2017 13:32:41 -0400","from smtp-fw-4101.amazon.com ([72.21.198.25]:41162 \"EHLO\n\tsmtp-fw-4101.amazon.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751197AbdJDRck (ORCPT\n\t<rfc822;linux-pci@vger.kernel.org>); Wed, 4 Oct 2017 13:32:40 -0400","from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO\n\temail-inbound-relay-1d-74cf8b49.us-east-1.amazon.com) ([10.43.8.6])\n\tby smtp-border-fw-out-4101.iad4.amazon.com with\n\tESMTP/TLS/DHE-RSA-AES256-SHA; 04 Oct 2017 17:32:23 +0000","from EX13MTAUEA001.ant.amazon.com\n\t(iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162])\n\tby email-inbound-relay-1d-74cf8b49.us-east-1.amazon.com\n\t(8.14.7/8.14.7) with ESMTP id v94HWEZG093669\n\t(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL);\n\tWed, 4 Oct 2017 17:32:22 GMT","from EX13D02EUC004.ant.amazon.com (10.43.164.117) by\n\tEX13MTAUEA001.ant.amazon.com (10.43.61.82) with Microsoft SMTP Server\n\t(TLS) id 15.0.1236.3; Wed, 4 Oct 2017 17:32:21 +0000","from EX13D02EUC001.ant.amazon.com (10.43.164.92) by\n\tEX13D02EUC004.ant.amazon.com (10.43.164.117) with Microsoft SMTP\n\tServer (TLS) id 15.0.1236.3; Wed, 4 Oct 2017 17:32:20 +0000","from EX13D02EUC001.ant.amazon.com ([10.43.164.92]) by\n\tEX13D02EUC001.ant.amazon.com ([10.43.164.92]) with mapi id\n\t15.00.1236.000; Wed, 4 Oct 2017 17:32:20 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209;\n\tt=1507138360; x=1538674360;\n\th=from:to:cc:subject:date:message-id:references:\n\tin-reply-to:content-id:mime-version:\n\tcontent-transfer-encoding;\n\tbh=kV/j25vZcpLFF3nyosOcUblLUnSpwxl/6UHWwR5yTSI=;\n\tb=v8aPoKPPBHrOE5Ywoq8RK7qsGxobNPYCsO3MhtM0PYPZ0Bb1ykPq4ZTl\n\tdL0VgNKnDyEDsgzZv8iaTZ7QJodaah8gpRKvVI5bOoJGP/gi7ek56cHLa\n\t9h2Ans/w0/Bz02GI0Mzy1loDXnIk56LtpqszuPhP7TRAuGRKritPcVwzn I=;","X-IronPort-AV":"E=Sophos;i=\"5.42,478,1500940800\"; d=\"scan'208\";a=\"686882781\"","From":"\"Sironi, Filippo\" <sironi@amazon.de>","To":"Bjorn Helgaas <helgaas@kernel.org>","CC":"\"linux-pci@vger.kernel.org\" <linux-pci@vger.kernel.org>,\n\t\"linux-kernel@vger.kernel.org\" <linux-kernel@vger.kernel.org>","Subject":"Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Thread-Topic":"[PATCH 2/2] pci: Expose offset, stride, and VF device ID via\n\tsysfs","Thread-Index":"AQHTIAMI7hPeU/MVWEyGqeRDF3b/sKLGH6iAgAWQZ4CABwxEAIAABPIAgAFsKYA=","Date":"Wed, 4 Oct 2017 17:32:20 +0000","Message-ID":"<38998983-95AF-468B-885B-F56D63E57E54@amazon.de>","References":"<1503927530-26076-1-git-send-email-sironi@amazon.de>\n\t<1503927530-26076-2-git-send-email-sironi@amazon.de>\n\t<20170925185523.GF15970@bhelgaas-glaptop.roam.corp.google.com>\n\t<922D0B9C-4900-4226-9FB3-1BF3EA103708@amazon.de>\n\t<20171003193114.GE25517@bhelgaas-glaptop.roam.corp.google.com>\n\t<20171003194855.GG25517@bhelgaas-glaptop.roam.corp.google.com>","In-Reply-To":"<20171003194855.GG25517@bhelgaas-glaptop.roam.corp.google.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-ms-exchange-messagesentrepresentingtype":"1","x-ms-exchange-transport-fromentityheader":"Hosted","x-originating-ip":"[10.43.164.85]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-ID":"<0CDF5CCEEA0CFA4BAFD62A558D59B813@amazon.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<linux-pci.vger.kernel.org>","X-Mailing-List":"linux-pci@vger.kernel.org"}}]