[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvopvYGtqLzm5m4yhXLih7SuSSuw4RtRhBCiXob+rXsMP5fSA@mail.gmail.com>
Date: Wed, 17 Sep 2025 11:08:26 +0200
From: Matthew Wood <thepacketgeek@...il.com>
To: Krzysztof Wilczyński <kw@...ux.com>
Cc: Keith Busch <kbusch@...nel.org>, Bjorn Helgaas <helgaas@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, Mario Limonciello <superm1@...nel.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [RESEND PATCH v7 1/1] PCI/sysfs: Expose PCIe device serial number
Thank you all for the helpful responses!
> Hello,
>
> > > I can see that the PCI r3.0 (conventional PCI) spec doesn't include
> > > the Device Serial Number Capability and the PCIe spec does include it,
> > > but this seems like it would fit better in the pci_dev_dev_attrs[],
> > > and the visibility check would be parallel to the
> > > dev_attr_boot_vga.attr check there.
> >
> > I'm not sure I agree. The pci_dev_dev_attrs apply to all pci devices,
> > but DSN only exists in PCIe Extended Capability space. Conventional pci
> > config requests couldn't even describe it, so seems okay to fence it off
> > using the PCI-Express attribute group that already has that visibility
> > barrier.
>
> PCI-X 2.0 added Extended Configuration Space[1]. Perhaps why Bjorn had
> different attributes group in mind here.
Looking more at pci_get_dsn, I see that there's no check for pci_is_pcie so I
understand the thoughts here and can see how it would make sense to move
to pci_dev_dev_attrs.
I also agree that the visibility check for dsn would match the
existing dev_attr_boot_vga
check, with the additional advantage of not making the existing attrs in
pcie_dev_attrs_are_visible oddballs without visibility checks.
I will prepare a v8 with that change, thanks again!
Powered by blists - more mailing lists