lkml.org 
[lkml]   [2021]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 1/3] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips
    On Thursday 07 January 2021 17:40:06 Russell King - ARM Linux admin wrote:
    > 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.

    Do you have an idea where to put a comment?

    \
     
     \ /
      Last update: 2021-01-07 20:21    [W:4.422 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site