[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 1/5] dt-bindings: iio: add Open Sensor Fusion device

[Jinseob Kim]

Add a binding for the generic Open Sensor Fusion host interface.

Open Sensor Fusion devices report capabilities and samples over an OSF
protocol stream. Sensor channels are discovered at runtime from
capability reports instead of being described individually in Device
Tree.

The protocol version is discovered at runtime from the OSF frame header.
OSF GREEN is a product identity, and OSF0 is a wire-format magic value,
so neither is used as the Linux compatible string.

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
 .../bindings/iio/opensensorfusion,osf.yaml    | 52 +++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
 MAINTAINERS                                   |  6 +++
 3 files changed, 60 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml

diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
new file mode 100644
index 000000000000..3998390828cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
@@ -0,0 +1,52 @@
+# 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: |
+  This binding documents the generic Open Sensor Fusion host interface. Open
+  Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF protocol
+  data stream over its host interface and reports capabilities and samples for
+  multiple sensor classes. The actual sensor channels are discovered at runtime
+  from OSF capability reports instead of describing them in Device Tree. The
+  protocol version is discovered at runtime.
+
+  Public project documentation is available at:
+
+    https://github.com/opensensorfusion
+
+  OSF0, protocol_major, and protocol_minor are wire-protocol details
+  exchanged in OSF frames.
+
+allOf:
+  - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+properties:
+  compatible:
+    const: opensensorfusion,osf
+
+  vcc-supply:
+    description:
+      Regulator supplying power to the Open Sensor Fusion device.
+
+required:
+  - compatible
+  - vcc-supply
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    serial {
+        sensor {
+            compatible = "opensensorfusion,osf";
+            vcc-supply = <&vcc_sensor>;
+        };
+    };
+...
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index ba2002969373..0ec4e481c64b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1267,6 +1267,8 @@ patternProperties:
     description: OpenPandora GmbH
   "^openrisc,.*":
     description: OpenRISC.io
+  "^opensensorfusion,.*":
+    description: Open Sensor Fusion
   "^openwrt,.*":
     description: OpenWrt
   "^option,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index e033f2d564d6..ff09899bd645 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20511,6 +20511,12 @@ F:	Documentation/process/maintainer-devicetree.rst
 F:	arch/*/boot/dts/
 F:	include/dt-bindings/

+OPEN SENSOR FUSION
+M:	Jinseob Kim <kimjinseob88@gmail.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
+K:	opensensorfusion
+
 OPENCOMPUTE PTP CLOCK DRIVER
 M:	Vadim Fedorenko <vadim.fedorenko@linux.dev>
 L:	netdev@vger.kernel.org
-- 
2.43.0

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