From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Benjamin Block <bblock@linux.ibm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Lukas Wunner <lukas@wunner.de>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Julian Ruess <julianr@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Ramesh Errabolu <ramesh@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: s390: Expose the UID as an arch specific PCI slot attribute
Date: Fri, 26 Sep 2025 20:25:07 +0200 [thread overview]
Message-ID: <b8c610fa2ac725364c8e485e948c7bd6efd605fa.camel@linux.ibm.com> (raw)
In-Reply-To: <20250926142714.GB17059@p1gen4-pw042f0m.boeblingen.de.ibm.com>
On Fri, 2025-09-26 at 16:27 +0200, Benjamin Block wrote:
> > diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> > index 41f900f693d92522ff729829e446b581977ef3ff..23eed78d9dce72ef466679f31c78aca52ba00f99 100644
> > --- a/arch/s390/include/asm/pci.h
> > +++ b/arch/s390/include/asm/pci.h
> > @@ -207,6 +207,10 @@ extern const struct attribute_group zpci_ident_attr_group;
> > &pfip_attr_group, \
> > &zpci_ident_attr_group,
> >
--- snip --
> > +extern const struct attribute_group zpci_slot_attr_group;
> > +
> > +#define ARCH_PCI_SLOT_GROUPS (&zpci_slot_attr_group)
>
> I don't know the history exactly, but this can't be easily extended like the
> other group above `ARCH_PCI_DEV_GROUPS`.
>
> (&zpci_slot_attr_group, \
> &zpci_slot_attr_group_b)
>
> Won't compile. The way `ARCH_PCI_DEV_GROUPS` does it, attaching a different
> group is just adding a new line.
Without the parenthesis it should. I only added them because otherwise
checkpatch complains and it's still valid for a single item to have
parenthesis.
>
> > diff --git a/arch/s390/pci/pci_sysfs.c b/arch/s390/pci/pci_sysfs.c
> > index 0ee0924cfab7e5d22468fb197ee78cac679d8c13..997dff3796094680d9a3f0b6eb27a89fa1ed30b2 100644
> > --- a/arch/s390/pci/pci_sysfs.c
> > +++ b/arch/s390/pci/pci_sysfs.c
> > @@ -178,6 +178,17 @@ static ssize_t index_show(struct device *dev,
> > }
> > static DEVICE_ATTR_RO(index);
> >
> > --- snip ---
> > +{
> > + struct zpci_dev *zdev = container_of(slot->hotplug, struct zpci_dev,
> > + hotplug_slot);
> > +
> > + return sysfs_emit(buf, "0x%x\n", zdev->uid);
>
> Do we need a special case for when `uid` is 0? That would imply the uid is
> invalid, right? Would we want to return an error in that case (-EINVAL, or
> smth)?
>
> Also, do we want to use the same format as in `zpci_setup_bus_resources()`
> with the 4 leading 0's (`0x%04x`)?
I chose to match the "uid" device attribute here ("zpci_attr(uid,
"0x%x\n", uid)" in the beginning of the same file). This doesn't
special case UID 0. You are right that this is an invalid UID though.
It also still exposes the UID even if it is not guaranteed to be
unique. But we'll make that setting known to user-space separately.
I feel like knowing the UIDs can still be helpful even when they are
not unique, for example to check that they've been set correctly from
within Linux before enabling UID Checking.
>
> > +}
> > +
> > +static struct pci_slot_attribute zpci_slot_attr_uid =
> > + __ATTR(uid, 0444, zpci_uid_slot_show, NULL);
>
> __ATTR_RO()?
next prev parent reply other threads:[~2025-09-26 18:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 13:14 [PATCH] PCI: s390: Expose the UID as an arch specific PCI slot attribute Niklas Schnelle
2025-09-26 14:27 ` Benjamin Block
2025-09-26 18:25 ` Niklas Schnelle [this message]
2025-09-30 9:09 ` Benjamin Block
2025-10-08 11:05 ` Niklas Schnelle
2025-09-26 16:34 ` Ramesh Errabolu
2025-09-26 18:36 ` Niklas Schnelle
2025-09-26 18:44 ` Ramesh Errabolu
2025-10-02 18:50 ` Ramesh Errabolu
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=b8c610fa2ac725364c8e485e948c7bd6efd605fa.camel@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=bblock@linux.ibm.com \
--cc=bhelgaas@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=gbayer@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=julianr@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mjrosato@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=ramesh@linux.ibm.com \
--cc=svens@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox