linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexey Kardashevskiy <aik@amd.com>
Cc: Lukas Wunner <lukas@wunner.de>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH kernel v2] pci/doe: Support discovery version
Date: Tue, 5 Mar 2024 14:32:31 -0600	[thread overview]
Message-ID: <20240305203231.GA538524@bhelgaas> (raw)
In-Reply-To: <089cddf1-3686-4403-a480-07fddd66ab4b@amd.com>

On Tue, Mar 05, 2024 at 05:02:27PM +1100, Alexey Kardashevskiy wrote:
> On 28/2/24 07:41, Lukas Wunner wrote:
> > On Mon, Feb 26, 2024 at 02:31:14PM +1100, Alexey Kardashevskiy wrote:
> > > Does PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER need to be in pci-regs.h?
> > 
> > Yes that's fine.
> > 
> > > --- a/include/uapi/linux/pci_regs.h
> > > +++ b/include/uapi/linux/pci_regs.h
> > > @@ -1144,6 +1144,7 @@
> > >   #define PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH		0x0003ffff
> > >   #define PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX		0x000000ff
> > > +#define PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER	0x0000ff00
> > >   #define PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID		0x0000ffff
> > >   #define PCI_DOE_DATA_OBJECT_DISC_RSP_3_PROTOCOL		0x00ff0000
> > >   #define PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX	0xff000000
> > 
> > "DISCOVER" duplicates the preceding "DISC", maybe just
> > "PCI_DOE_DATA_OBJECT_DISC_REQ_3_VERSION" for simplicity?
> 
> Well, mostly because the PCIe spec specifically says "discovery" in the
> field description, not just "version", but ok, I'll drop it.
> 
> btw "DISC" is just confusing, it has nothing to do with discs. _PROTOCOL is
> not even correct anymore, now, in PCIe r6.1 it is called "type", lovely :)
> s/PCI_DOE_DATA_OBJECT_DISC_/PCI_DOE_DISCOVERY_/ (because DO==DATA_OBJECT)
> imho would do better but may be some other day.

Agreed, and there are only a couple uses so not hard to change,
although it is already in uapi/.  Maybe nobody really uses it yet
though?

> Less ugly since we want to keep it 80 chars long (do we, still?). Like this
> looks meh:
> 
>         u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
>                                     *index) |
> FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER,
>                                     (capver >= 2) ? 2 : 0);
> 
>         __le32 request_pl_le = cpu_to_le32(request_pl);
> 
> If we did 100 chars, I could do:
> 
>         u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
> *index) |
>                          FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_VER,
> (capver >= 2) ? 2 : 0);
>         __le32 request_pl_le = cpu_to_le32(request_pl);

Personally I prefer 80 columns because all the rest of drivers/pci is
that, and it's a hassle when browsing to have to resize the window to
either accommodate wider lines or avoid wasting screen space when all
the lines are shorter.

But there are exceptions.  Strings don't need to be broken because
grepping for error messages works better when they're continued.  This
situation might be an exception, too.  We don't need to slavishly
adhere to 80 if the result looks terrible.

Bjorn

  reply	other threads:[~2024-03-05 20:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26  3:31 [PATCH kernel v2] pci/doe: Support discovery version Alexey Kardashevskiy
2024-02-27  0:51 ` Dan Williams
2024-02-27 20:41 ` Lukas Wunner
2024-03-05  6:02   ` Alexey Kardashevskiy
2024-03-05 20:32     ` Bjorn Helgaas [this message]
2024-03-06  8:37     ` Lukas Wunner

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=20240305203231.GA538524@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=aik@amd.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    /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;
as well as URLs for NNTP newsgroup(s).