From: David Laight <David.Laight@ACULAB.COM>
To: 'Eddie James' <firstname.lastname@example.org>, Mark Brown <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
Subject: RE: [PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes
Date: Tue, 20 Jul 2021 13:04:38 +0000 [thread overview]
Message-ID: <0a637d7704df4303abe783215080578d@AcuMS.aculab.com> (raw)
From: Eddie James <firstname.lastname@example.org>
> Sent: 19 July 2021 16:47
> To: Mark Brown <email@example.com>
> Cc: firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; linux-
> email@example.com; firstname.lastname@example.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)
next prev parent reply other threads:[~2021-07-20 13:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-16 13:39 [PATCH 0/2] spi: fsi: Reduce max transfer size to 8 bytes Eddie James
2021-07-16 13:39 ` [PATCH 1/2] " Eddie James
2021-07-16 17:19 ` Mark Brown
2021-07-16 18:34 ` Eddie James
2021-07-19 15:20 ` Mark Brown
2021-07-19 15:46 ` Eddie James
2021-07-20 13:04 ` David Laight [this message]
2021-07-20 13:13 ` Mark Brown
2021-07-20 17:32 ` David Laight
2021-07-16 13:39 ` [PATCH 2/2] dt-bindings: fsi: Remove ibm, fsi2spi-restricted compatible Eddie James
2021-07-19 15:54 ` [PATCH 2/2] dt-bindings: fsi: Remove ibm,fsi2spi-restricted compatible Mark Brown
2021-07-17 13:46 ` [PATCH 0/2] spi: fsi: Reduce max transfer size to 8 bytes David Laight
2021-07-19 15:57 ` Eddie James
2021-07-19 18:00 ` Mark Brown
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).