[PATCH RFC 0/2] regmap: support firmware-described non-sequential register reads

[PATCH RFC 0/2] regmap: support firmware-described non-sequential register reads

[Richard Leitner]

Hi all,

this series adds support for firmware/device-tree described constraints
on sequential register reads.

The motivating use case are camera modules from Vision Components.
These modules may integrate image sensors that normally support
incrementing multi-register reads, while the MCU (which sits basically
"between" the I2C host and the camera sensors) breaks them. In such
cases, single-register reads work, but sequential/bulk register reads do
not.

This limitation is therefore not a property of the sensor silicon
itself, but of the hardware module/integration in which the device is
used. As a result, it cannot be identified from the deivce driver and
handling it in each affected device driver does not scale well.

To address this, the series introduces a common firmware property
(no-sequential-read) describing hardware integrations where reading
multiple consecutive registers in a single operation is not reliable.
regmap then consumes that property and maps it to its existing
use_single_read configuration. This keeps the hardware constraint
described in firmware/device-tree while applying it in the layer that
already owns the register read transfer policy.

The initial discussion that motivated this approach can be found here:
https://lore.kernel.org/lkml/20260721151614.GN50424@killaraus.ideasonboard.com/

Feedback is especially welcome on the property naming, the placement of
the common binding schema, and if regmap is the best place to implment this.

Thanks,
Richard

Link: https://lore.kernel.org/lkml/20260721151614.GN50424@killaraus.ideasonboard.com/
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
Richard Leitner (2):
      dt-bindings: regmap: add common schema for no-sequential-read
      regmap: implement no-sequential-read firmware property

 .../devicetree/bindings/regmap/common.yaml         | 26 ++++++++++++++++++++++
 drivers/base/regmap/regmap.c                       | 14 +++++++++++-
 2 files changed, 39 insertions(+), 1 deletion(-)
---
base-commit: 248951ddc14de84de3910f9b13f51491a8cd91df
change-id: 20260722-regmap-single-read-a2e95070cd66

Best regards,
--  
Richard Leitner <richard.leitner@linux.dev>

[PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Richard Leitner]

Introduce a common regmap dt-binding schema with an optional boolean
property no-sequential-read to describe hardware integrations where
reading multiple consecutive registers in a single operation is not
reliable and registers must be read individually.

A typical case are imaging sensors used on vendor-provided camera
modules whose bus integration does not support reads that advance across
consecutive register addresses. In such cases, single-register reads
work, but bulk reads do not. This restriction is a property of the
concrete hardware integration, not of the chip itself. It therefore
cannot be identified from the device driver and duplicating firmware
parsing in each affected driver does not scale.

Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
 .../devicetree/bindings/regmap/common.yaml         | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/regmap/common.yaml b/Documentation/devicetree/bindings/regmap/common.yaml
new file mode 100644
index 0000000000000..1d713bc3217da
--- /dev/null
+++ b/Documentation/devicetree/bindings/regmap/common.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regmap/common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common register access constraints
+
+maintainers:
+  - TBD
+
+description:
+  Common properties describing register access constraints.
+
+properties:
+  no-sequential-read:
+    type: boolean
+    description:
+      Indicates that this device instance does not support sequential
+      register reads.
+
+      Reads may start at a given register address, but reading multiple
+      consecutive registers in a single operation is not reliable.
+      Software must instead read registers individually.
+
+additionalProperties: true

-- 
2.53.0

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `maintainers` field in the newly introduced DT binding schema contains the placeholder 'TBD'. The device tree schema validation (`dtschema`) mandates that all items in the `maintainers` property must be valid names and email addresses matching the format 'Name <email@example.com>'. This will cause `make dt_binding_check` to fail.
--

--- Patch [1]: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read ---
commit 309f545ffe78e2e1263494a044512db6b6e61394
Author: Richard Leitner <richard.leitner@linux.dev>

dt-bindings: regmap: add common schema for no-sequential-read

This commit introduces a common regmap dt-binding schema with an optional
boolean property no-sequential-read. This describes hardware integrations
where reading multiple consecutive registers in a single operation is not
reliable and registers must be read individually.

> diff --git a/Documentation/devicetree/bindings/regmap/common.yaml b/Documentation/devicetree/bindings/regmap/common.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regmap/common.yaml
> @@ -0,0 +1,26 @@
[ ... ]
> +title: Common register access constraints
> +
> +maintainers:
> +  - TBD

[Severity: Low]
Will this cause make dt_binding_check to fail?

Device tree schema validation mandates that all items in the maintainers
property must be valid names and email addresses matching the format
Name <email@example.com>. The placeholder TBD does not match this format
and will trigger a meta-schema validation error.

> +
> +description:
> +  Common properties describing register access constraints.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722-regmap-single-read-v1-0-aaaf31591669@linux.dev?part=1

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> Introduce a common regmap dt-binding schema with an optional boolean
> property no-sequential-read to describe hardware integrations where
> reading multiple consecutive registers in a single operation is not
> reliable and registers must be read individually.

> A typical case are imaging sensors used on vendor-provided camera
> modules whose bus integration does not support reads that advance across
> consecutive register addresses. In such cases, single-register reads
> work, but bulk reads do not. This restriction is a property of the
> concrete hardware integration, not of the chip itself. It therefore
> cannot be identified from the device driver and duplicating firmware
> parsing in each affected driver does not scale.

No, this should not be a DT property.  We should discover this through
the bus, just like we do currently for the various I2C quirks that are
advertied by the I2C subsystem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Richard Leitner]

Hi Mark,

thanks the quick feedback.

On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > Introduce a common regmap dt-binding schema with an optional boolean
> > property no-sequential-read to describe hardware integrations where
> > reading multiple consecutive registers in a single operation is not
> > reliable and registers must be read individually.
> 
> > A typical case are imaging sensors used on vendor-provided camera
> > modules whose bus integration does not support reads that advance across
> > consecutive register addresses. In such cases, single-register reads
> > work, but bulk reads do not. This restriction is a property of the
> > concrete hardware integration, not of the chip itself. It therefore
> > cannot be identified from the device driver and duplicating firmware
> > parsing in each affected driver does not scale.
> 
> No, this should not be a DT property.  We should discover this through
> the bus, just like we do currently for the various I2C quirks that are
> advertied by the I2C subsystem.

What do you mean "discover this through the bus"? As mentioned in the
commit message there is no possibility to detect that within the affected
I2C device drivers.

Or do you mean that it should be "discovered" by modelling the MCU which
"proxies" the I2C traffic between the host and the sensor/device as some
kind of "parent" device of the sensor?

Or something other?

Sorry, if I don't get it, but currently I see no other option than
providing this information somehow via device-tree. No matter if it's in
regmap or I2C.

thanks & regards;rl

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Laurent Pinchart]

On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> > On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > > Introduce a common regmap dt-binding schema with an optional boolean
> > > property no-sequential-read to describe hardware integrations where
> > > reading multiple consecutive registers in a single operation is not
> > > reliable and registers must be read individually.
> > 
> > > A typical case are imaging sensors used on vendor-provided camera
> > > modules whose bus integration does not support reads that advance across
> > > consecutive register addresses. In such cases, single-register reads
> > > work, but bulk reads do not. This restriction is a property of the
> > > concrete hardware integration, not of the chip itself. It therefore
> > > cannot be identified from the device driver and duplicating firmware
> > > parsing in each affected driver does not scale.
> > 
> > No, this should not be a DT property.  We should discover this through
> > the bus, just like we do currently for the various I2C quirks that are
> > advertied by the I2C subsystem.
> 
> What do you mean "discover this through the bus"? As mentioned in the
> commit message there is no possibility to detect that within the affected
> I2C device drivers.
> 
> Or do you mean that it should be "discovered" by modelling the MCU which
> "proxies" the I2C traffic between the host and the sensor/device as some
> kind of "parent" device of the sensor?

Mark's comment wasn't totally clear to me. I think this is what he
meant.

Richard, do you know if the MCU (which is actually an FPGA if I'm not
mistaken) intercepts the I2C signals (i.e. is interposed between the
host and the image sensor), or is "just" connected on the same I2C bus
and messes up the I2C transfer when it detects a condition it dislikes
(for instance by pulling the SDA line down when it detects a read from a
protected register) ?

> Or something other?
> 
> Sorry, if I don't get it, but currently I see no other option than
> providing this information somehow via device-tree. No matter if it's in
> regmap or I2C.

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Richard Leitner]

On Wed, Jul 22, 2026 at 11:16:22PM +0300, Laurent Pinchart wrote:
> On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> > On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> > > On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > > > Introduce a common regmap dt-binding schema with an optional boolean
> > > > property no-sequential-read to describe hardware integrations where
> > > > reading multiple consecutive registers in a single operation is not
> > > > reliable and registers must be read individually.
> > > 
> > > > A typical case are imaging sensors used on vendor-provided camera
> > > > modules whose bus integration does not support reads that advance across
> > > > consecutive register addresses. In such cases, single-register reads
> > > > work, but bulk reads do not. This restriction is a property of the
> > > > concrete hardware integration, not of the chip itself. It therefore
> > > > cannot be identified from the device driver and duplicating firmware
> > > > parsing in each affected driver does not scale.
> > > 
> > > No, this should not be a DT property.  We should discover this through
> > > the bus, just like we do currently for the various I2C quirks that are
> > > advertied by the I2C subsystem.
> > 
> > What do you mean "discover this through the bus"? As mentioned in the
> > commit message there is no possibility to detect that within the affected
> > I2C device drivers.
> > 
> > Or do you mean that it should be "discovered" by modelling the MCU which
> > "proxies" the I2C traffic between the host and the sensor/device as some
> > kind of "parent" device of the sensor?
> 
> Mark's comment wasn't totally clear to me. I think this is what he
> meant.
> 
> Richard, do you know if the MCU (which is actually an FPGA if I'm not
> mistaken) intercepts the I2C signals (i.e. is interposed between the
> host and the image sensor), or is "just" connected on the same I2C bus
> and messes up the I2C transfer when it detects a condition it dislikes
> (for instance by pulling the SDA line down when it detects a read from a
> protected register) ?

Tbh. I don't know. The VC MIPI Camera Module Hardware Operating manual
suggests both, the controller and the sensor sit on the same I2C bus:

https://www.mipi-modules.com/fileadmin/external/documentation/hardware/VC_MIPI_Camera_Module/index.html#mipi-sensor-module-circuit

But that's just a block diagram and nothing is written down really.

I tried some reverse-engineering and probed most of the accessible pads
of the camera module with my scope. I found no evidence that there is "a
second I2C bus" with "delayed" signals as I would suspect if the FPGA
really intercepts the I2C traffic.

Nonetheless this is by far no proof that this isn't the case, as the I2C
lanes of the imaging sensor are not accessible without destroying the PCB
:-(

So any help/feedback/information is greatly appreciated.


@Mark: I understood that if the fpga really intercepts the I2C bus, it
should be modelled accordingly in device tree. But what would be the
preferred implementation if both devices sit on the same I2C bus, but
one is messing up some register reads on purpose?

thanks & regards;rl

> 
> > Or something other?
> > 
> > Sorry, if I don't get it, but currently I see no other option than
> > providing this information somehow via device-tree. No matter if it's in
> > regmap or I2C.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:

> @Mark: I understood that if the fpga really intercepts the I2C bus, it
> should be modelled accordingly in device tree. But what would be the
> preferred implementation if both devices sit on the same I2C bus, but
> one is messing up some register reads on purpose?

I think we would need to have a coherent understanding and description
of the actual issue to know how to describe it.

Please do not add random characters to my name.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:

> > No, this should not be a DT property.  We should discover this through
> > the bus, just like we do currently for the various I2C quirks that are
> > advertied by the I2C subsystem.

> What do you mean "discover this through the bus"? As mentioned in the
> commit message there is no possibility to detect that within the affected
> I2C device drivers.

> Or do you mean that it should be "discovered" by modelling the MCU which
> "proxies" the I2C traffic between the host and the sensor/device as some
> kind of "parent" device of the sensor?

If there is hardware there that rewrites the traffic then obviously that
hardware should be described in the device tree, yes.  It sounds like
this is the actual I2C controller and is what is imposing the limits.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH RFC 2/2] regmap: implement no-sequential-read firmware property

[Richard Leitner]

Some devices are integrated in hardware modules where incrementing
multi-register reads are not reliable, even though the underlying chip
normally supports them.

regmap already owns a configuration that selects between bulk reads and
single-register reads. Letting regmap consume this firmware property
makes use of this configuration and therefore keeps the override in the
actual layer of implementation.

If the property is absent, existing behaviour is unchanged.

Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
 drivers/base/regmap/regmap.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index e6e022b026375..ed08db764cdcb 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -674,6 +674,18 @@ enum regmap_endian regmap_get_val_endian(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(regmap_get_val_endian);
 
+static bool regmap_get_use_single_read(struct device *dev,
+				       const struct regmap_bus *bus,
+				       const struct regmap_config *config)
+{
+	struct fwnode_handle *fwnode = dev ? dev_fwnode(dev) : NULL;
+
+	if (fwnode_property_read_bool(fwnode, "no-sequential-read"))
+		return true;
+
+	return config->use_single_read || !(config->read || (bus && bus->read));
+}
+
 struct regmap *__regmap_init(struct device *dev,
 			     const struct regmap_bus *bus,
 			     void *bus_context,
@@ -786,7 +798,7 @@ struct regmap *__regmap_init(struct device *dev,
 		map->reg_stride_order = ilog2(map->reg_stride);
 	else
 		map->reg_stride_order = -1;
-	map->use_single_read = config->use_single_read || !(config->read || (bus && bus->read));
+	map->use_single_read = regmap_get_use_single_read(dev, bus, config);
 	map->use_single_write = config->use_single_write || !(config->write || (bus && bus->write));
 	map->can_multi_write = config->can_multi_write && (config->write || (bus && bus->write));
 	if (bus) {

-- 
2.53.0