netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Machata <petrm@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Danielle Ratson <danieller@nvidia.com>, <netdev@vger.kernel.org>,
	<mkubecek@suse.cz>, <matt@traverse.com.au>,
	<daniel.zahka@gmail.com>, <amcohen@nvidia.com>,
	<nbu-mlxsw@exchange.nvidia.com>
Subject: Re: [PATCH ethtool-next v3 10/16] qsfp: Add JSON output handling to --module-info in SFF8636 modules
Date: Wed, 5 Feb 2025 12:32:49 +0100	[thread overview]
Message-ID: <871pwcoc43.fsf@nvidia.com> (raw)
In-Reply-To: <20250204183713.5cf64e08@kernel.org>


Jakub Kicinski <kuba@kernel.org> writes:

> I think the description fields need to either be concatenated, or an
> array.

Yep.

https://www.rfc-editor.org/rfc/rfc8259#section-4 :

   The names within an object SHOULD be unique.

   An object whose names are all unique is interoperable in the sense
   that all software implementations receiving that object will agree on
   the name-value mappings.  When the names within an object are not
   unique, the behavior of software that receives such an object is
   unpredictable.  Many implementations report the last name/value pair
   only.  Other implementations report an error or fail to parse the
   object, and some implementations report all of the name/value pairs,
   including duplicates.

  reply	other threads:[~2025-02-05 11:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-04 13:39 [PATCH ethtool-next v3 00/16] Add JSON output to --module-info Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 01/16] module_common: Add a new file to all the common code for all module types Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 02/16] ethtool: Standardize Link Length field names across " Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 03/16] sff_common: Move sff_show_revision_compliance() to qsfp.c Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 04/16] cmis: Change loop order in cmis_show_dom_chan_lvl_flags() Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 05/16] qsfp: Reorder the channel-level flags list for SFF8636 module type Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 06/16] qsfp: Refactor sff8636_show_dom() by moving code into separate functions Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 07/16] module_common: Add helpers to support JSON printing for common value types Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 08/16] cmis: Add JSON output handling to --module-info in CMIS modules Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 09/16] cmis: Enable JSON output support " Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 10/16] qsfp: Add JSON output handling to --module-info in SFF8636 modules Danielle Ratson
2025-02-05  2:34   ` Jakub Kicinski
2025-02-05  7:45     ` Danielle Ratson
2025-02-05 10:48     ` Vadim Fedorenko
2025-02-05 12:13       ` Danielle Ratson
2025-02-05 12:20         ` Vadim Fedorenko
2025-02-05 12:25           ` Danielle Ratson
2025-02-05  2:37   ` Jakub Kicinski
2025-02-05 11:32     ` Petr Machata [this message]
2025-02-05 11:41       ` Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 11/16] qsfp: Enable JSON output support for " Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 12/16] sfpid: Add JSON output handling to --module-info in SFF8079 modules Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 13/16] sfpdiag: Add JSON output handling to --module-info in SFF8472 modules Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 14/16] ethtool: Enable JSON output support for SFF8079 and " Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 15/16] module_info: Add a new JSON file for units documentation Danielle Ratson
2025-02-04 13:39 ` [PATCH ethtool-next v3 16/16] ethtool: Add '-j' support to ethtool Danielle Ratson

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=871pwcoc43.fsf@nvidia.com \
    --to=petrm@nvidia.com \
    --cc=amcohen@nvidia.com \
    --cc=daniel.zahka@gmail.com \
    --cc=danieller@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=matt@traverse.com.au \
    --cc=mkubecek@suse.cz \
    --cc=nbu-mlxsw@exchange.nvidia.com \
    --cc=netdev@vger.kernel.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).