All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Matthew Wood <thepacketgeek@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH pci-next v1 0/1] PCI/sysfs: Expose PCIe device serial number
Date: Wed, 16 Jul 2025 10:23:27 +0100	[thread overview]
Message-ID: <20250716102327.00004dd7@huawei.com> (raw)
In-Reply-To: <CADvopvZZKCdwT=XfaJzgFRgH=eXcTmjsdA8-86hJaki5PDjx=A@mail.gmail.com>

On Tue, 15 Jul 2025 08:59:42 -0700
Matthew Wood <thepacketgeek@gmail.com> wrote:

> On Tue, Jul 15, 2025 at 4:19 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Sat, 12 Jul 2025 18:17:12 -0700
> > Matthew Wood <thepacketgeek@gmail.com> wrote:
> >  
> > > Add a single sysfs read-only interface for reading PCIe device serial
> > > numbers from userspace in a programmatic way. This device attribute
> > > uses the same 2-byte dashed formatting as lspci serial number capability
> > > output:
> > >
> > >     more /sys/devices/pci0000:c0/0000:c0:01.1/0000:c1:00.0/0000:c2:1f.0/0000:cc:00.0/device_serial_number
> > >     00-80-ee-00-00-00-41-80
> > >  
> >
> > What is the use case for this? I can think of some possibilities but good to
> > see why you care here.  
> 
> Two primary use cases we have are for inventory tooling and health
> check tooling; being able to
> reliably collect device serial numbers for tracking unique devices
> whose BDFs could change is
> critical. Sometimes in the process of hardware troubleshooting, cards
> are swapped and BDF idents
> change but we want to track devices by serial number without possibly
> fragile regexps.

Ok.  So you want to avoid having pull this from lspci output which
makes sense to me. Not sure what Bjorn and others think about this
though.


> 
> >
> >  
> > > Accompanying lspci output:
> > >
> > >     sudo lspci -vvv -s cc:00.0
> > >         cc:00.0 Serial Attached SCSI controller: Broadcom / LSI PCIe Switch management endpoint (rev b0)
> > >             Subsystem: Broadcom / LSI Device 0144
> > >             ...
> > >             Capabilities: [100 v1] Device Serial Number 00-80-ee-00-00-00-41-80
> > >             ...
> > >
> > > If a device doesn't support the serial number capability, userspace will receive
> > > an empty read:  
> >
> > Better if possible to not expose the sysfs attribute if no such capability.
> > We already have pcie_dev_attrs_are_visible() so easy to extend that.  
> 
> That's a great point, it looks like I could match on the attribute
> name to specifically hide device_serial_number
> if the device does not support the cap, but I can't find any precedent
> for matching on a->name in pci-sysfs.c.
> Would something like this be alright after the check for pci_is_pcie(dev):
> 
>     if (a->name == "device_serial_number") {
>         // check if device has serial, if not return 0
>     }

if (a == &dev_attr_device_serial_number.attr)
or something like that.

No need for string matching.

Jonathan


> 
> >
> >  
> > >
> > >     more /sys/devices/pci0000:00/0000:00:07.1/device_serial_number
> > >     echo $?
> > >     0
> > >
> > >
> > > Matthew Wood (1):
> > >   PCI/sysfs: Expose PCIe device serial number
> > >
> > >  drivers/pci/pci-sysfs.c | 17 +++++++++++++++++
> > >  1 file changed, 17 insertions(+)
> > >  
> >  


      reply	other threads:[~2025-07-16  9:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-13  1:17 [PATCH pci-next v1 0/1] PCI/sysfs: Expose PCIe device serial number Matthew Wood
2025-07-13  1:17 ` [PATCH pci-next v1 1/1] " Matthew Wood
2025-07-15 11:19 ` [PATCH pci-next v1 0/1] " Jonathan Cameron
2025-07-15 15:59   ` Matthew Wood
2025-07-16  9:23     ` Jonathan Cameron [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=20250716102327.00004dd7@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=thepacketgeek@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.