netdev - Re: [PATCH net-next 0/7] net: sfp: improve high power module implementation

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y1K94ImMTITNaYE/@lunn.ch>
Date:   Fri, 21 Oct 2022 17:42:24 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, devicetree@...r.kernel.org,
        Eric Dumazet <edumazet@...gle.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH net-next 0/7] net: sfp: improve high power module
 implementation

On Wed, Oct 19, 2022 at 02:28:20PM +0100, Russell King (Oracle) wrote:
> Hi,
> 
> This series aims to improve the power level switching between standard
> level 1 and the higher power levels.
> 
> The first patch updates the DT binding documentation to include the
> minimum and default of 1W, which is the base level that every SFP cage
> must support. Hence, it makes sense to document this in the binding.
> 
> The second patch enforces a minimum of 1W when parsing the firmware
> description, and optimises the code for that case; there's no need to
> check for SFF8472 compliance since we will not need to touch the
> A2h registers.
> 
> Patch 3 validates that the module supports SFF-8472 rev 10.2 before
> checking for power level 2 - rev 10.2 is where support for power
> levels was introduced, so if the module doesn't support this revision,
> it doesn't support power levels. Setting the power level 2 declaration
> bit is likely to be spurious.

Or it is yet another case of violating the standard. The bit is valid,
the revision is wrong in the EEPROM. How long do you think it will be
before we see a quirk like this?

> Patch 4 does the same for power level 3, except this was introduced in
> SFF-8472 rev 11.9. The revision code was never updated, so we use the
> rev 11.4 to signify this.

Great, the standard itself is broken.

       Andrew