[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200630130031.GH597495@lunn.ch>
Date: Tue, 30 Jun 2020 15:00:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ido Schimmel <idosch@...sch.org>
Cc: vadimp@...lanox.com, Adrian Pop <popadrian1996@...il.com>,
netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
jiri@...lanox.com, mlxsw@...lanox.com,
Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH net-next 1/2] mlxsw: core: Add ethtool support for
QSFP-DD transceivers
> Sounds sane to me... I know that in the past Vadim had to deal with
> various faulty modules. Vadim, is this something we can support? What
> happens if user space requests a page that does not exist? For example,
> in the case of QSFP-DD, lets say we do not provide page 03h but user
> space still wants it because it believes manufacturer did not set
> correct bits.
Hi Ido
I can see two scenarios.
This API is retrofitted to a firmware which only supports pre-defined
linear dumps. A page is requested which is not part of the
dump. EOPNOTSUPP seems like a good response.
The second is for a page which does not exist in the module. I would
just let the i2c bus master perform the transfer. Some might return
EIO, ENODEV if the SFP does not respond. Otherwise it might return
0xff from pullups, or random junk. Hopefully each page as a checksum,
and hopefully the vendor actually get the checksum correct? So let
userspace either deal with the error code, or whatever data is
provided.
The current code already to some extent handles missing data, it uses
the length to determine if the page is present or not. So it is not
too big a change to look error codes for individual pages.
Andrew
Powered by blists - more mailing lists