All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Eran Ben Elisha <eranbe@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
	Chris Preimesberger <chrisp@transition.com>,
	"linville@tuxdriver.com" <linville@tuxdriver.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
Date: Thu, 27 Sep 2018 16:52:41 +0200	[thread overview]
Message-ID: <20180927145241.GB12979@lunn.ch> (raw)
In-Reply-To: <091551a9-7a85-4112-bbe2-ce7c7d3cf964@mellanox.com>

> Both drivers read up to 256 bytes. 0-127 (from page 0). and 128-256 (from
> page 0). Driver is not capable of reading over 256 bytes currently.

Hi Erin

There should not be any need to read more than 256 bytes. For older
SFP devices, two addresses on the i2c bus are used, each with 256
bytes. For QSFP, one address is used, and you swap page by writing to
offset 127.

> looking on qsfp.c parser in ethtool.c (user space), I see an uninitialized
> bug issue that have caused bug #1 + #2.
> Applied it locally solved the issue (Not showing alarm data, which should be
> expected as driver do not fill it).

There appears to be a second bug somewhere. dumping the module info
using HEX returned 256 bytes. But the binary dump had more bytes.
Since you have the hardware, could you look into this?

Thanks
	Andrew

  reply	other threads:[~2018-09-27 21:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-26 19:29 bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers Chris Preimesberger
2018-09-26 19:44 ` Andrew Lunn
2018-09-26 20:47   ` Chris Preimesberger
2018-09-26 21:46     ` Andrew Lunn
2018-09-26 21:34 ` Neil Horman
2018-09-26 21:58   ` Andrew Lunn
2018-09-27 13:23     ` Neil Horman
2018-09-27 13:25   ` Eran Ben Elisha
2018-09-27 14:52     ` Andrew Lunn [this message]
2018-09-27 15:20       ` Eran Ben Elisha
2018-09-27 15:32         ` Andrew Lunn
2018-09-27 16:08           ` Chris Preimesberger
2018-09-27 16:38             ` Andrew Lunn
2018-09-27 18:56               ` Chris Preimesberger
2018-09-27 20:17                 ` Chris Preimesberger
2018-10-02  7:10           ` Eran Ben Elisha

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=20180927145241.GB12979@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=chrisp@transition.com \
    --cc=eranbe@mellanox.com \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.