Using fru-device with 16 Bit EEPROM

[Vijay Khemka]

On 7/18/19, 11:57 PM, "openbmc on behalf of Phil Eichinger" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of phil at zankapfel.net> wrote:

    Hi *,
    
    I was wondering if anyone is using fru-device from entity-manager with
    EEPROMs that have 16 Bit addressing.
    Initially I got an off-by-one error, I dumped the read header bytes and
    they looked like they came from address 0x01.
    I dug in a little deeper and I think there is an issue with the read
    function - read_block_data() - for 16 Bit addressing.
    I haven't verified it on a scope but I think the i2c_smbus API yields an
    I2C transmission for every API call?

We are also seeing this issue with devices which doesn't start at offset 0.
If Drive is setup to different address other than 0 then it is hard to detect if it 
is 16 bit or 8 bit as we can't write to device at the time of enumerations. As there 
is an alternate solution for these kind of devices but not working completely.
    
    My EEPROM (Microchip 24C128) requires for random reads a 2 Byte write
    with the higher address byte first - current implementation has it
    vice-versa and split over 2 transactions.
    From then on I can use the continuous read with auto address increment.
    
    Is the current implementation written for a different EEPROM requiring
    reading this way or is it just broken? In case of the latter I can send
    a patch.
    
    Why is there basically a user space driver for reading/writing EEPROMs
    instead of using the interface in sysfs (ie.
    /sys/devices/platform/ahb/ahb:apb/ahb:apb:bus at 1e78a000/1e78a100.i2c-bus/i2c-3/3-0050/eeprom)?
    
    Cheers,
    
    Phil
    --