From: Mario Limonciello <superm1@kernel.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: mario.limonciello@amd.com, bhelgaas@google.com,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v2] PCI: Adjust visibility of boot_display attribute instead of creation
Date: Mon, 21 Jul 2025 10:28:58 -0500 [thread overview]
Message-ID: <119a8f09-a326-45fb-aeca-9d2f37fe36c7@kernel.org> (raw)
In-Reply-To: <20250721105744.000046bc@huawei.com>
On 7/21/25 4:57 AM, Jonathan Cameron wrote:
> On Sun, 20 Jul 2025 10:15:08 -0500
> Mario Limonciello <superm1@kernel.org> wrote:
>
>> From: Mario Limonciello <mario.limonciello@amd.com>
>>
>> There is a desire to avoid creating new sysfs files late, so instead
>> of dynamically deciding to create the boot_display attribute, make
>> it static and use sysfs_update_group() to adjust visibility on the
>> applicable devices.
>>
>> This also fixes a compilation warning when compiled without
>> CONFIG_VIDEO on sparc.
>>
>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> Closes: https://lore.kernel.org/linux-next/20250718224118.5b3f22b0@canb.auug.org.au/
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>
> Leaving aside the 'where to call it' discussions, a few bits of feedback on the
> code. See inline.
>
Thanks!
>
>> ---
>> v2:
>> * Change to sysfs_update_group() instead
>> ---
>> drivers/pci/pci-sysfs.c | 59 +++++++++++++++++------------------------
>> 1 file changed, 25 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>> index 6b1a0ae254d3a..462a90d13eb87 100644
>> --- a/drivers/pci/pci-sysfs.c
>> +++ b/drivers/pci/pci-sysfs.c
>> @@ -1059,37 +1059,6 @@ void pci_remove_legacy_files(struct pci_bus *b)
>> }
>> #endif /* HAVE_PCI_LEGACY */
>>
>> -/**
>> - * pci_create_boot_display_file - create a file in sysfs for @dev
>> - * @pdev: dev in question
>> - *
>> - * Creates a file `boot_display` in sysfs for the PCI device @pdev
>> - * if it is the boot display device.
>> - */
>> -static int pci_create_boot_display_file(struct pci_dev *pdev)
>> -{
>> -#ifdef CONFIG_VIDEO
>> - if (video_is_primary_device(&pdev->dev))
>> - return sysfs_create_file(&pdev->dev.kobj, &dev_attr_boot_display.attr);
>> -#endif
>> - return 0;
>> -}
>> -
>> -/**
>> - * pci_remove_boot_display_file - remove the boot display file for @dev
>> - * @pdev: dev in question
>> - *
>> - * Removes the file `boot_display` in sysfs for the PCI device @pdev
>> - * if it is the boot display device.
>> - */
>> -static void pci_remove_boot_display_file(struct pci_dev *pdev)
>> -{
>> -#ifdef CONFIG_VIDEO
>> - if (video_is_primary_device(&pdev->dev))
>> - sysfs_remove_file(&pdev->dev.kobj, &dev_attr_boot_display.attr);
>> -#endif
>> -}
>> -
>> #if defined(HAVE_PCI_MMAP) || defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)
>> /**
>> * pci_mmap_resource - map a PCI resource into user memory space
>> @@ -1691,6 +1660,29 @@ static const struct attribute_group pci_dev_resource_resize_group = {
>> .is_visible = resource_resize_is_visible,
>> };
>>
>> +static struct attribute *pci_display_attrs[] = {
>> + &dev_attr_boot_display.attr,
>> + NULL,
>
> Trivial but I'd drop the comma after the NULL. It's at terminating entry and
> we don't want it to be easy to add stuff after it!
Thanks!
Sounds sensible. If I spin a v4 keeping it in pci-sysfs.c I'll drop it.
>
>> +};
>> +
>> +static umode_t pci_boot_display_visible(struct kobject *kobj,
>> + struct attribute *a, int n)
>> +{
>> +#ifdef CONFIG_VIDEO
>> + struct device *dev = kobj_to_dev(kobj);
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> +
>> + if (a == &dev_attr_boot_display.attr && video_is_primary_device(&pdev->dev))
> Is video_is_primary_device() stubbed out on !CONFIG_VIDEO?
>
> There seems to be a stub in include/asm-generic/video.h
>
> If it always is, drop the ifdef guards whilst you are here as the compiler
> can see that and remove the code anyway.
>
I feel like there was a reason for this from earlier in the versions of
the series introducing boot_display, but with how things are now I think
you're right.
I'll do some test builds without CONFIG_VIDEO set to convince myself.
>
>> + return a->mode;
>> +#endif
>> + return 0;
>> +}
>> +
>> +static const struct attribute_group pci_display_attr_group = {
>> + .attrs = pci_display_attrs,
>> + .is_visible = pci_boot_display_visible,
>> +};
>> +
>> int __must_check pci_create_sysfs_dev_files(struct pci_dev *pdev)
>> {
>> int retval;
>> @@ -1698,7 +1690,7 @@ int __must_check pci_create_sysfs_dev_files(struct pci_dev *pdev)
>> if (!sysfs_initialized)
>> return -EACCES;
>>
>> - retval = pci_create_boot_display_file(pdev);
>> + retval = sysfs_update_group(&pdev->dev.kobj, &pci_display_attr_group);
>> if (retval)
>> return retval;
>>
>> @@ -1716,7 +1708,6 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
>> if (!sysfs_initialized)
>> return;
>>
>> - pci_remove_boot_display_file(pdev);
>> pci_remove_resource_files(pdev);
>> }
>>
>> @@ -1755,7 +1746,6 @@ static umode_t pci_dev_attrs_are_visible(struct kobject *kobj,
>>
>> if (a == &dev_attr_boot_vga.attr && pci_is_vga(pdev))
>> return a->mode;
>> -
> Unrelated change.
Thanks, that snuck in when I was rearranging and I totally missed it.
I dropped it in v3.
>
>> return 0;
>> }
>>
>> @@ -1845,6 +1835,7 @@ static const struct attribute_group pcie_dev_attr_group = {
>>
>> const struct attribute_group *pci_dev_attr_groups[] = {
>> &pci_dev_attr_group,
>> + &pci_display_attr_group,
>> &pci_dev_hp_attr_group,
>> #ifdef CONFIG_PCI_IOV
>> &sriov_pf_dev_attr_group,
>
prev parent reply other threads:[~2025-07-21 15:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-20 15:15 [PATCH v2] PCI: Adjust visibility of boot_display attribute instead of creation Mario Limonciello
2025-07-20 15:34 ` Lukas Wunner
2025-07-21 7:15 ` Manivannan Sadhasivam
2025-07-21 15:23 ` Mario Limonciello
2025-07-22 11:02 ` [External] " Shuan He
2025-07-21 9:57 ` Jonathan Cameron
2025-07-21 15:28 ` Mario Limonciello [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=119a8f09-a326-45fb-aeca-9d2f37fe36c7@kernel.org \
--to=superm1@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox