linux-kernel - Re: Re: [PATCH] spi: Limit the spi device max speed to controller's max speed

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: <20201210181630.GE4747@sirena.org.uk>
Date:   Thu, 10 Dec 2020 18:16:30 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Tudor.Ambarus@...rochip.com
Cc:     fancer.lancer@...il.com, linux-spi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] spi: Limit the spi device max speed to controller's
 max speed

On Thu, Dec 10, 2020 at 04:32:02PM +0000, Tudor.Ambarus@...rochip.com wrote:
> On 12/10/20 5:33 PM, Mark Brown wrote:

> > It does work for now but it'd be nicer if we were doing this through
> > recording the decision on the transfer.

> Ok, we can drop the patch, as nobody complained about this until now. I can

TBH I've actually got it queued to apply and test, we can make things
better incrementally but it seems fine for now and it's backportable if
someone does run into trouble.

> work on a better approach. Are you saying that we should calibrate/adjust the
> maximum supported frequency on each operation/command? Most of the commands
> can work at the same frequency. I know an exception: on SPI NOR flashes, the

It's the way that everything else works.  It's a bit inefficent though.

> jesd216 standard specifies that the READ SFDP command should be run at 50MHz,
> even though the rest of the commands/opcodes can run at a higher frequency.
> It is common that flashes can run this command at 50+ MHz, and nobody bothered
> about adjusting the frequency at run-time until now. That being said, maybe we
> can calibrate/adjust a generic max frequency for most of the commands and
> treat the exceptions on a per operation basis.

If the spec says 50MHz for that one op we should probably stick to that
by default - the chances of it making a difference seem low but better
to stay in spec if we can.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)