[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250305200500.GA267333@bhelgaas>
Date: Wed, 5 Mar 2025 14:05:00 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Alistair Francis <alistair@...stair23.me>
Cc: bhelgaas@...gle.com, linux-pci@...r.kernel.org,
Jonathan.Cameron@...wei.com, lukas@...ner.de,
alex.williamson@...hat.com, christian.koenig@....com,
kch@...dia.com, gregkh@...uxfoundation.org, logang@...tatee.com,
linux-kernel@...r.kernel.org, alistair23@...il.com,
chaitanyak@...dia.com, rdunlap@...radead.org
Subject: Re: [PATCH v16 3/4] PCI/DOE: Expose the DOE features via sysfs
On Thu, Feb 27, 2025 at 02:34:02PM +1000, Alistair Francis wrote:
> The PCIe 6 specification added support for the Data Object
> Exchange (DOE).
> +++ b/drivers/pci/probe.c
> @@ -2662,6 +2662,9 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> WARN_ON(ret < 0);
>
> pci_npem_create(dev);
> +
> + ret = pci_doe_sysfs_init(dev);
> + WARN_ON(ret < 0);
IIUC the "doe_features" directory is added implicitly by
device_add_attrs() in device_add(), but the *contents* of that
directory can't be done that way because they're dynamic, based on the
DOE features we discovered.
I see that we WARN_ON() for device_add() failure, but it doesn't
really seem like much of an error handling strategy in either case.
I think we'll just get a stack trace that's alarming and probably not
useful.
I think it might be more useful to use pci_warn() at the interesting
places that might fail inside pci_doe_sysfs_init(), e.g., where we
know the name of the relevant feature, and make pci_doe_sysfs_init()
itself void.
Powered by blists - more mailing lists