[{"id":3675797,"web_url":"http://patchwork.ozlabs.org/comment/3675797/","msgid":"<4fc23ce0-7103-545b-bc11-230b52c2de94@linux.intel.com>","date":"2026-04-10T10:49:54","subject":"Re: [PATCH 06/20] PCI/sysfs: Convert PCI resource files to static\n attributes","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Fri, 10 Apr 2026, Krzysztof Wilczyński wrote:\n\n> Currently, the PCI resource files (resourceN, resourceN_wc) are\n> dynamically created by pci_create_sysfs_dev_files(), called from\n> both pci_bus_add_device() and the pci_sysfs_init() late_initcall,\n> with only a sysfs_initialized flag for synchronisation.  This has\n> caused \"duplicate filename\" warnings and boot panics when both\n> paths race on the same device.\n> \n> This is especially likely on Devicetree-based platforms, where the\n> PCI host controllers are platform drivers that probe via the driver\n> model, which can happen during or after the late_initcall.  As such,\n> pci_bus_add_device() and pci_sysfs_init() are more likely to overlap.\n> \n> Thus, convert to static const attributes with three attribute groups\n> (I/O, UC, WC), each with an .is_bin_visible callback that checks\n> resource flags, BAR length, and non_mappable_bars.  A .bin_size\n> callback provides pci_resource_len() to the kernfs node for correct\n> stat and lseek behaviour.\n> \n> As part of this conversion:\n> \n>   - Rename pci_read_resource_io() and pci_write_resource_io() to\n>     pci_read_resource() and pci_write_resource() since the callbacks\n>     are no longer I/O-specific in the static attribute context.\n> \n>   - Remove pci_create_resource_files(), pci_remove_resource_files(),\n>     and pci_create_attr() which are no longer needed.\n> \n>   - Move the __weak stubs outside the #if guard so they remain\n>     available for callers converted in subsequent commits.\n> \n> Platforms that do not define the HAVE_PCI_MMAP macro or the\n> ARCH_GENERIC_PCI_MMAP_RESOURCE macro, such as Alpha architecture,\n> continue using their platform-specific resource file creation.\n> \n> For reference, the dynamic creation dates back to the pre-Git era:\n> \n>   https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/drivers/pci/pci-sysfs.c?id=42298be0eeb5ae98453b3374c36161b05a46c5dc\n> \n> The write-combine support was added in commit 45aec1ae72fc (\"x86: PAT\n> export resource_wc in pci sysfs\").\n> \n> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>\n> ---\n>  drivers/pci/pci-sysfs.c | 242 +++++++++++++++++++++-------------------\n>  include/linux/pci.h     |   2 -\n>  2 files changed, 127 insertions(+), 117 deletions(-)\n> \n> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c\n> index d29d79be8ee5..e56fddbe7914 100644\n> --- a/drivers/pci/pci-sysfs.c\n> +++ b/drivers/pci/pci-sysfs.c\n> @@ -1200,14 +1200,14 @@ static ssize_t pci_resource_io(struct file *filp, struct kobject *kobj,\n>  #endif\n>  }\n>  \n> -static ssize_t pci_read_resource_io(struct file *filp, struct kobject *kobj,\n> +static ssize_t pci_read_resource(struct file *filp, struct kobject *kobj,\n>  \t\t\t\t    const struct bin_attribute *attr, char *buf,\n>  \t\t\t\t    loff_t off, size_t count)\n>  {\n>  \treturn pci_resource_io(filp, kobj, attr, buf, off, count, false);\n>  }\n>  \n> -static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,\n> +static ssize_t pci_write_resource(struct file *filp, struct kobject *kobj,\n>  \t\t\t\t     const struct bin_attribute *attr, char *buf,\n>  \t\t\t\t     loff_t off, size_t count)\n>  {\n> @@ -1261,129 +1261,136 @@ static const struct bin_attribute dev_resource##_bar##_wc_attr = {\t\t\\\n>  \t.mmap = pci_mmap_resource_wc,\t\t\t\t\t\t\\\n>  }\n>  \n> -/**\n> - * pci_remove_resource_files - cleanup resource files\n> - * @pdev: dev to cleanup\n> - *\n> - * If we created resource files for @pdev, remove them from sysfs and\n> - * free their resources.\n> - */\n> -static void pci_remove_resource_files(struct pci_dev *pdev)\n> +static inline umode_t\n> +__pci_resource_attr_is_visible(struct kobject *kobj,\n> +\t\t\t       const struct bin_attribute *a,\n> +\t\t\t       int bar, bool write_combine,\n> +\t\t\t       unsigned long flags)\n>  {\n> -\tint i;\n> +\tstruct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));\n>  \n> -\tfor (i = 0; i < PCI_STD_NUM_BARS; i++) {\n> -\t\tstruct bin_attribute *res_attr;\n> -\n> -\t\tres_attr = pdev->res_attr[i];\n> -\t\tif (res_attr) {\n> -\t\t\tsysfs_remove_bin_file(&pdev->dev.kobj, res_attr);\n> -\t\t\tkfree(res_attr);\n> -\t\t}\n> -\n> -\t\tres_attr = pdev->res_attr_wc[i];\n> -\t\tif (res_attr) {\n> -\t\t\tsysfs_remove_bin_file(&pdev->dev.kobj, res_attr);\n> -\t\t\tkfree(res_attr);\n> -\t\t}\n> -\t}\n> -}\n> -\n> -static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine)\n> -{\n> -\t/* allocate attribute structure, piggyback attribute name */\n> -\tint name_len = write_combine ? 13 : 10;\n> -\tstruct bin_attribute *res_attr;\n> -\tchar *res_attr_name;\n> -\tint retval;\n> -\n> -\tres_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC);\n> -\tif (!res_attr)\n> -\t\treturn -ENOMEM;\n> -\n> -\tres_attr_name = (char *)(res_attr + 1);\n> -\n> -\tsysfs_bin_attr_init(res_attr);\n> -\tif (write_combine) {\n> -\t\tsprintf(res_attr_name, \"resource%d_wc\", num);\n> -\t\tres_attr->mmap = pci_mmap_resource_wc;\n> -\t} else {\n> -\t\tsprintf(res_attr_name, \"resource%d\", num);\n> -\t\tif (pci_resource_flags(pdev, num) & IORESOURCE_IO) {\n> -\t\t\tres_attr->read = pci_read_resource_io;\n> -\t\t\tres_attr->write = pci_write_resource_io;\n> -\t\t\tif (arch_can_pci_mmap_io())\n> -\t\t\t\tres_attr->mmap = pci_mmap_resource_uc;\n> -\t\t} else {\n> -\t\t\tres_attr->mmap = pci_mmap_resource_uc;\n> -\t\t}\n> -\t}\n> -\tif (res_attr->mmap) {\n> -\t\tres_attr->f_mapping = iomem_get_mapping;\n> -\t\t/*\n> -\t\t * generic_file_llseek() consults f_mapping->host to determine\n> -\t\t * the file size. As iomem_inode knows nothing about the\n> -\t\t * attribute, it's not going to work, so override it as well.\n> -\t\t */\n> -\t\tres_attr->llseek = pci_llseek_resource;\n> -\t}\n> -\tres_attr->attr.name = res_attr_name;\n> -\tres_attr->attr.mode = 0600;\n> -\tres_attr->size = pci_resource_len(pdev, num);\n> -\tres_attr->private = (void *)(unsigned long)num;\n> -\tretval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);\n> -\tif (retval) {\n> -\t\tkfree(res_attr);\n> -\t\treturn retval;\n> -\t}\n> -\n> -\tif (write_combine)\n> -\t\tpdev->res_attr_wc[num] = res_attr;\n> -\telse\n> -\t\tpdev->res_attr[num] = res_attr;\n> -\n> -\treturn 0;\n> -}\n> -\n> -/**\n> - * pci_create_resource_files - create resource files in sysfs for @dev\n> - * @pdev: dev in question\n> - *\n> - * Walk the resources in @pdev creating files for each resource available.\n> - */\n> -static int pci_create_resource_files(struct pci_dev *pdev)\n> -{\n> -\tint i;\n> -\tint retval;\n> -\n> -\t/* Skip devices with non-mappable BARs */\n>  \tif (pdev->non_mappable_bars)\n>  \t\treturn 0;\n>  \n> -\t/* Expose the PCI resources from this device as files */\n> -\tfor (i = 0; i < PCI_STD_NUM_BARS; i++) {\n> +\tif (!pci_resource_len(pdev, bar))\n> +\t\treturn 0;\n\nI know it's same as in the previous code but I dislike assuming len != 0 \nimplies resource has been assigned. While it currently holds, I'd want to \nchange that eventually.\n\nThe current behavior causes issue e.g. if IOV resource fails to assign, it \nis reset (making its len 0 among other thing) and since IOV resource are \noptional that is fine from kernel's perspective. But resetting the \nresource means we also lose access to that resource because its type gets \ncleared so from kernel perspective the VF BAR stops to exist. Losing it \nmeans the user cannot solve the issue by e.g. resizing some other BAR \nsmaller to make space to allow the VF BARs to assign successfully.\n\nSo I think this code would actually want to check resource_assigned() \nwhich implies also non-zero size.\n\nAFAICT, this change looks fine (despite the diff being very messy).\n\n> -\t\t/* skip empty resources */\n> -\t\tif (!pci_resource_len(pdev, i))\n> -\t\t\tcontinue;\n> +\tif ((pci_resource_flags(pdev, bar) & flags) != flags)\n> +\t\treturn 0;\n>  \n> -\t\tretval = pci_create_attr(pdev, i, 0);\n> -\t\t/* for prefetchable resources, create a WC mappable file */\n> -\t\tif (!retval && arch_can_pci_mmap_wc() &&\n> -\t\t    pci_resource_flags(pdev, i) & IORESOURCE_PREFETCH)\n> -\t\t\tretval = pci_create_attr(pdev, i, 1);\n> -\t\tif (retval) {\n> -\t\t\tpci_remove_resource_files(pdev);\n> -\t\t\treturn retval;\n> -\t\t}\n> -\t}\n> -\treturn 0;\n> +\tif (write_combine && !arch_can_pci_mmap_wc())\n> +\t\treturn 0;\n> +\n> +\treturn a->attr.mode;\n>  }\n> -#else /* !(defined(HAVE_PCI_MMAP) || defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)) */\n> -int __weak pci_create_resource_files(struct pci_dev *dev) { return 0; }\n> -void __weak pci_remove_resource_files(struct pci_dev *dev) { return; }\n> +\n> +static umode_t pci_dev_resource_io_is_visible(struct kobject *kobj,\n> +\t\t\t\t\t      const struct bin_attribute *a,\n> +\t\t\t\t\t      int n)\n> +{\n> +\treturn __pci_resource_attr_is_visible(kobj, a, n, false,\n> +\t\t\t\t\t      IORESOURCE_IO);\n> +}\n> +\n> +static umode_t pci_dev_resource_uc_is_visible(struct kobject *kobj,\n> +\t\t\t\t\t      const struct bin_attribute *a,\n> +\t\t\t\t\t      int n)\n> +{\n> +\treturn __pci_resource_attr_is_visible(kobj, a, n, false,\n> +\t\t\t\t\t      IORESOURCE_MEM);\n> +}\n> +\n> +static umode_t pci_dev_resource_wc_is_visible(struct kobject *kobj,\n> +\t\t\t\t\t      const struct bin_attribute *a,\n> +\t\t\t\t\t      int n)\n> +{\n> +\treturn __pci_resource_attr_is_visible(kobj, a, n, true,\n> +\t\t\t\t\t      IORESOURCE_MEM | IORESOURCE_PREFETCH);\n> +}\n> +\n> +static size_t pci_dev_resource_bin_size(struct kobject *kobj,\n> +\t\t\t\t\tconst struct bin_attribute *a,\n> +\t\t\t\t\tint n)\n> +{\n> +\tstruct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));\n> +\n> +\treturn pci_resource_len(pdev, n);\n> +}\n> +\n> +pci_dev_resource_io_attr(0);\n> +pci_dev_resource_io_attr(1);\n> +pci_dev_resource_io_attr(2);\n> +pci_dev_resource_io_attr(3);\n> +pci_dev_resource_io_attr(4);\n> +pci_dev_resource_io_attr(5);\n> +\n> +pci_dev_resource_uc_attr(0);\n> +pci_dev_resource_uc_attr(1);\n> +pci_dev_resource_uc_attr(2);\n> +pci_dev_resource_uc_attr(3);\n> +pci_dev_resource_uc_attr(4);\n> +pci_dev_resource_uc_attr(5);\n> +\n> +pci_dev_resource_wc_attr(0);\n> +pci_dev_resource_wc_attr(1);\n> +pci_dev_resource_wc_attr(2);\n> +pci_dev_resource_wc_attr(3);\n> +pci_dev_resource_wc_attr(4);\n> +pci_dev_resource_wc_attr(5);\n> +\n> +static const struct bin_attribute *const pci_dev_resource_io_attrs[] = {\n> +\t&dev_resource0_io_attr,\n> +\t&dev_resource1_io_attr,\n> +\t&dev_resource2_io_attr,\n> +\t&dev_resource3_io_attr,\n> +\t&dev_resource4_io_attr,\n> +\t&dev_resource5_io_attr,\n> +\tNULL,\n> +};\n> +\n> +static const struct bin_attribute *const pci_dev_resource_uc_attrs[] = {\n> +\t&dev_resource0_uc_attr,\n> +\t&dev_resource1_uc_attr,\n> +\t&dev_resource2_uc_attr,\n> +\t&dev_resource3_uc_attr,\n> +\t&dev_resource4_uc_attr,\n> +\t&dev_resource5_uc_attr,\n> +\tNULL,\n> +};\n> +\n> +static const struct bin_attribute *const pci_dev_resource_wc_attrs[] = {\n> +\t&dev_resource0_wc_attr,\n> +\t&dev_resource1_wc_attr,\n> +\t&dev_resource2_wc_attr,\n> +\t&dev_resource3_wc_attr,\n> +\t&dev_resource4_wc_attr,\n> +\t&dev_resource5_wc_attr,\n> +\tNULL,\n> +};\n> +\n> +static const struct attribute_group pci_dev_resource_io_attr_group = {\n> +\t.bin_attrs = pci_dev_resource_io_attrs,\n> +\t.is_bin_visible = pci_dev_resource_io_is_visible,\n> +\t.bin_size = pci_dev_resource_bin_size,\n> +};\n> +\n> +static const struct attribute_group pci_dev_resource_uc_attr_group = {\n> +\t.bin_attrs = pci_dev_resource_uc_attrs,\n> +\t.is_bin_visible = pci_dev_resource_uc_is_visible,\n> +\t.bin_size = pci_dev_resource_bin_size,\n> +};\n> +\n> +static const struct attribute_group pci_dev_resource_wc_attr_group = {\n> +\t.bin_attrs = pci_dev_resource_wc_attrs,\n> +\t.is_bin_visible = pci_dev_resource_wc_is_visible,\n> +\t.bin_size = pci_dev_resource_bin_size,\n> +};\n> +\n>  #endif\n>  \n> +int __weak pci_create_resource_files(struct pci_dev *dev) { return 0; }\n> +void __weak pci_remove_resource_files(struct pci_dev *dev) { }\n> +\n>  /**\n>   * pci_write_rom - used to enable access to the PCI ROM display\n>   * @filp: sysfs file\n> @@ -1861,6 +1868,11 @@ static const struct attribute_group pci_dev_group = {\n>  \n>  const struct attribute_group *pci_dev_groups[] = {\n>  \t&pci_dev_group,\n> +#if defined(HAVE_PCI_MMAP) || defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)\n> +\t&pci_dev_resource_io_attr_group,\n> +\t&pci_dev_resource_uc_attr_group,\n> +\t&pci_dev_resource_wc_attr_group,\n> +#endif\n>  \t&pci_dev_config_attr_group,\n>  \t&pci_dev_rom_attr_group,\n>  \t&pci_dev_reset_attr_group,\n> diff --git a/include/linux/pci.h b/include/linux/pci.h\n> index 1c270f1d5123..a7a104427b07 100644\n> --- a/include/linux/pci.h\n> +++ b/include/linux/pci.h\n> @@ -2501,10 +2501,8 @@ int pcibios_alloc_irq(struct pci_dev *dev);\n>  void pcibios_free_irq(struct pci_dev *dev);\n>  resource_size_t pcibios_default_alignment(void);\n>  \n> -#if !defined(HAVE_PCI_MMAP) && !defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)\n>  extern int pci_create_resource_files(struct pci_dev *dev);\n>  extern void pci_remove_resource_files(struct pci_dev *dev);\n> -#endif\n>  \n>  #if defined(CONFIG_PCI_MMCONFIG) || defined(CONFIG_ACPI_MCFG)\n>  void __init pci_mmcfg_early_init(void);\n>","headers":{"Return-Path":"\n <linuxppc-dev+bounces-19556-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=btD35F4y;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-19556-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=198.175.65.14","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=btD35F4y;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=linux.intel.com\n (client-ip=198.175.65.14; helo=mgamail.intel.com;\n envelope-from=ilpo.jarvinen@linux.intel.com; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsYVR29H9z1yGb\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 20:50:22 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4fsYVP3Wf5z2yft;\n\tFri, 10 Apr 2026 20:50:21 +1000 (AEST)","from mgamail.intel.com (mgamail.intel.com [198.175.65.14])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4fsYVJ3mgBz2xT6\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri, 10 Apr 2026 20:50:13 +1000 (AEST)","from orviesa001.jf.intel.com ([10.64.159.141])\n  by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 03:50:10 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.244.118])\n  by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 03:49:58 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1775818221;\n\tcv=none;\n b=fmB8hA/b4osn4HTTIr7W4LfmkFfMLS+pLCxcoM4eR6/fw91ZpTMM+73AMwoLWQD0hkPbb0tj9Fx1GIx8Vv+b6Gm7Iy2orGHzgBN0bSpeRNxnJdE3WBLCSbdM1Ua7uzl7ZNaZlWSlJxLCPF4NwibaeosUo7v4/IMWa2Q2ipWOAt1BbtEH441wJ9KUb1qZY565sTreVZN9uP+3jDKVz624U1SXLy6yMPkUaPVfaIU4s4wgiiMg1jTgtw4OAi3/m8WnwD8AompJ1ireMkxkZs9y96vBccp/8vgpjuYpZu16YlqG+Wxqbfk4/64r4ncgnbBj853Y7uyJwq5fVkzL/8gPsQ==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1775818221; c=relaxed/relaxed;\n\tbh=fVXtGxEZhlalRdWn+jmflJwiiZlyyFnI18hmNwAuUks=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=SgJEnxRvvqNmGD6k0rpPiwbnBQotChl92DWUKzLAo9GaO4y3hX4qFxQAnZwN1CRFf4Uo+5oFOFiH+XagzZD+nLqIEcKvkpIXstCU5BJY7Orl8de7F4kWQTIh7SwcCihC94YITvYZ8l7LEUpDbpnbSTzxPkgLTh/syYiHLHj7J1WFkjRNOjqOj0Xdyju0fPaUcuQz4oLCfPdUM8pKmud4JCYpQFUBWNk9bYC2xgvyYi38/Iu89S/kDlyRCM8CyYP3H4/puvmRfZB9x7L2cxIt8wlsQrJRKVvTanbrDOO12g+mr0BMbsaG3vJ3L2VLBoz89V4ZjsY5efuOEr694YcAyw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n dkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=btD35F4y; dkim-atps=neutral;\n spf=pass (client-ip=198.175.65.14; helo=mgamail.intel.com;\n envelope-from=ilpo.jarvinen@linux.intel.com;\n receiver=lists.ozlabs.org) smtp.mailfrom=linux.intel.com","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n  t=1775818217; x=1807354217;\n  h=from:date:to:cc:subject:in-reply-to:message-id:\n   references:mime-version:content-id;\n  bh=htUsvW9HcAW+4Tu7OtqXPagEiVPdCGWQYuS/yVUGtOU=;\n  b=btD35F4yDx5CDzuEkadRELIvyWoH2qR4v22kDrUcKWHj6R8zFxTpfHnA\n   H7VWPZJUNmhbA4TDYTLfd4R4EErX/IRwgbOnsRqio9vmyVO+TTx7N9e2t\n   JF0Xb+iB8FDlmBSbT4NlfAyb4ToCgQ8lcYv+X42p9wYW1n+KDNuhEyFpd\n   FAZJSYidvQaHKJntrlkYU9YPfd5YpD3pPXvJ1/bVyjmDsPFID8xHewNxu\n   /H2qcCRZ9XOmKCIDh/tx0aaEmEx5XiohcLwOOxvhF/cXg92HvkQuRaYg4\n   Zz6MmxBVnPeIRQFf+WNg0aPy6F8XaPTUqtBRuaozddqdCOg5kRpG3aPFD\n   w==;","X-CSE-ConnectionGUID":["W4Lgb10qRUy6AwqxZTx36w==","qz+PkvWOTiCtwSASfDIxpg=="],"X-CSE-MsgGUID":["lg0PEXffQh6apP3eDAf+Ug==","QFr1YiJQRoO439xKOPHsHA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11754\"; a=\"80694945\"","E=Sophos;i=\"6.23,171,1770624000\";\n   d=\"scan'208\";a=\"80694945\"","E=Sophos;i=\"6.23,171,1770624000\";\n   d=\"scan'208\";a=\"267020190\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>","Date":"Fri, 10 Apr 2026 13:49:54 +0300 (EEST)","To":"=?iso-8859-2?q?Krzysztof_Wilczy=F1ski?= <kwilczynski@kernel.org>","cc":"Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <helgaas@kernel.org>,\n  Manivannan Sadhasivam <mani@kernel.org>,\n  Lorenzo Pieralisi <lpieralisi@kernel.org>,\n  Magnus Lindholm <linmag7@gmail.com>, Matt Turner <mattst88@gmail.com>,\n  Richard Henderson <richard.henderson@linaro.org>,\n  Christophe Leroy <chleroy@kernel.org>,\n  Madhavan Srinivasan <maddy@linux.ibm.com>,\n  Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>,\n  Dexuan Cui <decui@microsoft.com>,\n =?iso-8859-2?q?Krzysztof_Ha=B3asa?= <khalasa@piap.pl>,\n  Lukas Wunner <lukas@wunner.de>, Oliver O'Halloran <oohall@gmail.com>,\n  Saurabh Singh Sengar <ssengar@microsoft.com>,\n  Shuan He <heshuan@bytedance.com>,\n  Srivatsa Bhat <srivatsabhat@microsoft.com>, linux-pci@vger.kernel.org,\n  linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 06/20] PCI/sysfs: Convert PCI resource files to static\n attributes","In-Reply-To":"<20260410055040.39233-7-kwilczynski@kernel.org>","Message-ID":"<4fc23ce0-7103-545b-bc11-230b52c2de94@linux.intel.com>","References":"<20260410055040.39233-1-kwilczynski@kernel.org>\n <20260410055040.39233-7-kwilczynski@kernel.org>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"multipart/mixed; BOUNDARY=\"8323328-2006288344-1775817599=:1195\"","Content-ID":"<d01f4f57-bd3d-a780-7a87-f17ddb4c39ec@linux.intel.com>","X-Spam-Status":"No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=disabled\n\tversion=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3675819,"web_url":"http://patchwork.ozlabs.org/comment/3675819/","msgid":"<20260410111338.GB1750802@rocinante>","date":"2026-04-10T11:13:38","subject":"Re: [PATCH 06/20] PCI/sysfs: Convert PCI resource files to static\n attributes","submitter":{"id":86709,"url":"http://patchwork.ozlabs.org/api/people/86709/","name":"Krzysztof Wilczyński","email":"kwilczynski@kernel.org"},"content":"Hello,\n\n> > -\t/* Expose the PCI resources from this device as files */\n> > -\tfor (i = 0; i < PCI_STD_NUM_BARS; i++) {\n> > +\tif (!pci_resource_len(pdev, bar))\n> > +\t\treturn 0;\n> \n> I know it's same as in the previous code but I dislike assuming len != 0 \n> implies resource has been assigned. While it currently holds, I'd want to \n> change that eventually.\n> \n> The current behavior causes issue e.g. if IOV resource fails to assign, it \n> is reset (making its len 0 among other thing) and since IOV resource are \n> optional that is fine from kernel's perspective. But resetting the \n> resource means we also lose access to that resource because its type gets \n> cleared so from kernel perspective the VF BAR stops to exist. Losing it \n> means the user cannot solve the issue by e.g. resizing some other BAR \n> smaller to make space to allow the VF BARs to assign successfully.\n> \n> So I think this code would actually want to check resource_assigned() \n> which implies also non-zero size.\n\nMakes sense.\n\nI will update the code to use resource_assigned().  Since we are working on\nthis code anyway, it would be only prudent to also do the right thing.\n\n> AFAICT, this change looks fine (despite the diff being very messy).\n\nThank you!\n\n\tKrzysztof","headers":{"Return-Path":"\n <linuxppc-dev+bounces-19560-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=X5l16K95;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-19560-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.105.4.254","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=X5l16K95;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=kwilczynski@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsZ1N2rvMz1yGb\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:13:44 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4fsZ1N0BMGz2yft;\n\tFri, 10 Apr 2026 21:13:44 +1000 (AEST)","from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4fsZ1M1wtHz2xT6\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri, 10 Apr 2026 21:13:43 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby tor.source.kernel.org (Postfix) with ESMTP id 0836A6014B;\n\tFri, 10 Apr 2026 11:13:41 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 74BC9C19421;\n\tFri, 10 Apr 2026 11:13:40 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1775819623;\n\tcv=none;\n b=KAmFNxhhXHCEgMuH3QUTnqM1Tt9lkbR+QYNKj0vlAmiiPJN3s2q2aCJCKnrc5vJ8kAdFkP0rzRlJHi+B1b3u36ouOFqmlbKhF0Sejy1t8oIHpuIXHSguGAEO58kb+acr05QSHx3OlRay82hUYF66er/CC3IezmJIk0SvAidgYDaaTl4BBlthWEWauFrO8rutJMoLl4mxJyTaktYNWJqXpsDFzr2j3Xrs1afv5vnibyGwBPvYpz+HpiZuK5AJyhliwspgF83ob2lrxbXKL16162JxSC5kS3en+jvWtN5csgo0Q/tn8/Za4qk45c9vDLAO0Hdwbs0E1zLqscY43C3SSw==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1775819623; c=relaxed/relaxed;\n\tbh=RqNVnzl4sbELZDa2E3es1i/+o9lHIHVJUcSg0Sefjak=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=ZH9fAf5soYICCLAjMNb8VnuvbSYbWomZqUIDVCA6krzxv49Bqwt0k6HUs3xeszpeCM/OZkboLQmbcist71+LhflZdAQ97QoQbcydmaBjtHtj3lrrLqNgHvH+MbUcZ+N1fohjRXFyJoS3ZZBIUnxgN1MVMj8TNqbkZJJlDsJK8o1CFZofQ7RMc4ac7eSC68ZmFRaQfUc942VlmOQMpFHpJ+stVnqjrB92TzWNyyZkxUt3oDTZMt5dElf5IEMWuX0j3AnXp2Ujxf0y65IhiGljErRUJkZt5xT7nnx1SY9KRfk4OUL98/bgf4bPQtE578rD87K2DEjhrzymMNVaA2kyuw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=X5l16K95; dkim-atps=neutral;\n spf=pass (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=kwilczynski@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775819620;\n\tbh=tp+2vBtC3b7i++pW7T3oZUkkQ00XThq2Bf8TIH4wQGE=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=X5l16K95Yuy7Zv4u2Ee+Up4qtxS0POfOwlZpsSGzrt9Ojmt3piTwXDoyWVgseWXnE\n\t BE1JTvmcNII3Rc6iilUmw/jJL/PBTRga43FG1gGeILK4OVNM7OKK9FUzYXel4sElhg\n\t /EzZY/omP6f6NsjJlZ1lVRYAYLkQC1UFVtqIce6UXJWtaCvLa0faqH7IhfUWjfPoiU\n\t Z4B3RwVIrJbExnBeBJwyqduESMXXdJyGkzKeIYCL3jlNGM0rFFh8JrhxIsBb6OlgJW\n\t cqWeDJanlZfnOnWa90YObE79zRwptPIDMf0XaXxMrtOBMxZ98I6EKnpFY1GzK1TrdZ\n\t 1L3qfid+pwhPw==","Date":"Fri, 10 Apr 2026 20:13:38 +0900","From":"Krzysztof =?utf-8?q?Wilczy=C5=84ski?= <kwilczynski@kernel.org>","To":"Ilpo =?utf-8?b?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>","Cc":"Bjorn Helgaas <bhelgaas@google.com>, Bjorn Helgaas <helgaas@kernel.org>,\n Manivannan Sadhasivam <mani@kernel.org>,\n Lorenzo Pieralisi <lpieralisi@kernel.org>,\n Magnus Lindholm <linmag7@gmail.com>, Matt Turner <mattst88@gmail.com>,\n Richard Henderson <richard.henderson@linaro.org>,\n Christophe Leroy <chleroy@kernel.org>,\n Madhavan Srinivasan <maddy@linux.ibm.com>,\n Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>,\n Dexuan Cui <decui@microsoft.com>,\n Krzysztof =?utf-8?q?Ha=C5=82asa?= <khalasa@piap.pl>,\n Lukas Wunner <lukas@wunner.de>, Oliver O'Halloran <oohall@gmail.com>,\n Saurabh Singh Sengar <ssengar@microsoft.com>,\n Shuan He <heshuan@bytedance.com>, Srivatsa Bhat <srivatsabhat@microsoft.com>,\n linux-pci@vger.kernel.org, linux-alpha@vger.kernel.org,\n linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH 06/20] PCI/sysfs: Convert PCI resource files to static\n attributes","Message-ID":"<20260410111338.GB1750802@rocinante>","References":"<20260410055040.39233-1-kwilczynski@kernel.org>\n <20260410055040.39233-7-kwilczynski@kernel.org>\n <4fc23ce0-7103-545b-bc11-230b52c2de94@linux.intel.com>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<4fc23ce0-7103-545b-bc11-230b52c2de94@linux.intel.com>","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}}]