[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ed7c393b7aa4252a48cd2397ac251eb@AcuMS.aculab.com>
Date: Sat, 17 Jul 2021 13:46:15 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Eddie James' <eajames@...ux.ibm.com>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"broonie@...nel.org" <broonie@...nel.org>,
"openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
"joel@....id.au" <joel@....id.au>
Subject: RE: [PATCH 0/2] spi: fsi: Reduce max transfer size to 8 bytes
From: Eddie James
> Sent: 16 July 2021 14:39
>
> The security restrictions on the FSI-attached SPI controllers have
> been applied universally to all controllers, so the controller can no
> longer transfer more than 8 bytes for one transfer. Refactor the driver
> to remove the looping and support for larger transfers, and remove the
> "restricted" compatible string, as all the controllers are now
> considered restricted.
Aren't there significant performance (and device wear?) penalties
for doing short SPI eeprom writes?
IIRC (and I'm not getting my serial busses confused) a write request
can request an aligned transfer of up to (typically) 32 bytes.
At which point you need to wait for the status to indicate 'complete'.
So restricting writes to 8 bytes increases block write times
by a factor of 4.
Increasing the numbers of writes by a factor or 4 may also have
an effect on device wear - but that is more likely only affected
by erase cycles.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists