[PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes

David Laight David.Laight at ACULAB.COM
Tue Jul 20 23:04:38 AEST 2021

From: Eddie James <eajames at linux.ibm.com>
> Sent: 19 July 2021 16:47
> To: Mark Brown <broonie at kernel.org>
> Cc: devicetree at vger.kernel.org; openbmc at lists.ozlabs.org; robh+dt at kernel.org; linux-
> kernel at vger.kernel.org; linux-spi at vger.kernel.org
> Subject: Re: [PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes
> On Mon, 2021-07-19 at 16:20 +0100, Mark Brown wrote:
> > On Fri, Jul 16, 2021 at 01:34:38PM -0500, Eddie James wrote:
> >
> > > Security changes in the SPI controller - in the device microcode. I
> > > can
> > > reword the commit if you like.
> >
> > How will people end up running this device microcode?  Is this a bug
> > fix, or is this going to needlessly reduce performance for people
> > with
> > existing hardware?
> The hardware is still in development. As part of the development, the
> device microcode was changed to restrict transfers. The reason for this
> restriction was "security concerns". This restriction disallows the
> loop (or branch-if-not-equal-and-increment) sequencer command. It also
> does not allow the read (or shift in if you prefer) command to specify
> the number of bytes in the command itself. Rather, the number of bits
> to shift in must be specified in a separate control register. This
> effectively means that the controller cannot transfer more than 8 bytes
> at a time.
> Therefore I suppose this is effectively a bug fix. There will be no
> hardware available without these restrictions, so it is not a needless
> reduction in performance. Every system that can run this driver will
> run the more restrictive device microcode.

So just say that release versions of the hardware won't support
more than 8 byte transfers.

Having said that, you might want a loop in the driver so that
application requests for longer transfers are implemented
with multiple hardware requests.

I do also wonder why there is support in the main kernel sources
for hardware that doesn't actually exist.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

More information about the openbmc mailing list