From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
Christian Brauner <christian.brauner@ubuntu.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, Pierre Morel <pmorel@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Viktor Mihajlovski <mihajlov@linux.ibm.com>
Subject: Re: [RFC 1/1] s390/pci: expose UID checking state in sysfs
Date: Thu, 14 Jan 2021 14:20:10 +0100 [thread overview]
Message-ID: <675aa466-59ea-cf8a-6eec-caa6478ba4cd@linux.ibm.com> (raw)
In-Reply-To: <20210113185500.GA1918216@bjorn-Precision-5520>
On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
>>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>>>> We use the UID of a zPCI adapter, or the UID of the function zero if
>>>> there are multiple functions in an adapter, as PCI domain if and only if
>>>> UID Checking is turned on.
>>>> Otherwise we automatically generate domains as devices appear.
>>>>
>>>> The state of UID Checking is thus essential to know if the PCI domain
>>>> will be stable, yet currently there is no way to access this information
>>>> from userspace.
>>>> So let's solve this by showing the state of UID checking as a sysfs
>>>> attribute in /sys/bus/pci/uid_checking
>
>>>> +/* Global zPCI attributes */
>>>> +static ssize_t uid_checking_show(struct kobject *kobj,
>>>> + struct kobj_attribute *attr, char *buf)
>>>> +{
>>>> + return sprintf(buf, "%i\n", zpci_unique_uid);
>>>> +}
>>>> +
>>>> +static struct kobj_attribute sys_zpci_uid_checking_attr =
>>>> + __ATTR(uid_checking, 0444, uid_checking_show, NULL);
>>>
>>> Use DEVICE_ATTR_RO instead of __ATTR.
>>
>> It's my understanding that DEVICE_ATTR_* is only for
>> per device attributes. This one is global for the entire
>> Z PCI. I just tried with BUS_ATTR_RO instead
>> and that works but only if I put the attribute at
>> /sys/bus/pci/uid_checking instead of with a zpci
>> subfolder. This path would work for us too, we
>> currently don't have any other global attributes
>> that we are planning to expose but those could of
>> course come up in the future.
>
> Ah, I missed the fact that this is a kobj_attribute, not a
> device_attribute. Maybe KERNEL_ATTR_RO()? Very few uses so far, but
> seems like it might fit?
>
> Bjorn
>
KERNEL_ATTR_* is currently not exported in any header. After
adding it to include/linuc/sysfs.h it indeed works perfectly.
Adding Christian Brauner as suggested by get_maintainers for
their opinion. I'm of course willing to provide a patch
for that move should it be desired.
@Bjorn apart from the correct macro do you have a preference
for either suggested path /sys/bus/pci/zpci/uid_checking vs
/sys/bus/pci/uid_checking?
For completeness some further internal discussion lets
us tend to rather name it to "unique_uids" but I guess that
doesn't make a difference to non s390 people ;-)
next prev parent reply other threads:[~2021-01-14 13:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 9:38 [RFC 0/1] PCI: s390 global attribute "UID Checking" Niklas Schnelle
2021-01-11 9:38 ` [RFC 1/1] s390/pci: expose UID checking state in sysfs Niklas Schnelle
2021-01-12 21:50 ` Bjorn Helgaas
2021-01-13 7:47 ` Niklas Schnelle
2021-01-13 18:55 ` Bjorn Helgaas
2021-01-14 13:20 ` Niklas Schnelle [this message]
2021-01-14 13:44 ` Christian Brauner
2021-01-14 13:58 ` Greg Kroah-Hartman
2021-01-14 15:06 ` Niklas Schnelle
2021-01-14 15:17 ` Greg Kroah-Hartman
2021-01-14 15:51 ` Niklas Schnelle
2021-01-14 16:14 ` Greg Kroah-Hartman
2021-01-15 11:20 ` Niklas Schnelle
2021-01-15 12:02 ` Greg Kroah-Hartman
2021-01-15 15:29 ` Bjorn Helgaas
2021-01-15 16:15 ` Niklas Schnelle
2021-01-21 15:31 ` Niklas Schnelle
2021-01-21 15:54 ` Bjorn Helgaas
2021-01-21 16:11 ` Greg Kroah-Hartman
2021-01-21 17:04 ` Niklas Schnelle
2021-01-21 17:28 ` Greg Kroah-Hartman
2021-01-21 17:43 ` Niklas Schnelle
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=675aa466-59ea-cf8a-6eec-caa6478ba4cd@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=christian.brauner@ubuntu.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mihajlov@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=pmorel@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 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.