Re: [PATCH v5] PCI: s390: Expose the UID as an arch specific PCI slot attribute
From: Niklas Schnelle
Date: Thu Apr 02 2026 - 04:39:53 EST
On Wed, 2026-04-01 at 13:20 -0700, Randy Dunlap wrote:
>
> On 4/1/26 7:50 AM, Niklas Schnelle wrote:
> > On s390, an individual PCI function can generally be identified by two
> > identifiers, the FID and the UID. Which identifier is used depends on
> > the scope and the platform configuration.
> >
> > The first identifier, the FID, is always available and identifies a PCI
> > device uniquely within a machine. The FID may be virtualized by
> > hypervisors, but on the LPAR level, the machine scope makes it
> > impossible to create the same configuration based on FIDs on two
> > different LPARs of the same machine, and difficult to reuse across
> > machines.
> >
> > Such matching LPAR configurations are useful, though, allowing
> > standardized setups and booting a Linux installation on different LPARs.
> > To this end the UID, or user-defined identifier, was introduced. While
> > it is only guaranteed to be unique within an LPAR and only if indicated
> > by firmware, it allows users to replicate PCI device setups.
> >
> > On s390, which uses a machine hypervisor, a per PCI function hotplug
> > model is used. The shortcoming with the UID then is, that it is not
> > visible to the user without first attaching the PCI function and
> > accessing the "uid" device attribute. The FID, on the other hand, is
> > used as the slot name and is thus known even with the PCI function in
> > standby.
> >
> > Remedy this shortcoming by providing the UID as an attribute on the slot
> > allowing the user to identify a PCI function based on the UID without
> > having to first attach it. Do this via a macro mechanism analogous to
> > what was introduced by commit 265baca69a07 ("s390/pci: Stop usurping
> > pdev->dev.groups") for the PCI device attributes.
> >
> > Reviewed-by: Gerd Bayer <gbayer@xxxxxxxxxxxxx>
> > Reviewed-by: Julian Ruess <julianr@xxxxxxxxxxxxx>
> > Signed-off-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
> > ---
> > Note: I considered adding the UID as a generic slot index attribute
> > analogous to the PCI device index attribute (SMBIOS index / s390 UID)
> > but decided against it as this seems rather s390 specific.
> >
> > v4->v5:
> > - Rebase on v7.0-rc6
> > - Reworded note
> > - Add documentation for the new attribute
> > - Link to v4: https://lore.kernel.org/r/20251217-uid_slot-v4-1-559ceb59ba69@xxxxxxxxxxxxx
> >
> > v3->v4:
> > - Rebase on v6.19-rc1
> > - Collect R-bs
> > - Link to v3: https://lore.kernel.org/r/20251015-uid_slot-v3-1-44389895c1bb@xxxxxxxxxxxxx
> > ---
> >
> > ---
> > Documentation/arch/s390/pci.rst | 7 +++++++
> > arch/s390/include/asm/pci.h | 4 ++++
> > arch/s390/pci/pci_sysfs.c | 20 ++++++++++++++++++++
> > drivers/pci/slot.c | 13 ++++++++++++-
> > 4 files changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
> > index d5755484d8e75c7bf67a350e61bbe04f0452a2fa..03afb57ece4df90a75597cb34c1f048c2e162b67 100644
> > --- a/Documentation/arch/s390/pci.rst
> > +++ b/Documentation/arch/s390/pci.rst
> > @@ -55,6 +55,13 @@ Entries specific to zPCI functions and entries that hold zPCI information.
> >
> > - /sys/bus/pci/slots/XXXXXXXX/power
> >
> > + In addition to using the FID as the name of the slot the slot directory
> > + also contains the following s390 specific slot attributes
>
> s390-specific
>
> Use a period (full stop, '.') at the end of the sentence above.
Done
>
> > +
> > + - uid
> > + The User-defined identifier (UID) of the function which may be configured
> > + by this slot. See also the corresponding attribute of the device.
>
> These 3 lines are run together in html output. Maybe add a ':' or '-' after
> uid?
Good point. Thank you. This is actually an issue in the whole file e.g.
below for the device attributes. So I think I'll add another patch to
fix it for the rest of the file. There is also some naming issues too
anyway like in the PCI attribute "uid" is called "user identifier"
which doesn't match our architecture wording and is highly confusing.
Thanks,
Niklas Schnelle