linux-kernel - Re: Asymmetric regmap read/write reg

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] [day] [month] [year] [list]

Message-ID: <20220311192730.GA265@COLIN-DESKTOP1.localdomain>
Date:   Fri, 11 Mar 2022 11:27:30 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Asymmetric regmap read/write reg

On Fri, Mar 11, 2022 at 01:26:29PM +0000, Mark Brown wrote:
> On Thu, Mar 10, 2022 at 01:54:08PM -0800, Colin Foster wrote:
> 
> > The Ocelot chip has requires 100ns between address write and when the
> > address is ready to be clocked out. This can be dealt with in three
> > different ways:
> > 1. Use a slow enough clock speed
> > 2. Use a delay between address write and value read
> > 3. Clock out N padding bytes to account for the 100ns access time
> > 
> > Forcing a slow clock speed is obviously not ideal, and forcing a delay
> > between "write_then_read" sounds too driver-specific, so option 3 seems
> > like the best option - especially if bulk reads are utilized.
> > 
> > Where regmap comes in is specifically the padding bytes. Reads require
> 
> Why not implement this using a delay?  That seems both more
> straightforward and likely tending to be more accurate given that clock
> rates for SPI devices tend to be a bit vague.  Much less disruptive to
> implement too.

Hi Mark,

Thanks, that's a good idea. I'll reconsider that strategy, especially
since I now have a better understanding of the SPI <> Regmap <> bus
interactions.

Much appreciated!