From: Ido Schimmel <idosch@idosch.org>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: netdev@vger.kernel.org, vadimp@nvidia.com, moshe@nvidia.com,
popadrian1996@gmail.com, mlxsw@nvidia.com,
Ido Schimmel <idosch@nvidia.com>
Subject: Re: [PATCH ethtool-next 1/7] cmis: Fix CLEI code parsing
Date: Thu, 30 Sep 2021 23:41:02 +0300 [thread overview]
Message-ID: <YVYg3rBB1/a2dlxw@shredder> (raw)
In-Reply-To: <20210930202133.rspuswnnbnnhlgeb@lion.mk-sys.cz>
On Thu, Sep 30, 2021 at 10:21:33PM +0200, Michal Kubecek wrote:
> On Fri, Sep 17, 2021 at 05:40:37PM +0300, Ido Schimmel wrote:
> > From: Ido Schimmel <idosch@nvidia.com>
> >
> > In CMIS, unlike SFF-8636, there is no presence indication for the CLEI
> > code (Common Language Equipment Identification) field. The field is
> > always present, but might not be supported. In which case, "a value of
> > all ASCII 20h (spaces) shall be entered".
> >
> > Therefore, remove the erroneous check which seems to be influenced from
> > SFF-8636 and only print the string if it is supported and has a non-zero
> > length.
> >
> > Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> > ---
> > cmis.c | 8 +++++---
> > cmis.h | 3 +--
> > 2 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/cmis.c b/cmis.c
> > index 1a91e798e4b8..2a48c1a1d56a 100644
> > --- a/cmis.c
> > +++ b/cmis.c
> > @@ -307,6 +307,8 @@ static void cmis_show_link_len(const __u8 *id)
> > */
> > static void cmis_show_vendor_info(const __u8 *id)
> > {
> > + const char *clei = (const char *)(id + CMIS_CLEI_START_OFFSET);
> > +
> > sff_show_ascii(id, CMIS_VENDOR_NAME_START_OFFSET,
> > CMIS_VENDOR_NAME_END_OFFSET, "Vendor name");
> > cmis_show_oui(id);
> > @@ -319,9 +321,9 @@ static void cmis_show_vendor_info(const __u8 *id)
> > sff_show_ascii(id, CMIS_DATE_YEAR_OFFSET,
> > CMIS_DATE_VENDOR_LOT_OFFSET + 1, "Date code");
> >
> > - if (id[CMIS_CLEI_PRESENT_BYTE] & CMIS_CLEI_PRESENT_MASK)
> > - sff_show_ascii(id, CMIS_CLEI_START_OFFSET,
> > - CMIS_CLEI_END_OFFSET, "CLEI code");
> > + if (strlen(clei) && strcmp(clei, CMIS_CLEI_BLANK))
> > + sff_show_ascii(id, CMIS_CLEI_START_OFFSET, CMIS_CLEI_END_OFFSET,
> > + "CLEI code");
> > }
> >
> > void qsfp_dd_show_all(const __u8 *id)
>
> Is it safe to assume that the string will be always null terminated?
No. You want to see strnlen() and strncmp() instead?
> Looking at the code below, CMIS_CLEI_BLANK consists of 10 spaces which
> would fill the whole block at offsets 0xBE through 0xC7 with spaces and
> offset 0xC8 is used as CMIS_PWR_CLASS_OFFSET. Also, sff_show_ascii()
> doesn't seem to expect a null terminated string, rather a space padded
> one.
>
> Michal
>
>
> > diff --git a/cmis.h b/cmis.h
> > index 78ee1495bc33..d365252baa48 100644
> > --- a/cmis.h
> > +++ b/cmis.h
> > @@ -34,10 +34,9 @@
> > #define CMIS_DATE_VENDOR_LOT_OFFSET 0xBC
> >
> > /* CLEI Code (Page 0) */
> > -#define CMIS_CLEI_PRESENT_BYTE 0x02
> > -#define CMIS_CLEI_PRESENT_MASK 0x20
> > #define CMIS_CLEI_START_OFFSET 0xBE
> > #define CMIS_CLEI_END_OFFSET 0xC7
> > +#define CMIS_CLEI_BLANK " "
> >
> > /* Cable assembly length */
> > #define CMIS_CBL_ASM_LEN_OFFSET 0xCA
> > --
> > 2.31.1
> >
next prev parent reply other threads:[~2021-09-30 20:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 14:40 [PATCH ethtool-next 0/7] ethtool: Small EEPROM changes Ido Schimmel
2021-09-17 14:40 ` [PATCH ethtool-next 1/7] cmis: Fix CLEI code parsing Ido Schimmel
2021-09-30 20:21 ` Michal Kubecek
2021-09-30 20:41 ` Ido Schimmel [this message]
2021-09-30 21:12 ` Michal Kubecek
2021-09-17 14:40 ` [PATCH ethtool-next 2/7] cmis: Fix wrong define name Ido Schimmel
2021-09-17 14:40 ` [PATCH ethtool-next 3/7] cmis: Correct comment Ido Schimmel
2021-09-17 14:40 ` [PATCH ethtool-next 4/7] sff-8636: Remove incorrect comment Ido Schimmel
2021-09-17 14:40 ` [PATCH ethtool-next 5/7] sff-8636: Fix incorrect function name Ido Schimmel
2021-09-17 14:40 ` [PATCH ethtool-next 6/7] sff-8636: Convert if statement to switch-case Ido Schimmel
2021-09-17 14:40 ` [PATCH ethtool-next 7/7] sff-8636: Remove extra blank lines Ido Schimmel
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=YVYg3rBB1/a2dlxw@shredder \
--to=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=mkubecek@suse.cz \
--cc=mlxsw@nvidia.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=popadrian1996@gmail.com \
--cc=vadimp@nvidia.com \
/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).