linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: linux-pci@vger.kernel.org, "Martin Mareš" <mj@ucw.cz>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	jcm@redhat.com, nariman.poushin@linaro.org, linuxarm@huawei.com
Subject: Re: [RFC PATCH 0/2] lspci: support for CCIX DVSEC
Date: Tue, 2 Jul 2019 16:28:29 -0500	[thread overview]
Message-ID: <20190702212829.GE128603@google.com> (raw)
In-Reply-To: <20190627144355.27913-1-Jonathan.Cameron@huawei.com>

On Thu, Jun 27, 2019 at 10:43:53PM +0800, Jonathan Cameron wrote:
> This series adds support for near complete interpretation of CCIX DVSEC.
> Most of the CCIX base 1.0 specification is covered, but a few minor
> elements are not currently printed (some of the timeouts and credit
> types). That can be rectified in a future version or follow up patch
> and isn't necessary for this discussion.
> 
> CCIX (www.ccixconsortium.org) is a coherent interconnect specification.
> It is flexible in allowed interconnect topologies, but is overlayed
> on top of a traditional PCIe tree.  Note that CCIX physical devices
> may turn up in a number of different locations in the PCIe tree.
> 
> The topology configuration and physical layer controls and description
> are presented using PCIe DVSEC structures defined in the CCIX 1.0
> base specification.  These use the unique ID granted by the PCISIG.
> Note that, whilst it looks like a Vendor ID for this usecase it is
> not one and can only be used to identify DVSEC and related CCIX protocol
> messages.
> 
> So why an RFC?
> * Are the lspci maintainers happy to have the tool include support for
>   PCI configuration structures that are defined in other standards?
> * Is the general approach and code structure appropriate?
> * It's a lot of description so chances are some of it isn't in a format
>   consistent with the rest of lspci!
> 
> The patch set includes and example that was manually created to exercise
> much of the parser.  We also have qemu patches to emulate more complex
> topologies if anyone wants to experiment.
> 
> https://patchwork.kernel.org/cover/11015357/
> 
> Example output from lspci -t -F ccix-specex1 -s 03:00.0
> 
> 03:00.0 Class 0700: Device 19ec:0003 (prog-if 01)
> ...

> 	Capabilities: [600 v0] Designated Vendor-Specific <>
> 		Vendor:1e2c Version:0
> 		<CCIX Transport 600>
> 			TranCap:	ESM+ SR/LR RecalOnrC- CalTime: 500us QuickEqTime: 200ms/208ms
> 			ESMRateCap:	2.5 GT/s 5 GT/s 8 GT/s 16 GT/s 20 GT/s 25 GT/s 
> 			ESMStatus:	25 GT/s Cal+
> 			ESMCtl:		ESM0: 16 GT/s ESM1: 25 GT/s ESM+ ESMCompliance- LR
> 					ExtEqPhase2TimeOut: 400 ms / 408 ms  ExtEqPhase3TimeOut: 600 ms / 608 ms 
> 					QuickEqTimeout: Unknown
> 			ESMEqCtl 20GT/s:	Lane #00: Trans Presets US: 0x1 DS: 0x2

It's a minor annoyance that all these lines are longer than 80 columns.  I
know there are existing things in lspci that are wider, which are also
slightly annoying.  But you're adding a TON of them and there's a bunch of
whitespace at the beginning of each line :)

> The following grants the 'pciutils' project trademark usage of
> CCIX tradmark where relevant.
> 
> This patch is being distributed by the CCIX Consortium, Inc. (CCIX) to
> you and other parties that are paticipating (the "participants") in the
> pciutils with the understanding that the participants will use CCIX's
> name and trademark only when this patch is used in association with the
> pciutils project.
> 
> CCIX is also distributing this patch to these participants with the
> understanding that if any portion of the CCIX specification will be
> used or referenced in the pciutils project, the participants will not modify
> the cited portion of the CCIX specification and will give CCIX propery
> copyright attribution by including the following copyright notice with
> the cited part of the CCIX specification:
> "© 2019 CCIX CONSORTIUM, INC. ALL RIGHTS RESERVED."

s/tradmark/trademark/
s/paticipating/participating/
s/propery/proper/

I guess "will not modify the cited portion" just means people will
quote it accurately?  It seems obvious that people proposing changes
to pciutils can't really modify the CCIX spec.

The above all sounds a little onerous and I doubt I would sign up to
it because I'd be afraid to mention "CCIX" in an email and I'm pretty
sure I'd forget to add the copyright notice somewhere.  But
fortunately that's up to Martin, not me.

> Jonathan Cameron (2):
>   CCIX DVSEC initial support
>   DVSEC Add an example from the ccix spec.

s/ccix/CCIX/ so they match.  No period necessary in subject line.

I don't maintain pciutils, but I like to have subject lines match in
grammatical style.  One of the above is a sentence and the other is not.
Maybe:

  Add CCIX DVSEC decoding support
  Add DVSEC example from CCIX spec

Bjorn

  parent reply	other threads:[~2019-07-03  1:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 14:43 [RFC PATCH 0/2] lspci: support for CCIX DVSEC Jonathan Cameron
2019-06-27 14:43 ` [RFC PATCH 1/2] lspci: CCIX DVSEC initial support Jonathan Cameron
2020-01-22  9:48   ` Martin Mareš
2019-06-27 14:43 ` [RFC PATCH 2/2] lspci: DVSEC Add an example from the ccix spec Jonathan Cameron
2019-07-02 21:28 ` Bjorn Helgaas [this message]
2019-07-03  7:18   ` [RFC PATCH 0/2] lspci: support for CCIX DVSEC Jonathan Cameron
2019-08-06 11:16 ` Jonathan Cameron
2020-01-22  9:42 ` Martin Mareš
2020-01-27 11:48   ` Jonathan Cameron

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=20190702212829.GE128603@google.com \
    --to=helgaas@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=jcm@redhat.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mj@ucw.cz \
    --cc=nariman.poushin@linaro.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 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).