[PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver

[PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver

[Jinseob Kim]

This RFC series adds an Industrial I/O driver for Open Sensor Fusion
sensor aggregation devices.

Open Sensor Fusion is an open hardware project for sensor
aggregation devices. The Linux IIO driver is an initial host-side
implementation for OSF devices. The driver receives OSF frames over
UART, uses device capability reports to discover supported sensor
streams, and exposes supported raw sensor data through IIO devices.

This series is still marked RFC because the DT binding identity, the
supported OSF protocol subset, and protocol extension and backward
compatibility rules are still under review. The v4 series
intentionally models the Linux device as a generic Open Sensor Fusion
device rather than an OSF GREEN board-specific device. OSF GREEN is
the prototype board used for current runtime testing, not the Linux DT
compatible or driver identity.

The current wire format uses the OSF0 magic for protocol major
version 0. That is kept as an internal wire-format detail for
compatibility with existing firmware, tools, and runtime smoke
evidence. The public driver identity remains Open Sensor Fusion / OSF,
with protocol versioning handled by the protocol major/minor fields.

Project links:
https://www.opensensorfusion.org/
https://github.com/opensensorfusion
https://github.com/opensensorfusion/opensensorfusion-hardware
https://github.com/opensensorfusion/opensensorfusion-linux

Runtime testing so far has used an OSF GREEN prototype connected to a
Raspberry Pi over UART. On Raspberry Pi 6.12.75+rpt-rpi-v8, the
driver registered osf-accel, osf-gyro, osf-magn, and osf-temp from a
capability report. Raw reads and software kfifo buffer reads were
tested for all four IIO devices.

Changes since v3:

* Explain why the series is still RFC.
* Move the DT binding out of iio/imu because the device is a sensor
  aggregation device rather than an IMU.
* Replace the OSF GREEN board-specific compatible with the generic
  opensensorfusion,osf compatible.
* Treat OSF GREEN as tested prototype hardware / board model
  information, not as the Linux compatible string.
* Rename the kernel documentation to open-sensor-fusion.rst and
  reduce it to a driver-facing overview.
* Add the IIO documentation toctree entry.
* Keep full protocol details and compatibility rules in project
  documentation rather than duplicating the full wire specification in
  the kernel tree.
* Avoid using OSF0 as the public driver identity; keep it only as the
  current wire magic for protocol major version 0.
* Add FourCC-style wire magic handling in the decoder.
* Use GENMASK() for the capability flags mask.
* Clarify signed 32-bit little-endian sample decoding.
* Stop counting normal partial UART receive waits as partial frame
  errors.
* Avoid decoding complete frames twice in the stream/core path.
* Remove the local scan[] bounce before
  iio_push_to_buffers_with_ts_unaligned() and pass the values buffer
  directly.
* Remove the meaningless temperature available_scan_masks entry.
* Update MAINTAINERS paths for the new binding and documentation
  names.

Jinseob Kim (6):
  dt-bindings: iio: add Open Sensor Fusion device
  Documentation: iio: add Open Sensor Fusion driver overview
  iio: osf: add protocol decoding
  iio: osf: add stream parser
  iio: osf: add UART transport
  iio: osf: register IIO devices from capabilities

 .../iio/imu/opensensorfusion,osf-green.yaml   |  43 ---
 .../bindings/iio/opensensorfusion,osf.yaml    |  43 +++
 Documentation/iio/index.rst                   |   1 +
 .../iio/open-sensor-fusion-protocol-v0.rst    | 308 ------------------
 Documentation/iio/open-sensor-fusion.rst      |  62 ++++
 MAINTAINERS                                   |  26 +-
 drivers/iio/opensensorfusion/Kconfig          |   4 +-
 drivers/iio/opensensorfusion/osf_core.c       |   9 +-
 drivers/iio/opensensorfusion/osf_iio.c        |  15 +-
 drivers/iio/opensensorfusion/osf_protocol.c   |   4 +-
 drivers/iio/opensensorfusion/osf_protocol.h   |   4 +-
 drivers/iio/opensensorfusion/osf_serdev.c     |   2 +-
 drivers/iio/opensensorfusion/osf_stream.c     |  38 +--
 13 files changed, 145 insertions(+), 414 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
 delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
 create mode 100644 Documentation/iio/open-sensor-fusion.rst

-- 
2.43.0

[PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device

[Jinseob Kim]

Describe the OSF sensor aggregation hub.

Use the generic opensensorfusion,osf compatible.

Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 .../iio/imu/opensensorfusion,osf-green.yaml   | 43 -------------------
 .../bindings/iio/opensensorfusion,osf.yaml    | 43 +++++++++++++++++++
 MAINTAINERS                                   | 27 ++++++------
 3 files changed, 57 insertions(+), 56 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
 create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml

diff --git a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml b/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
deleted file mode 100644
index 626b41fb0..000000000
--- a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
+++ /dev/null
@@ -1,43 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/iio/imu/opensensorfusion,osf-green.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: OSF GREEN sensor aggregation board
-
-maintainers:
-  - Jinseob Kim <kimjinseob88@gmail.com>
-
-description: |
-  OSF GREEN is an STM32F405-based sensor aggregation board from the Open
-  Sensor Fusion open hardware project. It sends OSF0 capability, status, and
-  sample frames to a host over a UART link.
-
-  Open Sensor Fusion is not a generic industry standard. Public project and
-  hardware documentation is available at:
-
-    https://github.com/opensensorfusion
-    https://github.com/opensensorfusion/opensensorfusion-hardware
-
-allOf:
-  - $ref: /schemas/serial/serial-peripheral-props.yaml#
-
-properties:
-  compatible:
-    const: opensensorfusion,osf-green
-
-required:
-  - compatible
-
-unevaluatedProperties: false
-
-examples:
-  - |
-    serial {
-        sensor {
-            compatible = "opensensorfusion,osf-green";
-        };
-    };
-
-...
diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
new file mode 100644
index 000000000..a4049715a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Open Sensor Fusion Sensor Aggregation Hub
+
+maintainers:
+  - Jinseob Kim <kimjinseob88@gmail.com>
+
+description: |
+  Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
+  protocol data stream over its host interface and may report capabilities and
+  samples for multiple sensor classes. The Linux driver discovers the actual
+  sensor channels from OSF capability reports instead of describing those
+  sensors in Device Tree.
+
+  Open Sensor Fusion is not a generic industry standard. Public project
+  documentation is available at:
+
+    https://github.com/opensensorfusion
+
+allOf:
+  - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+properties:
+  compatible:
+    const: opensensorfusion,osf
+
+required:
+  - compatible
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    serial {
+        sensor {
+            compatible = "opensensorfusion,osf";
+        };
+    };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 56181470d..e227b9aff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19977,19 +19977,6 @@ F:	Documentation/networking/oa-tc6-framework.rst
 F:	drivers/net/ethernet/oa_tc6.c
 F:	include/linux/oa_tc6.h
 
-OPEN SENSOR FUSION IIO DRIVER
-M:	Jinseob Kim <kimjinseob88@gmail.com>
-S:	Maintained
-F:	Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
-F:	Documentation/iio/open-sensor-fusion-protocol-v0.rst
-F:	drivers/iio/opensensorfusion/Kconfig
-F:	drivers/iio/opensensorfusion/Makefile
-F:	drivers/iio/opensensorfusion/osf_core.*
-F:	drivers/iio/opensensorfusion/osf_iio.*
-F:	drivers/iio/opensensorfusion/osf_protocol.*
-F:	drivers/iio/opensensorfusion/osf_serdev.c
-F:	drivers/iio/opensensorfusion/osf_stream.*
-
 OPEN FIRMWARE AND FLATTENED DEVICE TREE
 M:	Rob Herring <robh@kernel.org>
 M:	Saravana Kannan <saravanak@kernel.org>
@@ -20024,6 +20011,20 @@ F:	Documentation/devicetree/
 F:	arch/*/boot/dts/
 F:	include/dt-bindings/
 
+OPEN SENSOR FUSION IIO DRIVER
+M:	Jinseob Kim <kimjinseob88@gmail.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
+F:	Documentation/iio/open-sensor-fusion-protocol-v0.rst
+F:	drivers/iio/opensensorfusion/Kconfig
+F:	drivers/iio/opensensorfusion/Makefile
+F:	drivers/iio/opensensorfusion/osf_core.*
+F:	drivers/iio/opensensorfusion/osf_iio.*
+F:	drivers/iio/opensensorfusion/osf_protocol.*
+F:	drivers/iio/opensensorfusion/osf_serdev.c
+F:	drivers/iio/opensensorfusion/osf_stream.*
+
+
 OPENCOMPUTE PTP CLOCK DRIVER
 M:	Vadim Fedorenko <vadim.fedorenko@linux.dev>
 L:	netdev@vger.kernel.org
-- 
2.43.0

Re: [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device

[Conor Dooley]

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

Jonathan/IIO folks,

On Mon, Jun 08, 2026 at 08:43:38AM +0900, Jinseob Kim wrote:

> diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> new file mode 100644
> index 000000000..a4049715a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Open Sensor Fusion Sensor Aggregation Hub
> +
> +maintainers:
> +  - Jinseob Kim <kimjinseob88@gmail.com>
> +
> +description: |
> +  Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
> +  protocol data stream over its host interface and may report capabilities and
> +  samples for multiple sensor classes. The Linux driver discovers the actual
> +  sensor channels from OSF capability reports instead of describing those
> +  sensors in Device Tree.
> +
> +  Open Sensor Fusion is not a generic industry standard. Public project
> +  documentation is available at:
> +
> +    https://github.com/opensensorfusion
> +
> +allOf:
> +  - $ref: /schemas/serial/serial-peripheral-props.yaml#
> +
> +properties:
> +  compatible:
> +    const: opensensorfusion,osf
> +
> +required:
> +  - compatible

Do you think it makes sense to permit a regulator here, so that the
"host" OS can power on/off the board running the osf stack?

> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    serial {
> +        sensor {
> +            compatible = "opensensorfusion,osf";
> +        };
> +    };
> +...

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

Re: [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device

[Kim Jinseob]

> Do you think it makes sense to permit a regulator here, so that the
> "host" OS can power on/off the board running the osf stack?

From the OSF hardware side, yes, that makes sense.

The current prototype used for testing is powered independently, but an OSF
device may also be integrated as a host-powered UART peripheral. In that case
allowing the host to control the board supply through an optional regulator
would be useful.

Unless the IIO side prefers otherwise, I will add an optional supply property
to the binding and matching optional regulator handling in the driver in the
next revision.

Jinseob


2026년 6월 10일 (수) 오전 1:19, Conor Dooley <conor@kernel.org>님이 작성:
>
> Jonathan/IIO folks,
>
> On Mon, Jun 08, 2026 at 08:43:38AM +0900, Jinseob Kim wrote:
>
> > diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > new file mode 100644
> > index 000000000..a4049715a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > @@ -0,0 +1,43 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Open Sensor Fusion Sensor Aggregation Hub
> > +
> > +maintainers:
> > +  - Jinseob Kim <kimjinseob88@gmail.com>
> > +
> > +description: |
> > +  Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
> > +  protocol data stream over its host interface and may report capabilities and
> > +  samples for multiple sensor classes. The Linux driver discovers the actual
> > +  sensor channels from OSF capability reports instead of describing those
> > +  sensors in Device Tree.
> > +
> > +  Open Sensor Fusion is not a generic industry standard. Public project
> > +  documentation is available at:
> > +
> > +    https://github.com/opensensorfusion
> > +
> > +allOf:
> > +  - $ref: /schemas/serial/serial-peripheral-props.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    const: opensensorfusion,osf
> > +
> > +required:
> > +  - compatible
>
> Do you think it makes sense to permit a regulator here, so that the
> "host" OS can power on/off the board running the osf stack?
>
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    serial {
> > +        sensor {
> > +            compatible = "opensensorfusion,osf";
> > +        };
> > +    };
> > +...

Re: [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device

[Jonathan Cameron]

On Wed, 10 Jun 2026 18:33:54 +0900
Kim Jinseob <kimjinseob88@gmail.com> wrote:

> > Do you think it makes sense to permit a regulator here, so that the
> > "host" OS can power on/off the board running the osf stack?  
> 
> From the OSF hardware side, yes, that makes sense.
> 
> The current prototype used for testing is powered independently, but an OSF
> device may also be integrated as a host-powered UART peripheral. In that case
> allowing the host to control the board supply through an optional regulator
> would be useful.
> 
> Unless the IIO side prefers otherwise, I will add an optional supply property
> to the binding and matching optional regulator handling in the driver in the
> next revision.

When a device needs power, the regulator is required, not optional from a binding
point of view.  If it is always one people can use a fixed regulator to represent it.

Now from a driver point of view, the regulator framework in linux provides stub regulators
for missing ones - on assumption they are always on.  So we can just request the
regulators in the driver.  Keep it simple for now and use a
devm_regulator_get_enable() in probe so we have power on for all the time
the driver is loaded. Can do fancy stuff later when you have a board where the
power is controlled.

> 
> Jinseob
> 
> 
> 2026년 6월 10일 (수) 오전 1:19, Conor Dooley <conor@kernel.org>님이 작성:
> >
> > Jonathan/IIO folks,
> >
> > On Mon, Jun 08, 2026 at 08:43:38AM +0900, Jinseob Kim wrote:
> >  
> > > diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > > new file mode 100644
> > > index 000000000..a4049715a
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > > @@ -0,0 +1,43 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Open Sensor Fusion Sensor Aggregation Hub
> > > +
> > > +maintainers:
> > > +  - Jinseob Kim <kimjinseob88@gmail.com>
> > > +
> > > +description: |
> > > +  Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
> > > +  protocol data stream over its host interface and may report capabilities and
> > > +  samples for multiple sensor classes. The Linux driver discovers the actual
> > > +  sensor channels from OSF capability reports instead of describing those
> > > +  sensors in Device Tree.
> > > +
> > > +  Open Sensor Fusion is not a generic industry standard. Public project
> > > +  documentation is available at:
> > > +
> > > +    https://github.com/opensensorfusion
> > > +
> > > +allOf:
> > > +  - $ref: /schemas/serial/serial-peripheral-props.yaml#
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: opensensorfusion,osf
> > > +
> > > +required:
> > > +  - compatible  
> >
> > Do you think it makes sense to permit a regulator here, so that the
> > "host" OS can power on/off the board running the osf stack?
> >  
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    serial {
> > > +        sensor {
> > > +            compatible = "opensensorfusion,osf";
> > > +        };
> > > +    };
> > > +...  

Re: [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device

[Kim Jinseob]

2026년 6월 15일 (월) 오전 2:55, Jonathan Cameron <jic23@kernel.org>님이 작성:
>
> On Wed, 10 Jun 2026 18:33:54 +0900
> Kim Jinseob <kimjinseob88@gmail.com> wrote:

> When a device needs power, the regulator is required, not optional from a binding
> point of view.  If it is always one people can use a fixed regulator to represent it.
>
> Now from a driver point of view, the regulator framework in linux provides stub regulators
> for missing ones - on assumption they are always on.  So we can just request the
> regulators in the driver.  Keep it simple for now and use a
> devm_regulator_get_enable() in probe so we have power on for all the time
> the driver is loaded. Can do fancy stuff later when you have a board where the
> power is controlled.

Understood, thanks.

I will make vcc-supply a required property in the binding and use
devm_regulator_get_enable() in probe in the next revision, keeping the
power handling simple for now.

Jinseob

Re: [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device

[Jonathan Cameron]

On Mon,  8 Jun 2026 08:43:38 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:

> Describe the OSF sensor aggregation hub.
> 
> Use the generic opensensorfusion,osf compatible.
> 
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>

This seems to be a patch against an earlier version of your series.
Make sure this applies directly on the upstream kernel (release or rc1
typically depending on which is most recent).

Jonathan

> ---
>  .../iio/imu/opensensorfusion,osf-green.yaml   | 43 -------------------
>  .../bindings/iio/opensensorfusion,osf.yaml    | 43 +++++++++++++++++++
>  MAINTAINERS                                   | 27 ++++++------
>  3 files changed, 57 insertions(+), 56 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
>  create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml b/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
> deleted file mode 100644
> index 626b41fb0..000000000
> --- a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> -%YAML 1.2
> ----
> -$id: http://devicetree.org/schemas/iio/imu/opensensorfusion,osf-green.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
As above. There shouldn't be anything to remove!

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 56181470d..e227b9aff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19977,19 +19977,6 @@ F:	Documentation/networking/oa-tc6-framework.rst
>  F:	drivers/net/ethernet/oa_tc6.c
>  F:	include/linux/oa_tc6.h
>  
> -OPEN SENSOR FUSION IIO DRIVER
> -M:	Jinseob Kim <kimjinseob88@gmail.com>
> -S:	Maintained
> -F:	Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
> -F:	Documentation/iio/open-sensor-fusion-protocol-v0.rst
> -F:	drivers/iio/opensensorfusion/Kconfig
> -F:	drivers/iio/opensensorfusion/Makefile
> -F:	drivers/iio/opensensorfusion/osf_core.*
> -F:	drivers/iio/opensensorfusion/osf_iio.*
> -F:	drivers/iio/opensensorfusion/osf_protocol.*
> -F:	drivers/iio/opensensorfusion/osf_serdev.c
> -F:	drivers/iio/opensensorfusion/osf_stream.*
> -
>  OPEN FIRMWARE AND FLATTENED DEVICE TREE
>  M:	Rob Herring <robh@kernel.org>
>  M:	Saravana Kannan <saravanak@kernel.org>
> @@ -20024,6 +20011,20 @@ F:	Documentation/devicetree/
>  F:	arch/*/boot/dts/
>  F:	include/dt-bindings/
>  
> +OPEN SENSOR FUSION IIO DRIVER
> +M:	Jinseob Kim <kimjinseob88@gmail.com>
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> +F:	Documentation/iio/open-sensor-fusion-protocol-v0.rst
> +F:	drivers/iio/opensensorfusion/Kconfig
> +F:	drivers/iio/opensensorfusion/Makefile
> +F:	drivers/iio/opensensorfusion/osf_core.*
> +F:	drivers/iio/opensensorfusion/osf_iio.*
> +F:	drivers/iio/opensensorfusion/osf_protocol.*
> +F:	drivers/iio/opensensorfusion/osf_serdev.c
> +F:	drivers/iio/opensensorfusion/osf_stream.*
> +
One blank line.

> +
>  OPENCOMPUTE PTP CLOCK DRIVER
>  M:	Vadim Fedorenko <vadim.fedorenko@linux.dev>
>  L:	netdev@vger.kernel.org

[PATCH RFC v4 2/6] Documentation: iio: add Open Sensor Fusion driver overview

[Jinseob Kim]

Add a short driver-facing overview.

Leave full protocol details to project docs.

Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 Documentation/iio/index.rst                   |   1 +
 .../iio/open-sensor-fusion-protocol-v0.rst    | 308 ------------------
 Documentation/iio/open-sensor-fusion.rst      |  62 ++++
 MAINTAINERS                                   |   3 +-
 4 files changed, 64 insertions(+), 310 deletions(-)
 delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
 create mode 100644 Documentation/iio/open-sensor-fusion.rst

diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index ba3e609c6..2713ec5e0 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -38,4 +38,5 @@ Industrial I/O Kernel Drivers
    adxl345
    bno055
    ep93xx_adc
+   open-sensor-fusion
    opt4060
diff --git a/Documentation/iio/open-sensor-fusion-protocol-v0.rst b/Documentation/iio/open-sensor-fusion-protocol-v0.rst
deleted file mode 100644
index 80852f4cf..000000000
--- a/Documentation/iio/open-sensor-fusion-protocol-v0.rst
+++ /dev/null
@@ -1,308 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0-only
-
-Open Sensor Fusion protocol v0
-==============================
-
-This document describes the OSF0 UART wire format used by the Open Sensor
-Fusion Linux IIO driver. It is a wire format reference for the host driver. It
-is not a firmware programming interface.
-
-Background
-----------
-
-Open Sensor Fusion is an open hardware project for sensor aggregation devices
-and Linux IIO host support. It is not a generic sensor protocol standard. The
-first concrete hardware target is OSF GREEN, an STM32F405-based board that
-streams OSF0 frames to a Linux host.
-
-Public project documentation is available at:
-
-- https://www.opensensorfusion.org/
-- https://github.com/opensensorfusion
-- https://github.com/opensensorfusion/opensensorfusion-hardware
-- https://github.com/opensensorfusion/opensensorfusion-linux
-
-Wire format and driver subset
------------------------------
-
-OSF0 defines a small device-to-host UART frame format. The current RFC driver
-supports only the subset needed to expose OSF GREEN raw sensor data through
-IIO:
-
-- ``SENSOR_SAMPLE`` frames for accelerometer, gyroscope, magnetometer, and
-  temperature samples.
-- ``CAPABILITY_REPORT`` frames used to create the supported IIO devices.
-- ``DEVICE_STATUS`` frames cached for diagnostics.
-
-The driver ignores vendor private message types and does not implement command
-transport, calibration controls, USB transport, fusion output, or runtime
-capability removal.
-
-Device model
-------------
-
-An OSF0 device is a sensor aggregation device. It sends binary frames from the
-device to the host. The host driver decodes the frames and maps supported
-sensors to IIO devices.
-
-The hardware used for smoke testing is an OSF GREEN prototype with an
-STM32F405RGT6 MCU, an ICM42688P-class IMU, and an MMC5983MA magnetometer. That
-hardware is the first supported target for the RFC driver.
-
-Transport
----------
-
-The transport is UART at 115200 baud, 8 data bits, no parity, and 1 stop bit.
-The Linux transport is serdev. The v0 upstream driver covers device-to-host
-frames. Flow control is not used by the tested stream.
-
-Byte order
-----------
-
-All multi-byte integer fields are little-endian. Samples use signed 32-bit
-little-endian integers when ``sample_format`` is ``s32``.
-
-Frame format
-------------
-
-Each frame has a fixed 38-byte header, a payload, and a 4-byte CRC.
-
-.. list-table::
-   :header-rows: 1
-
-   * - Offset
-     - Size
-     - Field
-     - Description
-   * - 0
-     - 4
-     - magic
-     - ASCII ``OSF0``
-   * - 4
-     - 1
-     - protocol_major
-     - Must be ``0``
-   * - 5
-     - 1
-     - protocol_minor
-     - Minor version
-   * - 6
-     - 2
-     - header_len
-     - Must be ``38``
-   * - 8
-     - 2
-     - message_type
-     - Message type
-   * - 10
-     - 4
-     - payload_len
-     - Payload length in bytes
-   * - 14
-     - 8
-     - sequence
-     - Monotonic device sequence
-   * - 22
-     - 8
-     - timestamp_us
-     - Device timestamp in microseconds
-   * - 30
-     - 4
-     - flags
-     - Message flags
-   * - 34
-     - 4
-     - reserved
-     - Must be zero for v0
-   * - 38
-     - payload_len
-     - payload
-     - Message payload
-   * - 38 + payload_len
-     - 4
-     - crc32
-     - CRC32 over header and payload
-
-The frame CRC is IEEE CRC32 as implemented by ``crc32_le()`` with initial
-value ``0xffffffff`` and final XOR value ``0xffffffff``. The CRC field is not
-included in the CRC input.
-
-Message types
--------------
-
-.. list-table::
-   :header-rows: 1
-
-   * - Value
-     - Name
-     - Direction
-   * - ``0x0001``
-     - ``SENSOR_SAMPLE``
-     - device to host
-   * - ``0x0002``
-     - ``DEVICE_STATUS``
-     - device to host
-   * - ``0x0003``
-     - ``CAPABILITY_REPORT``
-     - device to host
-
-Message types ``0x7f00`` through ``0x7fff`` are reserved. Values at or above
-``0x8000`` are vendor private and are ignored by the current RFC driver.
-
-``SENSOR_SAMPLE`` payload
--------------------------
-
-The payload is a 16-byte payload header followed by ``4 * channel_count`` bytes
-of sample data.
-
-.. list-table::
-   :header-rows: 1
-
-   * - Offset
-     - Size
-     - Field
-     - Description
-   * - 0
-     - 2
-     - sensor_type
-     - Sensor type ID
-   * - 2
-     - 2
-     - sensor_index
-     - Instance index
-   * - 4
-     - 2
-     - channel_count
-     - Number of ``s32`` channels
-   * - 6
-     - 2
-     - sample_format
-     - Must be ``1`` (``s32``)
-   * - 8
-     - 4
-     - scale_nano
-     - Scale factor in nano-units
-   * - 12
-     - 4
-     - reserved
-     - Must be zero for v0
-   * - 16
-     - 4 * channel_count
-     - samples
-     - Signed 32-bit channel samples
-
-The current RFC driver accepts only ``sample_format = s32`` and only the fixed
-channel counts used by its supported IIO devices.
-
-``DEVICE_STATUS`` payload
--------------------------
-
-The payload size is 20 bytes. Fields are ``uptime_s``, ``status_flags``,
-``error_flags``, ``dropped_frames``, and a reserved field. Each field is
-32 bits. The reserved field must be zero for v0.
-
-``CAPABILITY_REPORT`` payload
------------------------------
-
-The base payload size is 4 bytes. It contains ``capability_count`` and a
-reserved field. The reserved field must be zero for v0. Each capability entry
-is 20 bytes:
-
-.. list-table::
-   :header-rows: 1
-
-   * - Offset
-     - Size
-     - Field
-     - Description
-   * - 0
-     - 2
-     - sensor_type
-     - Sensor type ID
-   * - 2
-     - 2
-     - sensor_index
-     - Instance index
-   * - 4
-     - 2
-     - channel_count
-     - Number of channels
-   * - 6
-     - 2
-     - sample_format
-     - Must be ``1`` (``s32``)
-   * - 8
-     - 4
-     - scale_nano
-     - Scale factor in nano-units
-   * - 12
-     - 4
-     - flags
-     - Capability flags
-   * - 16
-     - 4
-     - reserved
-     - Must be zero for v0
-
-Capability flag bit 0 means enabled by default. Bit 1 means calibrated data can
-be provided by the device. Other bits are invalid for v0.
-
-Sensor type IDs
----------------
-
-.. list-table::
-   :header-rows: 1
-
-   * - Value
-     - Sensor
-     - Current RFC driver mapping
-   * - ``0x0001``
-     - accelerometer
-     - ``IIO_ACCEL``, X/Y/Z
-   * - ``0x0002``
-     - gyroscope
-     - ``IIO_ANGL_VEL``, X/Y/Z
-   * - ``0x0003``
-     - magnetometer
-     - ``IIO_MAGN``, X/Y/Z
-   * - ``0x0004``
-     - barometer
-     - not mapped
-   * - ``0x0005``
-     - temperature
-     - ``IIO_TEMP``
-   * - ``0x0006``
-     - humidity
-     - not mapped
-   * - ``0x0007``
-     - ambient light
-     - not mapped
-   * - ``0x0008``
-     - proximity
-     - not mapped
-
-Scaling
--------
-
-``scale_nano`` is the per-channel scale value in nano-units. The Linux driver
-maps it to ``IIO_CHAN_INFO_SCALE`` as integer plus nano. The exact physical
-unit depends on the IIO channel type.
-
-Timestamps
-----------
-
-The frame header carries ``timestamp_us``, a device-side timestamp in
-microseconds. UART buffering and host scheduling can add delay before a frame
-is processed by the host.
-
-The current RFC driver does not claim production-grade host/device timestamp
-correlation. Buffered IIO timestamps are taken from IIO timestamp clock handling
-when samples are pushed to IIO buffers.
-
-Non-goals for v0 upstream
--------------------------
-
-The v0 upstream driver does not include USB transport, fusion output, Attitude
-and Heading Reference System (AHRS) output, Kalman output, calibration command
-ABI, custom sysfs control surface, production timestamp correlation, or runtime
-capability removal.
diff --git a/Documentation/iio/open-sensor-fusion.rst b/Documentation/iio/open-sensor-fusion.rst
new file mode 100644
index 000000000..244a4fecb
--- /dev/null
+++ b/Documentation/iio/open-sensor-fusion.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Open Sensor Fusion
+==================
+
+Open Sensor Fusion is a sensor aggregation hub interface. The Linux IIO driver
+receives OSF protocol frames from an attached device, discovers supported sensor
+streams through capability reports, and registers matching IIO devices for the
+sensor classes supported by the driver.
+
+This document is a driver-facing overview for the Linux IIO mapping. The full
+wire protocol, firmware behavior, and hardware model details belong in the Open
+Sensor Fusion project documentation.
+
+Device Model
+------------
+
+An OSF device sends binary frames from the device to the host. The host driver
+uses ``CAPABILITY_REPORT`` messages to discover which sensor streams are
+available. Device Tree describes the attached OSF sensor aggregation hub; it does
+not enumerate the individual sensors discovered at runtime.
+
+The currently supported Linux subset exposes:
+
+* accelerometer samples as ``IIO_ACCEL`` X/Y/Z channels,
+* gyroscope samples as ``IIO_ANGL_VEL`` X/Y/Z channels,
+* magnetometer samples as ``IIO_MAGN`` X/Y/Z channels, and
+* temperature samples as ``IIO_TEMP``.
+
+Protocol Scope
+---------------
+
+The driver supports OSF protocol major version 0 for the initial IIO receive
+path. The current wire magic is ``OSF0``; that string is a wire-format detail and
+is not the Linux driver identity. Protocol versioning is carried by the
+``protocol_major`` and ``protocol_minor`` fields in the frame header.
+
+The initial Linux driver handles device-to-host frames for:
+
+* ``SENSOR_SAMPLE`` buffered and direct-mode sample data,
+* ``CAPABILITY_REPORT`` based IIO device registration, and
+* ``DEVICE_STATUS`` cache updates.
+
+Vendor-private message types are ignored. Command transport, calibration
+control ABI, fusion output ABI, and runtime capability removal are outside the
+initial Linux IIO receive path.
+
+Timestamps
+----------
+
+OSF frames include a device-side ``timestamp_us`` field. Buffered IIO samples use
+an IIO timestamp captured on the host when samples are pushed to IIO buffers.
+The initial driver does not correlate the device timestamp with the host IIO
+clock.
+
+Compatibility Notes
+-------------------
+
+The project protocol documentation should define the compatibility rules for
+reserved fields, optional flags, and trailing extension data. Until those rules
+are finalized, the Linux decoder keeps conservative bounds checks around the
+currently supported message layouts.
diff --git a/MAINTAINERS b/MAINTAINERS
index e227b9aff..2ddefc42d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20015,7 +20015,7 @@ OPEN SENSOR FUSION IIO DRIVER
 M:	Jinseob Kim <kimjinseob88@gmail.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
-F:	Documentation/iio/open-sensor-fusion-protocol-v0.rst
+F:	Documentation/iio/open-sensor-fusion.rst
 F:	drivers/iio/opensensorfusion/Kconfig
 F:	drivers/iio/opensensorfusion/Makefile
 F:	drivers/iio/opensensorfusion/osf_core.*
@@ -20024,7 +20024,6 @@ F:	drivers/iio/opensensorfusion/osf_protocol.*
 F:	drivers/iio/opensensorfusion/osf_serdev.c
 F:	drivers/iio/opensensorfusion/osf_stream.*
 
-
 OPENCOMPUTE PTP CLOCK DRIVER
 M:	Vadim Fedorenko <vadim.fedorenko@linux.dev>
 L:	netdev@vger.kernel.org
-- 
2.43.0

Re: [PATCH RFC v4 2/6] Documentation: iio: add Open Sensor Fusion driver overview

[Jonathan Cameron]

On Mon,  8 Jun 2026 08:43:39 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:

> Add a short driver-facing overview.
> 
> Leave full protocol details to project docs.
> 
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
Same issue on needing this series to be against a suitable
tree, not on top of your previous version.

> ---
>  Documentation/iio/index.rst                   |   1 +
>  .../iio/open-sensor-fusion-protocol-v0.rst    | 308 ------------------
>  Documentation/iio/open-sensor-fusion.rst      |  62 ++++
>  MAINTAINERS                                   |   3 +-
>  4 files changed, 64 insertions(+), 310 deletions(-)
>  delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
>  create mode 100644 Documentation/iio/open-sensor-fusion.rst
> 
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e227b9aff..2ddefc42d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20015,7 +20015,7 @@ OPEN SENSOR FUSION IIO DRIVER
>  M:	Jinseob Kim <kimjinseob88@gmail.com>
>  S:	Maintained
>  F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> -F:	Documentation/iio/open-sensor-fusion-protocol-v0.rst
> +F:	Documentation/iio/open-sensor-fusion.rst
>  F:	drivers/iio/opensensorfusion/Kconfig
>  F:	drivers/iio/opensensorfusion/Makefile
>  F:	drivers/iio/opensensorfusion/osf_core.*
> @@ -20024,7 +20024,6 @@ F:	drivers/iio/opensensorfusion/osf_protocol.*
>  F:	drivers/iio/opensensorfusion/osf_serdev.c
>  F:	drivers/iio/opensensorfusion/osf_stream.*
>  
> -
Check your series for things like this right before sending (we all make 
mistakes like this when building up series!)  It clearly belongs in the
previous patch.

>  OPENCOMPUTE PTP CLOCK DRIVER
>  M:	Vadim Fedorenko <vadim.fedorenko@linux.dev>
>  L:	netdev@vger.kernel.org

Re: [PATCH RFC v4 2/6] Documentation: iio: add Open Sensor Fusion driver overview

[Kim Jinseob]

> Same issue on needing this series to be against a suitable
> tree, not on top of your previous version.

Understood, thanks.

I will regenerate the next revision as a full standalone series against a
clean upstream base, not on top of the previous version.

I will also check the final diffstat before sending so files from earlier
versions are not removed, and fold the MAINTAINERS cleanup into the correct
patch.

Thanks,

Jinseob

[PATCH RFC v4 3/6] iio: osf: add protocol decoding

[Jinseob Kim]

Use a FourCC-style wire magic comparison.

Document signed little-endian sample handling.

Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 drivers/iio/opensensorfusion/osf_protocol.c | 4 +++-
 drivers/iio/opensensorfusion/osf_protocol.h | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/opensensorfusion/osf_protocol.c b/drivers/iio/opensensorfusion/osf_protocol.c
index ed91d3dd5..5bee545f3 100644
--- a/drivers/iio/opensensorfusion/osf_protocol.c
+++ b/drivers/iio/opensensorfusion/osf_protocol.c
@@ -11,6 +11,7 @@
 
 #define OSF_CRC32_INIT		GENMASK(31, 0)
 #define OSF_CRC32_XOROUT	GENMASK(31, 0)
+#define OSF_FRAME_MAGIC		0x3046534f /* "OSF0" little-endian */
 
 static bool osf_sensor_type_valid(u16 sensor_type)
 {
@@ -38,7 +39,7 @@ int osf_protocol_decode_frame(const u8 *buf, size_t len,
 	if (len < OSF_FRAME_MIN_LEN)
 		return -EMSGSIZE;
 
-	if (buf[0] != 'O' || buf[1] != 'S' || buf[2] != 'F' || buf[3] != '0')
+	if (get_unaligned_le32(buf) != OSF_FRAME_MAGIC)
 		return -EPROTO;
 
 	major = buf[4];
@@ -136,6 +137,7 @@ int osf_protocol_sensor_sample_value(const struct osf_sensor_sample *sample,
 	if (index >= sample->channel_count)
 		return -ERANGE;
 
+	/* Samples are little-endian two's-complement signed values. */
 	*value = (s32)get_unaligned_le32(sample->samples + index * sizeof(s32));
 
 	return 0;
diff --git a/drivers/iio/opensensorfusion/osf_protocol.h b/drivers/iio/opensensorfusion/osf_protocol.h
index 4b6fb131a..c62c2c254 100644
--- a/drivers/iio/opensensorfusion/osf_protocol.h
+++ b/drivers/iio/opensensorfusion/osf_protocol.h
@@ -2,6 +2,7 @@
 #ifndef _OSF_PROTOCOL_H
 #define _OSF_PROTOCOL_H
 
+#include <linux/bits.h>
 #include <linux/types.h>
 
 #define OSF_PROTOCOL_MAJOR		0
@@ -14,7 +15,7 @@
 #define OSF_DEVICE_STATUS_LEN		20
 #define OSF_CAP_REPORT_BASE_LEN		4
 #define OSF_CAP_SENSOR_ENTRY_LEN		20
-#define OSF_CAPABILITY_FLAGS_MASK	0x00000003U
+#define OSF_CAPABILITY_FLAGS_MASK	GENMASK(1, 0)
 
 enum osf_message_type {
 	OSF_MSG_SENSOR_SAMPLE		= 0x0001,
@@ -44,6 +45,7 @@ struct osf_frame {
 	u64 sequence;
 	u64 timestamp_us;
 	u32 flags;
+	/* payload points into the caller-owned frame buffer. */
 	const u8 *payload;
 	u32 crc;
 };
-- 
2.43.0

[PATCH RFC v4 4/6] iio: osf: add stream parser

[Jinseob Kim]

Keep the parser focused on frame assembly.

Let the core decode complete frames once.

Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 drivers/iio/opensensorfusion/osf_stream.c | 38 ++++++-----------------
 1 file changed, 9 insertions(+), 29 deletions(-)

diff --git a/drivers/iio/opensensorfusion/osf_stream.c b/drivers/iio/opensensorfusion/osf_stream.c
index a2739c987..957f73716 100644
--- a/drivers/iio/opensensorfusion/osf_stream.c
+++ b/drivers/iio/opensensorfusion/osf_stream.c
@@ -62,8 +62,6 @@ static size_t osf_stream_discard_to_magic(struct osf_stream *stream)
 
 static int osf_stream_process(struct osf_stream *stream)
 {
-	struct osf_frame frame;
-	size_t decoded_len;
 	size_t discarded;
 	size_t frame_len;
 	u32 payload_len;
@@ -82,10 +80,8 @@ static int osf_stream_process(struct osf_stream *stream)
 		if (!stream->len)
 			break;
 
-		if (stream->len < OSF_FRAME_HEADER_LEN) {
-			stream->stats.partial_frames++;
+		if (stream->len < OSF_FRAME_HEADER_LEN)
 			break;
-		}
 
 		if (get_unaligned_le16(stream->buf + 6) !=
 		    OSF_FRAME_HEADER_LEN) {
@@ -106,34 +102,18 @@ static int osf_stream_process(struct osf_stream *stream)
 		}
 
 		frame_len = OSF_FRAME_HEADER_LEN + payload_len + OSF_FRAME_CRC_LEN;
-		if (stream->len < frame_len) {
-			stream->stats.partial_frames++;
+		if (stream->len < frame_len)
 			break;
-		}
-
-		ret = osf_protocol_decode_frame(stream->buf, frame_len, &frame,
-						&decoded_len);
-		if (ret) {
-			if (ret == -EBADMSG)
-				stream->stats.bad_crc_frames++;
-			stream->stats.dropped_bytes++;
-			osf_stream_drop_invalid_head(stream);
-			if (!first_err)
-				first_err = ret;
-			continue;
-		}
-
-		if (decoded_len != frame_len) {
-			stream->stats.dropped_bytes++;
-			osf_stream_drop_invalid_head(stream);
-			if (!first_err)
-				first_err = -EMSGSIZE;
-			continue;
-		}
 
 		ret = osf_core_receive_frame(stream->osf, stream->buf, frame_len);
 		if (ret) {
-			osf_stream_discard(stream, frame_len);
+			if (ret == -EBADMSG) {
+				stream->stats.bad_crc_frames++;
+				stream->stats.dropped_bytes++;
+				osf_stream_drop_invalid_head(stream);
+			} else {
+				osf_stream_discard(stream, frame_len);
+			}
 			if (!first_err)
 				first_err = ret;
 			continue;
-- 
2.43.0

[PATCH RFC v4 5/6] iio: osf: add UART transport

[Jinseob Kim]

Use the generic Open Sensor Fusion compatible.

Avoid board-specific DT compatibles.

Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 drivers/iio/opensensorfusion/Kconfig      | 4 ++--
 drivers/iio/opensensorfusion/osf_serdev.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
index 957caed2b..8b9376d28 100644
--- a/drivers/iio/opensensorfusion/Kconfig
+++ b/drivers/iio/opensensorfusion/Kconfig
@@ -10,5 +10,5 @@ config OPEN_SENSOR_FUSION
 	help
 	  Build the Open Sensor Fusion UART IIO driver.
 
-	  The driver receives OSF0 frames over a serdev UART and registers
-	  IIO devices for supported capability entries.
+	  The driver receives OSF protocol frames over a serdev UART and
+	  registers IIO devices for supported capability entries.
diff --git a/drivers/iio/opensensorfusion/osf_serdev.c b/drivers/iio/opensensorfusion/osf_serdev.c
index 1ac93548d..fd36acd1b 100644
--- a/drivers/iio/opensensorfusion/osf_serdev.c
+++ b/drivers/iio/opensensorfusion/osf_serdev.c
@@ -91,7 +91,7 @@ static void osf_serdev_remove(struct serdev_device *serdev)
 }
 
 static const struct of_device_id osf_serdev_of_match[] = {
-	{ .compatible = "opensensorfusion,osf-green" },
+	{ .compatible = "opensensorfusion,osf" },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, osf_serdev_of_match);
-- 
2.43.0

[PATCH RFC v4 6/6] iio: osf: register IIO devices from capabilities

[Jinseob Kim]

Clean up the IIO sample push path.

Drop the redundant temperature scan mask.

Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 drivers/iio/opensensorfusion/osf_core.c |  9 +++++----
 drivers/iio/opensensorfusion/osf_iio.c  | 15 +++------------
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
index e0a12de01..61ef55646 100644
--- a/drivers/iio/opensensorfusion/osf_core.c
+++ b/drivers/iio/opensensorfusion/osf_core.c
@@ -293,10 +293,11 @@ int osf_core_read_latest_sample(struct osf_device *osf, u16 sensor_type,
 		    latest->sensor_index != sensor_index)
 			continue;
 
-		if (latest->valid && channel < latest->channel_count) {
-			*value = latest->values[channel];
-			ret = 0;
-		}
+		if (!latest->valid || channel >= latest->channel_count)
+			break;
+
+		*value = latest->values[channel];
+		ret = 0;
 		break;
 	}
 	mutex_unlock(&osf->latest_lock);
diff --git a/drivers/iio/opensensorfusion/osf_iio.c b/drivers/iio/opensensorfusion/osf_iio.c
index 5e5099878..3da3f2bda 100644
--- a/drivers/iio/opensensorfusion/osf_iio.c
+++ b/drivers/iio/opensensorfusion/osf_iio.c
@@ -6,7 +6,6 @@
 #include <linux/iio/buffer.h>
 #include <linux/iio/iio.h>
 #include <linux/iio/kfifo_buf.h>
-#include <linux/string.h>
 #include <linux/types.h>
 #include <linux/units.h>
 
@@ -89,10 +88,6 @@ static const unsigned long osf_3axis_available_scan_masks[] = {
 	0
 };
 
-static const unsigned long osf_temp_available_scan_masks[] = {
-	BIT(0),
-	0
-};
 
 static const struct osf_iio_sensor_spec osf_iio_sensor_specs[] = {
 	{
@@ -125,7 +120,6 @@ static const struct osf_iio_sensor_spec osf_iio_sensor_specs[] = {
 		.name = "osf-temp",
 		.channels = osf_temp_channels,
 		.num_channels = ARRAY_SIZE(osf_temp_channels),
-		.available_scan_masks = osf_temp_available_scan_masks,
 	},
 };
 
@@ -265,21 +259,18 @@ int osf_iio_push_sample(struct iio_dev *indio_dev, const s32 *values,
 			unsigned int channel_count)
 {
 	struct osf_iio_state *state = iio_priv(indio_dev);
-	s32 scan[OSF_MAX_SAMPLE_CHANNELS] = { };
 	s64 timestamp;
 
 	if (channel_count != state->spec->channel_count)
 		return -EPROTO;
 
-	memcpy(scan, values, channel_count * sizeof(*values));
-
-	/* Buffer state can change here; IIO rechecks it during the push path. */
+	/* This is only a fast path; IIO rechecks buffer state while pushing. */
 	if (!iio_buffer_enabled(indio_dev))
 		return 0;
 
 	timestamp = iio_get_time_ns(indio_dev);
 
-	return iio_push_to_buffers_with_ts_unaligned(indio_dev, scan,
-						     channel_count * sizeof(*scan),
+	return iio_push_to_buffers_with_ts_unaligned(indio_dev, values,
+						     channel_count * sizeof(*values),
 						     timestamp);
 }
-- 
2.43.0

Re: [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver

[Conor Dooley]

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

Hey,

On Mon, Jun 08, 2026 at 08:43:37AM +0900, Jinseob Kim wrote:
> This RFC series adds an Industrial I/O driver for Open Sensor Fusion
> sensor aggregation devices.
> 
> Open Sensor Fusion is an open hardware project for sensor
> aggregation devices. The Linux IIO driver is an initial host-side
> implementation for OSF devices. The driver receives OSF frames over
> UART, uses device capability reports to discover supported sensor
> streams, and exposes supported raw sensor data through IIO devices.
> 
> This series is still marked RFC because the DT binding identity, the
> supported OSF protocol subset, and protocol extension and backward
> compatibility rules are still under review. The v4 series
> intentionally models the Linux device as a generic Open Sensor Fusion
> device rather than an OSF GREEN board-specific device. OSF GREEN is
> the prototype board used for current runtime testing, not the Linux DT
> compatible or driver identity.

Other than the fact that new revisions must not be sent as a diff on top
of a prior revision, please stop sending new versions without actually
replying to my v1 comments. In particular:

| What does "v0" mean here? Is the data format not complete yet?
| Are versions of the protocol likely to be backwards compatible?
| Will the device identify what version of the protocol it implements?

This version drops mention of v0 in the binding, but I don't know if that
means the version is fully discoverable or if you've moved to a stable
revision etc. You need to spell this stuff out to us, I'm not going to
read a github repository to figure this out - I have hundreds of patches
to get through every day. It's your responsibility to explain it all.

> The current wire format uses the OSF0 magic for protocol major
> version 0. That is kept as an internal wire-format detail for

For example, what does "OSF0 magic" mean? Is that a detectable version
number in a consistent place across revisions? Or will OSF1 magic be
incompatible. From a devicetree point of view, that's important because
if the magic is in different places in different revisions, the
compatible needs to convey what revision the device implements.

> compatibility with existing firmware, tools, and runtime smoke
> evidence. The public driver identity remains Open Sensor Fusion / OSF,
> with protocol versioning handled by the protocol major/minor fields.

This sounds like versioning is discoverable, but you need to spell this
out in the commit message for the binding.

Thanks,
Conor.

> 
> Project links:
> https://www.opensensorfusion.org/
> https://github.com/opensensorfusion
> https://github.com/opensensorfusion/opensensorfusion-hardware
> https://github.com/opensensorfusion/opensensorfusion-linux
> 
> Runtime testing so far has used an OSF GREEN prototype connected to a
> Raspberry Pi over UART. On Raspberry Pi 6.12.75+rpt-rpi-v8, the
> driver registered osf-accel, osf-gyro, osf-magn, and osf-temp from a
> capability report. Raw reads and software kfifo buffer reads were
> tested for all four IIO devices.
> 
> Changes since v3:
> 
> * Explain why the series is still RFC.
> * Move the DT binding out of iio/imu because the device is a sensor
>   aggregation device rather than an IMU.
> * Replace the OSF GREEN board-specific compatible with the generic
>   opensensorfusion,osf compatible.
> * Treat OSF GREEN as tested prototype hardware / board model
>   information, not as the Linux compatible string.
> * Rename the kernel documentation to open-sensor-fusion.rst and
>   reduce it to a driver-facing overview.
> * Add the IIO documentation toctree entry.
> * Keep full protocol details and compatibility rules in project
>   documentation rather than duplicating the full wire specification in
>   the kernel tree.
> * Avoid using OSF0 as the public driver identity; keep it only as the
>   current wire magic for protocol major version 0.
> * Add FourCC-style wire magic handling in the decoder.
> * Use GENMASK() for the capability flags mask.
> * Clarify signed 32-bit little-endian sample decoding.
> * Stop counting normal partial UART receive waits as partial frame
>   errors.
> * Avoid decoding complete frames twice in the stream/core path.
> * Remove the local scan[] bounce before
>   iio_push_to_buffers_with_ts_unaligned() and pass the values buffer
>   directly.
> * Remove the meaningless temperature available_scan_masks entry.
> * Update MAINTAINERS paths for the new binding and documentation
>   names.
> 
> Jinseob Kim (6):
>   dt-bindings: iio: add Open Sensor Fusion device
>   Documentation: iio: add Open Sensor Fusion driver overview
>   iio: osf: add protocol decoding
>   iio: osf: add stream parser
>   iio: osf: add UART transport
>   iio: osf: register IIO devices from capabilities
> 
>  .../iio/imu/opensensorfusion,osf-green.yaml   |  43 ---
>  .../bindings/iio/opensensorfusion,osf.yaml    |  43 +++
>  Documentation/iio/index.rst                   |   1 +
>  .../iio/open-sensor-fusion-protocol-v0.rst    | 308 ------------------
>  Documentation/iio/open-sensor-fusion.rst      |  62 ++++
>  MAINTAINERS                                   |  26 +-
>  drivers/iio/opensensorfusion/Kconfig          |   4 +-
>  drivers/iio/opensensorfusion/osf_core.c       |   9 +-
>  drivers/iio/opensensorfusion/osf_iio.c        |  15 +-
>  drivers/iio/opensensorfusion/osf_protocol.c   |   4 +-
>  drivers/iio/opensensorfusion/osf_protocol.h   |   4 +-
>  drivers/iio/opensensorfusion/osf_serdev.c     |   2 +-
>  drivers/iio/opensensorfusion/osf_stream.c     |  38 +--
>  13 files changed, 145 insertions(+), 414 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
>  create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
>  delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
>  create mode 100644 Documentation/iio/open-sensor-fusion.rst
> 
> -- 
> 2.43.0
> 

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

Re: [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver

[Kim Jinseob]

> Other than the fact that new revisions must not be sent as a diff on top
> of a prior revision, please stop sending new versions without actually
> replying to my v1 comments.

You are right, sorry for the noise.

I made a process mistake here. I prepared v4 on top of the previously sent
series instead of preparing it as a full standalone replacement series from
the proper base. I will not ask you to review v4 in that form, and I will
prepare the next revision as a full series from a clean base.

I also should have answered your protocol versioning questions directly before
sending another revision.

> What does "v0" mean here? Is the data format not complete yet?
> Are versions of the protocol likely to be backwards compatible?
> Will the device identify what version of the protocol it implements?

The current OSF wire header starts with a fixed 4-byte magic, "OSF0", at a
fixed offset. The same header also carries explicit protocol_major and
protocol_minor fields at fixed offsets.

For the currently supported firmware and driver, protocol_major is 0. The "0"
in "OSF0" is intended to denote the current major wire-format revision, not
the Linux driver identity.

The binding is intended for devices implementing this discoverable OSF header
layout. The driver currently supports protocol major version 0. Minor version
changes are intended to be backward compatible. Incompatible wire-format
changes require a new protocol_major value.

If a future major revision cannot be discovered using the same fixed header
layout, or is not compatible with this binding, it should use a new compatible
string.

I will spell this out in the binding commit message and documentation in the
next revision.

Jinseob