[PATCH v9 0/5] iio: add Open Sensor Fusion UART support

[PATCH v9 0/5] iio: add Open Sensor Fusion UART support

[Jinseob Kim]

This series adds the Open Sensor Fusion UART receive path and IIO
devices discovered from capability reports. It exposes accelerometer,
gyroscope, magnetometer and temperature samples through the standard
direct-read and software-buffer interfaces.

Changes since v8:
- Configure UART at 115200 baud with flow control disabled before enabling
  vcc. Acquire the regulator before opening UART, retain decoded early
  capabilities, and publish IIO children only after fallible probe setup.
  Close UART and drain receive work before releasing receive-side state.
- Give the aligned one-axis and three-axis scan structures explicit
  padding members so designated initialization also initializes the bytes
  between samples and timestamps.
- Pack selected channels into the active scan layout. Tests found that
  forcing an XYZ producer layout could give X/Y/XY consumers a value at
  the timestamp offset on the target IIO base. All nonempty masks remain
  supported.
- Quiesce pushes with a driver mutex in predisable and admit them after
  postenable. The same mutex covers the enabled check, layout access and
  complete push; it does not claim IIO buffer mode.
- Keep the latest-cache rejection rules and add KUnit tests for early
  capabilities, scan bytes/timestamps and buffer teardown.
- Tidy macro/call alignment, shorten the driver commit message, and
  document the actual receive-side compatibility constraints.

Protocol specification remains an open review question. The accessible
historical protocol-v0 drafts at OSF revision
11d11eb413e6a0e861e4d45fdccadc71c5f15c48 disagree on reserved fields,
trailing extensions and magnetometer units. They do not establish a
versioned normative specification for this implementation. The driver
requires exact known payload lengths and capability scales in IIO units,
including gauss for magnetometers. Documentation now makes those
constraints explicit. This does not establish protocol maturity or
resolve the request for a canonical compatibility specification; feedback
on that requirement is still needed before merge.

Validation:
- GCC and Clang W=1 kernel/module builds with automatic stack
  initialization disabled.
- Eight OSF KUnit cases, including all 44 sensor/mask/timestamp
  combinations, retained latest-cache regressions and controlled
  push/disable/unregister interleavings; Clang KASAN and lockdep.
- Before/after padding byte and generated-code checks, an auxiliary ASan
  demux race harness, and 16 modeled probe/unwind/retry scenarios.
- Strict checkpatch on all five patches; clean apply with matching
  intermediate/final trees and per-patch DT, documentation and code
  builds. GCC and Clang final links pass.
- Fresh ARM64 Image, modules and Pi 4 DTB built from the final tree.
- Raspberry Pi 4 with those artifacts: four IIO devices, direct RAW,
  12-second simultaneous capture, all 44 scan combinations, 400 buffer
  transitions, unload/reload and verified return to the stock kernel.

Conor's Reviewed-by is retained on the unchanged binding. Randy's earlier
documentation Tested-by is not carried forward because patch 2 changed.
LLM assistance was used for the documentation, driver fixes and tests.

Based on Jonathan's IIO testing commit
edb91bc566576f6664a3efbad6bd4205aa1d5259.

v8: https://lore.kernel.org/linux-iio/20260820050608.5440-1-kimjinseob88@gmail.com/

Jinseob Kim (5):
  dt-bindings: iio: add Open Sensor Fusion device
  Documentation: iio: add Open Sensor Fusion driver overview
  iio: osf: add protocol decoding
  iio: osf: add authenticated stream parser
  iio: osf: add UART IIO driver

 .../bindings/iio/opensensorfusion,osf.yaml    |  52 ++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 Documentation/iio/index.rst                   |   1 +
 Documentation/iio/open-sensor-fusion.rst      |  84 +++
 MAINTAINERS                                   |   8 +
 drivers/iio/Kconfig                           |   1 +
 drivers/iio/Makefile                          |   1 +
 drivers/iio/opensensorfusion/Kconfig          |  27 +
 drivers/iio/opensensorfusion/Makefile         |   7 +
 drivers/iio/opensensorfusion/osf_core.c       | 414 +++++++++++++
 drivers/iio/opensensorfusion/osf_core.h       |  73 +++
 drivers/iio/opensensorfusion/osf_core_test.c  | 577 ++++++++++++++++++
 drivers/iio/opensensorfusion/osf_iio.c        | 336 ++++++++++
 drivers/iio/opensensorfusion/osf_iio.h        |  22 +
 drivers/iio/opensensorfusion/osf_iio_test.c   | 325 ++++++++++
 drivers/iio/opensensorfusion/osf_protocol.c   | 224 +++++++
 drivers/iio/opensensorfusion/osf_protocol.h   | 101 +++
 drivers/iio/opensensorfusion/osf_serdev.c     | 162 +++++
 drivers/iio/opensensorfusion/osf_stream.c     | 231 +++++++
 drivers/iio/opensensorfusion/osf_stream.h     |  53 ++
 20 files changed, 2701 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
 create mode 100644 Documentation/iio/open-sensor-fusion.rst
 create mode 100644 drivers/iio/opensensorfusion/Kconfig
 create mode 100644 drivers/iio/opensensorfusion/Makefile
 create mode 100644 drivers/iio/opensensorfusion/osf_core.c
 create mode 100644 drivers/iio/opensensorfusion/osf_core.h
 create mode 100644 drivers/iio/opensensorfusion/osf_core_test.c
 create mode 100644 drivers/iio/opensensorfusion/osf_iio.c
 create mode 100644 drivers/iio/opensensorfusion/osf_iio.h
 create mode 100644 drivers/iio/opensensorfusion/osf_iio_test.c
 create mode 100644 drivers/iio/opensensorfusion/osf_protocol.c
 create mode 100644 drivers/iio/opensensorfusion/osf_protocol.h
 create mode 100644 drivers/iio/opensensorfusion/osf_serdev.c
 create mode 100644 drivers/iio/opensensorfusion/osf_stream.c
 create mode 100644 drivers/iio/opensensorfusion/osf_stream.h


base-commit: edb91bc566576f6664a3efbad6bd4205aa1d5259
-- 
2.43.0

[PATCH v9 2/5] Documentation: iio: add Open Sensor Fusion driver overview

[Jinseob Kim]

Document the Linux IIO mapping for Open Sensor Fusion devices.

The overview explains that sensor channels are discovered at runtime
from mandatory capability reports. It also documents that OSF0 is a
wire-format detail and that protocol_major and protocol_minor carry
protocol compatibility information.

Assisted-by: LLM
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 Documentation/iio/index.rst              |  1 +
 Documentation/iio/open-sensor-fusion.rst | 84 ++++++++++++++++++++++++
 MAINTAINERS                              |  1 +
 3 files changed, 86 insertions(+)
 create mode 100644 Documentation/iio/open-sensor-fusion.rst

diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index b02b879b053a..c2b7963348fd 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -40,4 +40,5 @@ Industrial I/O Kernel Drivers
    adxl345
    bno055
    ep93xx_adc
+   open-sensor-fusion
    opt4060
diff --git a/Documentation/iio/open-sensor-fusion.rst
b/Documentation/iio/open-sensor-fusion.rst
new file mode 100644
index 000000000000..15d41202eb66
--- /dev/null
+++ b/Documentation/iio/open-sensor-fusion.rst
@@ -0,0 +1,84 @@
+.. 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 and registers matching IIO
+devices for the sensor classes supported by the driver. The actual sensor
+channels are discovered at runtime from mandatory OSF capability reports.
+
+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.
Devices using the
+``opensensorfusion,osf`` compatible are expected to provide
+``CAPABILITY_REPORT`` messages so the host can 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 IIO receive path.
+The current wire magic is ``OSF0``; that string is a wire-format detail and is
+not the Linux driver identity. Device Tree keeps the generic
+``opensensorfusion,osf`` compatible rather than naming a product such as OSF
+GREEN or a wire magic value.
+
+Protocol versioning is carried by the ``protocol_major`` and ``protocol_minor``
+fields at fixed offsets in the OSF frame header. The driver currently
+supports ``protocol_major`` 0. ``protocol_minor`` changes within major version
+0 are intended to remain backward-compatible within the fixed header layout.
+Incompatible wire-format changes require a new ``protocol_major``. A future
+device that cannot expose compatible version discovery through that fixed
+header layout would need a different Device Tree compatible.
+
+The 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
+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 driver does not correlate the device timestamp with the host IIO
+clock.
+
+Compatibility Notes
+-------------------
+
+This overview describes the implemented receive path, not a normative wire
+specification. A publicly versioned specification covering reserved fields,
+extensions and physical scale units remains needed for interoperability review.
+
+The decoder requires the fixed header size and the exact payload lengths of
+known messages. It ignores unsupported protocol majors, unknown message types
+and frames with nonzero header reserved fields. Unsupported capability entries
+are skipped individually; malformed known payloads are rejected. Appending data
+to an existing known message is therefore not a compatible extension for this
+receiver.
+
+IIO scale is taken from the initial capability report and is not updated by
+sample frames. Devices must supply scales in the units required by each IIO
+channel type, including gauss for magnetometers. Historical OSF draft documents
+differ on reserved-field handling, trailing extensions and magnetometer units;
+those drafts do not establish a canonical specification for this driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index ff09899bd645..0c9c322162b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20515,6 +20515,7 @@ OPEN SENSOR FUSION
 M:	Jinseob Kim <kimjinseob88@gmail.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
+F:	Documentation/iio/open-sensor-fusion.rst
 K:	opensensorfusion

 OPENCOMPUTE PTP CLOCK DRIVER
-- 
2.43.0

Re: [PATCH v9 2/5] Documentation: iio: add Open Sensor Fusion driver overview

[Randy Dunlap]

Hi,

On 9/9/26 8:05 AM, Jinseob Kim wrote:
> Document the Linux IIO mapping for Open Sensor Fusion devices.
> 
> The overview explains that sensor channels are discovered at runtime
> from mandatory capability reports. It also documents that OSF0 is a
> wire-format detail and that protocol_major and protocol_minor carry
> protocol compatibility information.
> 
> Assisted-by: LLM
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> ---
>  Documentation/iio/index.rst              |  1 +
>  Documentation/iio/open-sensor-fusion.rst | 84 ++++++++++++++++++++++++
>  MAINTAINERS                              |  1 +
>  3 files changed, 86 insertions(+)
>  create mode 100644 Documentation/iio/open-sensor-fusion.rst
> 

What email client did you use to send this patch?
It is wrapping (longer) lines for you, in a way that's not good.
It causes malformed patches.
You can see it below or at
https://lore.kernel.org/linux-doc/CALMSewK17jG3MXTHv4Rj+tFVriw9+tqNuAMcX4KGQGy5NQP_MQ@mail.gmail.com/T/#u


> diff --git a/Documentation/iio/open-sensor-fusion.rst
> b/Documentation/iio/open-sensor-fusion.rst
> new file mode 100644
> index 000000000000..15d41202eb66
> --- /dev/null
> +++ b/Documentation/iio/open-sensor-fusion.rst
> @@ -0,0 +1,84 @@
> +.. 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 and registers matching IIO
> +devices for the sensor classes supported by the driver. The actual sensor
> +channels are discovered at runtime from mandatory OSF capability reports.
> +
> +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.
> Devices using the

^^^ Should be one line, not two.

> +``opensensorfusion,osf`` compatible are expected to provide
> +``CAPABILITY_REPORT`` messages so the host can discover which sensor
> streams are

Same.

> +available. Device Tree describes the attached OSF sensor aggregation
> hub; it does

Same.

> +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 IIO receive path.
> +The current wire magic is ``OSF0``; that string is a wire-format detail and is
> +not the Linux driver identity. Device Tree keeps the generic
> +``opensensorfusion,osf`` compatible rather than naming a product such as OSF
> +GREEN or a wire magic value.
> +
> +Protocol versioning is carried by the ``protocol_major`` and ``protocol_minor``
> +fields at fixed offsets in the OSF frame header. The driver currently
> +supports ``protocol_major`` 0. ``protocol_minor`` changes within major version
> +0 are intended to remain backward-compatible within the fixed header layout.
> +Incompatible wire-format changes require a new ``protocol_major``. A future
> +device that cannot expose compatible version discovery through that fixed
> +header layout would need a different Device Tree compatible.
> +
> +The 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
> +Linux IIO receive path.
> +
> +Timestamps
> +----------
> +
> +OSF frames include a device-side ``timestamp_us`` field. Buffered IIO
> samples use

Same.

> +an IIO timestamp captured on the host when samples are pushed to IIO buffers.
> +The driver does not correlate the device timestamp with the host IIO
> +clock.
> +
> +Compatibility Notes
> +-------------------
> +
> +This overview describes the implemented receive path, not a normative wire
> +specification. A publicly versioned specification covering reserved fields,
> +extensions and physical scale units remains needed for interoperability review.
> +
> +The decoder requires the fixed header size and the exact payload lengths of
> +known messages. It ignores unsupported protocol majors, unknown message types
> +and frames with nonzero header reserved fields. Unsupported capability entries
> +are skipped individually; malformed known payloads are rejected. Appending data
> +to an existing known message is therefore not a compatible extension for this
> +receiver.
> +
> +IIO scale is taken from the initial capability report and is not updated by
> +sample frames. Devices must supply scales in the units required by each IIO
> +channel type, including gauss for magnetometers. Historical OSF draft documents
> +differ on reserved-field handling, trailing extensions and magnetometer units;
> +those drafts do not establish a canonical specification for this driver.

There is some help for various email clients in Documentation/process/email-clients.rst
that may help you (or not).

-- 
~Randy

Re: [PATCH v9 2/5] Documentation: iio: add Open Sensor Fusion driver overview

[Kim Jinseob]

Hi Randy,

> What email client did you use to send this patch?

I used a tool that sends through the Gmail API.

I'll check the received raw messages to investigate the line wrapping.

Thanks,

Jinseob


2026년 9월 10일 (목) 오전 1:02, Randy Dunlap <rdunlap@infradead.org>님이 작성:
>
> Hi,
>
> On 9/9/26 8:05 AM, Jinseob Kim wrote:
> > Document the Linux IIO mapping for Open Sensor Fusion devices.
> >
> > The overview explains that sensor channels are discovered at runtime
> > from mandatory capability reports. It also documents that OSF0 is a
> > wire-format detail and that protocol_major and protocol_minor carry
> > protocol compatibility information.
> >
> > Assisted-by: LLM
> > Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> > ---
> >  Documentation/iio/index.rst              |  1 +
> >  Documentation/iio/open-sensor-fusion.rst | 84 ++++++++++++++++++++++++
> >  MAINTAINERS                              |  1 +
> >  3 files changed, 86 insertions(+)
> >  create mode 100644 Documentation/iio/open-sensor-fusion.rst
> >
>
> What email client did you use to send this patch?
> It is wrapping (longer) lines for you, in a way that's not good.
> It causes malformed patches.
> You can see it below or at
> https://lore.kernel.org/linux-doc/CALMSewK17jG3MXTHv4Rj+tFVriw9+tqNuAMcX4KGQGy5NQP_MQ@mail.gmail.com/T/#u
>
>
> > diff --git a/Documentation/iio/open-sensor-fusion.rst
> > b/Documentation/iio/open-sensor-fusion.rst
> > new file mode 100644
> > index 000000000000..15d41202eb66
> > --- /dev/null
> > +++ b/Documentation/iio/open-sensor-fusion.rst
> > @@ -0,0 +1,84 @@
> > +.. 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 and registers matching IIO
> > +devices for the sensor classes supported by the driver. The actual sensor
> > +channels are discovered at runtime from mandatory OSF capability reports.
> > +
> > +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.
> > Devices using the
>
> ^^^ Should be one line, not two.
>
> > +``opensensorfusion,osf`` compatible are expected to provide
> > +``CAPABILITY_REPORT`` messages so the host can discover which sensor
> > streams are
>
> Same.
>
> > +available. Device Tree describes the attached OSF sensor aggregation
> > hub; it does
>
> Same.
>
> > +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 IIO receive path.
> > +The current wire magic is ``OSF0``; that string is a wire-format detail and is
> > +not the Linux driver identity. Device Tree keeps the generic
> > +``opensensorfusion,osf`` compatible rather than naming a product such as OSF
> > +GREEN or a wire magic value.
> > +
> > +Protocol versioning is carried by the ``protocol_major`` and ``protocol_minor``
> > +fields at fixed offsets in the OSF frame header. The driver currently
> > +supports ``protocol_major`` 0. ``protocol_minor`` changes within major version
> > +0 are intended to remain backward-compatible within the fixed header layout.
> > +Incompatible wire-format changes require a new ``protocol_major``. A future
> > +device that cannot expose compatible version discovery through that fixed
> > +header layout would need a different Device Tree compatible.
> > +
> > +The 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
> > +Linux IIO receive path.
> > +
> > +Timestamps
> > +----------
> > +
> > +OSF frames include a device-side ``timestamp_us`` field. Buffered IIO
> > samples use
>
> Same.
>
> > +an IIO timestamp captured on the host when samples are pushed to IIO buffers.
> > +The driver does not correlate the device timestamp with the host IIO
> > +clock.
> > +
> > +Compatibility Notes
> > +-------------------
> > +
> > +This overview describes the implemented receive path, not a normative wire
> > +specification. A publicly versioned specification covering reserved fields,
> > +extensions and physical scale units remains needed for interoperability review.
> > +
> > +The decoder requires the fixed header size and the exact payload lengths of
> > +known messages. It ignores unsupported protocol majors, unknown message types
> > +and frames with nonzero header reserved fields. Unsupported capability entries
> > +are skipped individually; malformed known payloads are rejected. Appending data
> > +to an existing known message is therefore not a compatible extension for this
> > +receiver.
> > +
> > +IIO scale is taken from the initial capability report and is not updated by
> > +sample frames. Devices must supply scales in the units required by each IIO
> > +channel type, including gauss for magnetometers. Historical OSF draft documents
> > +differ on reserved-field handling, trailing extensions and magnetometer units;
> > +those drafts do not establish a canonical specification for this driver.
>
> There is some help for various email clients in Documentation/process/email-clients.rst
> that may help you (or not).
>
> --
> ~Randy
>

Re: [PATCH v9 0/5] iio: add Open Sensor Fusion UART support

[Jonathan Cameron]

Hi,

> Protocol specification remains an open review question. The accessible
> historical protocol-v0 drafts at OSF revision
> 11d11eb413e6a0e861e4d45fdccadc71c5f15c48 disagree on reserved fields,
> trailing extensions and magnetometer units. They do not establish a
> versioned normative specification for this implementation. The driver
> requires exact known payload lengths and capability scales in IIO units,
> including gauss for magnetometers. Documentation now makes those
> constraints explicit. This does not establish protocol maturity or
> resolve the request for a canonical compatibility specification; feedback
> on that requirement is still needed before merge.

Please put this statement right at the top of your cover letter.
Probably in shorter form.  "Specification still undergoing review,"

This changes this puts a big external dependency on the patch set
(I'd have preferred this remained an RFC but I know others asked for
 that to change!)

Given limited review capacity I want people to make a decision on whether
they wish to review knowing that the specification is still potentially
in flux.

A such I for one am going to hold off on reviewing new versions until
you post a patch that at the top of the cover letter says.
"Specification is now reviewed and has moved to the stage where we can
 rely on it as being stable + ideally a pointer to an errata process so
 we have a grasp on how specification fixes are handled.

Thanks and good luck getting to that point!

Jonathan