public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Martin Mareš" <mj@ucw.cz>
Cc: <linux-pci@vger.kernel.org>, <bhelgaas@google.com>,
	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: Mon, 27 Jan 2020 11:48:50 +0000	[thread overview]
Message-ID: <20200127114850.00002978@Huawei.com> (raw)
In-Reply-To: <mj+md-20200122.092951.48097.albireo@ucw.cz>

On Wed, 22 Jan 2020 10:42:21 +0100
Martin Mareš <mj@ucw.cz> wrote:

> Hello!
> 
> > 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!  
> 
> I am very happy to include parsers of vendor-specific capabilities.

Great.

> 
> The general approach is fine, but please bring the source code closer
> to the coding style of the rest of pciutils.

Will do - though may take me a while to get back to this one.

> 
> > 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.  
> 
> I suspect that this is not compatible with the GPL. Everybody is allowed
> to use portions of pciutils in other GPLed projects. So the trademark usage
> right should be granted to use in the contributed code, regardless of whether
> it is currently in the pciutils project, or any other project.

I'll keep clear of the interesting legal argument around that one.
Good news is that the CCIX consortium has agreed to more standard statement
on trademark ownership only.  No right limitations in the new version, just
statements of fact.

As I understand it, using the CCIX to mean CCIX is never a trademark violation
anyway, it's only when composites are created from it that we might run into
issues.  That's true whatever the text here says and is equally true of PCI for
example if they should ever decide to enforce their trademarks.

> 
> > 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."  
> 
> Are there any citations affected by this in your patch? You only refer to data
> structures defined by the specification, but this is factual information which
> cannot be copyrighted (but IANAL).

I never got a clear answer on this from our legal (was exploring other
alternatives if we couldn't get the CCIX consortium requirements relaxed).
My understanding was the same as yours, but it became unnecessary with
confirmation that the CCIX consortium legal had relaxed their requirements
anyway.

> 
> I am strongly opposed to adding more copyright notices to the pciutils
> besides the GPL.
> 
> 				Have a nice fortnight

I'll fix the legal stuff in the next version. We got that changed after
push back from various other bits of the open source community.  Just took
a while due to some other complexities that I won't go into but you might
be able to guess given who I work for ;)

Was very helpful indeed to get feedback of the form you've given as it
forced the issue nicely.  I should have posted a note to this thread to
say that was changing, sorry for wasting your time.

Thanks!

Jonathan




      reply	other threads:[~2020-01-27 11:48 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 ` [RFC PATCH 0/2] lspci: support for CCIX DVSEC Bjorn Helgaas
2019-07-03  7:18   ` Jonathan Cameron
2019-08-06 11:16 ` Jonathan Cameron
2020-01-22  9:42 ` Martin Mareš
2020-01-27 11:48   ` Jonathan Cameron [this message]

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=20200127114850.00002978@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=bhelgaas@google.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