From: Jinseob Kim <kimjinseob88@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>, linux-iio@vger.kernel.org
Cc: "David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andriy.shevchenko@intel.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: [PATCH RFC v4 2/6] Documentation: iio: add Open Sensor Fusion driver overview
Date: Mon, 8 Jun 2026 08:43:39 +0900 [thread overview]
Message-ID: <20260607234343.22109-3-kimjinseob88@gmail.com> (raw)
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
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
next prev parent reply other threads:[~2026-06-07 23:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-07 23:43 [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver Jinseob Kim
2026-06-07 23:43 ` [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device Jinseob Kim
2026-06-07 23:43 ` Jinseob Kim [this message]
2026-06-07 23:43 ` [PATCH RFC v4 3/6] iio: osf: add protocol decoding Jinseob Kim
2026-06-07 23:43 ` [PATCH RFC v4 4/6] iio: osf: add stream parser Jinseob Kim
2026-06-07 23:43 ` [PATCH RFC v4 5/6] iio: osf: add UART transport Jinseob Kim
2026-06-07 23:43 ` [PATCH RFC v4 6/6] iio: osf: register IIO devices from capabilities Jinseob Kim
2026-06-08 17:28 ` [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver Conor Dooley
2026-06-08 23:27 ` Kim Jinseob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260607234343.22109-3-kimjinseob88@gmail.com \
--to=kimjinseob88@gmail.com \
--cc=andriy.shevchenko@intel.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox