openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Eddie James <eajames@linux.ibm.com>
To: Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, openbmc@lists.ozlabs.org,
	robh+dt@kernel.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org
Subject: Re: [PATCH 1/2] spi: fsi: Reduce max transfer size to 8 bytes
Date: Mon, 19 Jul 2021 10:46:33 -0500	[thread overview]
Message-ID: <d2e07f0beda57ffeaa31e8cf5bf28edfbd982e58.camel@linux.ibm.com> (raw)
In-Reply-To: <20210719152010.GB4174@sirena.org.uk>

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.

Thanks,
Eddie



  reply	other threads:[~2021-07-19 15:47 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 [this message]
2021-07-20 13:04           ` David Laight
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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d2e07f0beda57ffeaa31e8cf5bf28edfbd982e58.camel@linux.ibm.com \
    --to=eajames@linux.ibm.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).