netdev - Re: [PATCH net-next 2/2] net/mlx5e: Add DSFP EEPROM dump support to ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7575def5-2ff3-75db-019a-9f4456375492@nvidia.com>
Date:   Mon, 16 Nov 2020 12:11:40 +0200
From:   Moshe Shemesh <moshe@...dia.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Moshe Shemesh <moshe@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Adrian Pop <pop.adrian61@...il.com>,
        Michal Kubecek <mkubecek@...e.cz>, <netdev@...r.kernel.org>,
        Vladyslav Tarasiuk <vladyslavt@...dia.com>
Subject: Re: [PATCH net-next 2/2] net/mlx5e: Add DSFP EEPROM dump support to
 ethtool


On 11/13/2020 2:44 AM, Andrew Lunn wrote:
> On Thu, Nov 12, 2020 at 05:54:51PM +0200, Moshe Shemesh wrote:
>> On 11/12/2020 3:13 PM, Andrew Lunn wrote:
>>> On Thu, Nov 12, 2020 at 07:49:41AM +0200, Moshe Shemesh wrote:
>>>> From: Vladyslav Tarasiuk <vladyslavt@...dia.com>
>>>>
>>>> DSFP is a new cable module type, which EEPROM uses memory layout
>>>> described in CMIS 4.0 document. Use corresponding standard value for
>>>> userspace ethtool to distinguish DSFP's layout from older standards.
>>>>
>>>> Add DSFP module ID in accordance to SFF-8024.
>>>>
>>>> DSFP module memory can be flat or paged, which is indicated by a
>>>> flat_mem bit. In first case, only page 00 is available, and in second -
>>>> multiple pages: 00h, 01h, 02h, 10h and 11h.
>>> You are simplifying quite a bit here, listing just these pages. When i
>>> see figure 8-1, CMIS Module Memory Map, i see many more pages, and
>>> banks of pages.
>>
>> Right, but as I understand these are the basic 5 pages which are mandatory.
>> Supporting more than that we will need new API.
> Humm, actually, looking at the diagram again, pages 10h and 11h are
> banked. Is one bamk sufficient? If so, you need to document that bank
> zero is always returned, and make sure your firmware is doing that.
>
> We also need to be clear that tunable laser information is not
> available, due to this fixed layout.


Pages 10h and 11h are banked, but the mandatory data for active 
transceivers is in bank 0. I will document it in the commit. There are 
more banked pages, but they are all optional. Also pages 03h and 04h are 
optional. I am looking to support here the mandatory part. For 
supporting the optional pages we will need to change API.

>       Andrew