From: Greg KH <gregkh@linuxfoundation.org>
To: Alistair Francis <alistair23@gmail.com>
Cc: Damien Le Moal <dlemoal@kernel.org>,
bhelgaas@google.com, linux-pci@vger.kernel.org,
Jonathan.Cameron@huawei.com, lukas@wunner.de,
alex.williamson@redhat.com, christian.koenig@amd.com,
kch@nvidia.com, logang@deltatee.com,
linux-kernel@vger.kernel.org, chaitanyak@nvidia.com,
rdunlap@infradead.org,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH v4] PCI/DOE: Expose the DOE protocols via sysfs
Date: Fri, 11 Aug 2023 21:47:47 +0200 [thread overview]
Message-ID: <2023081101-snore-shawl-8bbb@gregkh> (raw)
In-Reply-To: <CAKmqyKOpgTUOzPMhe3Dr1H6BiFZYHrBHFpiESyXitRHbdH0+LA@mail.gmail.com>
On Fri, Aug 11, 2023 at 02:40:45PM -0400, Alistair Francis wrote:
> On Thu, Aug 10, 2023 at 9:04 PM Damien Le Moal <dlemoal@kernel.org> wrote:
> >
> > On 8/11/23 01:33, Alistair Francis wrote:
> > > The PCIe 6 specification added support for the Data Object Exchange (DOE).
> > > When DOE is supported the Discovery Data Object Protocol must be
> > > implemented. The protocol allows a requester to obtain information about
> > > the other DOE protocols supported by the device.
> > >
> > > The kernel is already querying the DOE protocols supported and cacheing
> > > the values. This patch exposes the values via sysfs. This will allow
> > > userspace to determine which DOE protocols are supported by the PCIe
> > > device.
> > >
> > > By exposing the information to userspace tools like lspci can relay the
> > > information to users. By listing all of the supported protocols we can
> > > allow userspace to parse and support the list, which might include
> > > vendor specific protocols as well as yet to be supported protocols.
> > >
> > > Each DOE feature is exposed as a single file. The files are empty and
> > > the information is contained in the file name.
> >
> > s/feature/protocol ?
>
> Fixed
>
> >
> > Personally, I would still have each file content repeat the same information as
> > the file name specifies. That is, file value == file name. That will avoid
> > people getting confused as empty sysfs files are rather uncommon.
>
> I don't see an obvious way to implement that with the .show()
> function. I don't see a clear way to know what file the user accessed.
The show callback gets a pointer to the attribute it was called with, so
you know the file that was opened and can figure it out from there as to
what it should print out.
I think right now it returns an error, right? That's not good as
userspace is going to think "this attribute really isn't there if I
can't read from it" as that is how all other sysfs files work.
thanks,
greg k-h
next prev parent reply other threads:[~2023-08-11 19:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 16:33 [PATCH v4] PCI/DOE: Expose the DOE protocols via sysfs Alistair Francis
2023-08-11 1:03 ` Damien Le Moal
2023-08-11 18:40 ` Alistair Francis
2023-08-11 19:47 ` Greg KH [this message]
2023-08-12 8:05 ` Lukas Wunner
2023-08-12 8:31 ` Lukas Wunner
2023-08-12 8:21 ` Lukas Wunner
2023-08-15 18:36 ` Alistair Francis
2023-08-23 12:10 ` Jonathan Cameron
2023-08-11 5:21 ` Chaitanya Kulkarni
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=2023081101-snore-shawl-8bbb@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=bhelgaas@google.com \
--cc=chaitanyak@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=dlemoal@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=lukas@wunner.de \
--cc=rdunlap@infradead.org \
/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.