linux-kernel - Re: [PATCH] eeprom: at25: set minimum read/write access stride to 1

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: <2225645.EMaFvj1lSc@n95hx1g2>
Date:   Tue, 28 Jul 2020 12:30:13 +0200
From:   Christian Eggers <ceggers@...i.de>
To:     David Laight <David.Laight@...lab.com>
CC:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] eeprom: at25: set minimum read/write access stride to 1

On Tuesday, 28 July 2020, 11:52:05 CEST, David Laight wrote:
> From: Christian Eggers
> 
> > Sent: 28 July 2020 10:30
> > 
> > SPI eeproms are addressed by byte.
> 
> They also support multi-byte writes - possibly with alignment
> restrictions.
> So forcing 4-byte writes (at aligned addresses) would typically
> speed up writes by a factor of 4 over byte writes.
> 
> So does this fix a problem?
> If so what.
I use the nvmem-cells property for getting the MAC-Address out of the eeprom 
(actually an FRAM in my case).

&spi {
    ....
    fram: fram@0 {
    ...
        mac_address_fec2: mac-address@126 {
            reg = <0x126 6>;
        };
    ...
    };
};

&fec2 {
    ...
    nvmem-cells = <&mac_address_fec2>;
    nvmem-cell-names = "mac-address";
    ...
};

As the address of the MAC is not aligned to 4 bytes,
reading the MAC from FRAM fails.

> So setting the 'stride' to 4 may be a compromise.
> Looking at some code that writes the EPCQ for Altera FPGA
> (which I think is just SPI) it does aligned 256 byte writes.
> The long writes (and the 4-bit physical interface) are needed
> to get the write times down to a sensible value.
I do not understand why a minimum read/write stride of 1 would affect 
performance. It is fully up to the user of the eeprom, how much data is read/
written at once. Of course it would not be economical only to read/write one 
byte at a time.

For reading data, there should be no difference whether the access is aligned 
to a particular address. For writing, data is usually organized in "write 
pages". For (I2C) eeproms I've used, the write page size is typically 32 
bytes. But his is handled separately by the "pagesize" property.

Is there any benefit at all if the stride size is set > 1?


> 
> 	David
> 
regards
Christian