linux-kernel - Re: [PATCH v2 1/3] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

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: <20210107174006.GQ1551@shell.armlinux.org.uk>
Date:   Thu, 7 Jan 2021 17:40:06 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Pali Rohár <pali@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Thomas Schreiber <tschreibe@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Marek Behún <kabel@...nel.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] net: sfp: add workaround for Realtek RTL8672 and
 RTL9601C chips

On Thu, Jan 07, 2021 at 06:19:23PM +0100, Andrew Lunn wrote:
> Did we loose the comment:
> 
> /* Some modules (Nokia 3FE46541AA) lock up if byte 0x51 is read as a
>  * single read. Switch back to reading 16 byte blocks ...
> 
> That explains why 16 is used. Given how broken stuff is and the number
> of workaround we need, we should try to document as much as we cam, so
> we don't break stuff when adding more workarounds.

It is _not_ why 16 is used at all.

We used to read the whole lot in one go. However, some modules could
not cope with a full read - also some Linux I2C drivers struggled with
it.

So, we reduced it down to 16 bytes. See commit 28e74a7cfd64 ("net: sfp:
read eeprom in maximum 16 byte increments"). That had nothing to do
with the 3FE46541AA, which came along later. It has been discovered
that 3FE46541AA reacts badly to a single byte read to address 0x51 -
it locks the I2C bus. Hence why we can't just go to single byte reads
for every module.

So, the comment needs to be kept to explain why we are unable to go
to single byte reads for all modules.  The choice of 16 remains
relatively arbitary.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!