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

Message-ID: <20220310215408.GA3149079@euler>
Date:   Thu, 10 Mar 2022 13:54:08 -0800
From:   Colin Foster <colin.foster@...advantage.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Asymmetric regmap read/write reg

Hi Mark, Regmap Abstraction realm,

I'm writing the driver for Ocelot chips over SPI. My latest RFC can be
found here, specifically the patch that utilzes regmap.

https://patchwork.kernel.org/project/netdevbpf/patch/20220307021208.2406741-11-colin.foster@in-advantage.com/

There's an interesting issue that comes about that isn't currently
supported by regmap - specifically in bus read / write operations.

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
the padding bytes, and writes don't. So this brings in new requirements
where a specific map->format.format_write would actually become
map->format_tx.format_write and map->format_rx.format_write. Several
other parameters (format_reg, work_buf) would also be affected.

In other words: 32-bit register writes could be
| A  | A  | A  | V1 | V2 | V3 | V4 |
while reads could be:
| A  | A  | A  | P  | P  | V1 | V2 | V3 | V4 |
and sequential R/W operations wouldn't require padding.

So my questions:
Is this a valid use-case (extension) of the regmap bus? And something
that might want to be supported?
Has this type of work been considered previously?

My other options are to fall back to a slower clock speed and try to
use regmap-spi bus as-is. The addresses get down-shifted by two, so
there's a smaller complication there. But this should allow for async
writes, which I came across when trying to apply a heartbeat trigger to
an attached GPIO LED.

Or I can continue with my current implementation of just using single
register reads / writes and forego the regmap_bus entirely. Though using
bulk reads alone would probably provide ~150% performance increase.

Do you have any suggestions / initial feedback? Maybe there's something
I'm missing.

Thank you very much,

Colin Foster