Specification status: OSF-D2H 0.0 spec-1 has completed project technical
stability review, has been adopted by the project owner, and is published
as a fixed specification.

Canonical specification:
https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/spec/osf-d2h-0.0.md

Errata process:
https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/errata/README.md

Current adoption/publication record:
https://github.com/opensensorfusion/opensensorfusion-protocol/blob/0cabccf63ac01d0eb82dd9882739ff58eed4a76c/reviews/publication-record-20260918.md

The specification was frozen before adoption/publication, so its embedded
status snapshot is intentionally historical. The dated publication record
above establishes the current adopted/public state. This is project review
and adoption, not an external maintainer approval.

This series adds the Open Sensor Fusion UART receive path and IIO devices
discovered from capability reports. It exposes accelerometer, gyroscope,
magnetometer and temperature data through RAW/SCALE and buffered scans.
Device Tree describes the sensor hub; its individual streams are discovered
at runtime.

The receiver validates supported descriptors and sample scales, keeps
discovery open after empty or unsupported initial inventories, and checks
repeated inventories before allowing new data to use registered metadata.
A supported descriptor changing meaning faults the session until an
explicit teardown and rebind. Existing v9 cache, scan-layout and buffer
lifetime fixes are retained.

Based on Jonathan Cameron's IIO testing branch:
69fa76f0af3414cc189c3b0b807cb59e327ecc00

Changes since v9:
- Publish and reference the reviewed/adopted OSF-D2H 0.0 specification,
  errata process and dated publication evidence.
- Tolerate reserved padding, validate descriptor/sample scales, keep
  discovery open after empty/unsupported reports, and compare repeated
  capability reports.
- Fail closed on changed descriptor meaning instead of publishing data
  with stale metadata.
- Add focused KUnit coverage for these lifecycle and validation cases.
- Use managed UART/IIO/power teardown and dev_warn_probe() for the
  controller baud-rate warning, addressing Andy's probe-path feedback.
- Split the former combined UART/core/IIO driver patch into transport/core,
  IIO registration, core KUnit, and IIO KUnit patches following review.
- Use validated/unvalidated terminology for framing/CRC results throughout
  the stream/core/transport code, tests and diagnostics. CRC detects
  accidental corruption; it does not provide cryptographic authentication.

Prior validation on the identical source tree:
identical source tree evidence reused; no builds rerun for DCO packaging.
- All eight intermediate apply/config/relevant builds.
- Independent transport/core and IIO module link/MODPOST.
- GCC/Clang W=1 vmlinux and modules.
- GCC and Clang KUnit: core 16 + IIO 2, all 18 pass in each run.
- Core-only intermediate KUnit: all 16 pass.
- ARM64 Image, selected OSF module and Pi4 DTB.
- Targeted DT binding/style and IIO documentation.

The terminology-only diff was verified mechanically. Wire semantics and
data-path behavior are unchanged; the receive diagnostic key is validated=.
Hardware testing was not repeated for this terminology revision or this
post-DCO packaging audit; previous hardware evidence remains historical.

Human DCO is complete. No email has been sent.

Jinseob Kim (8):
  dt-bindings: iio: add Open Sensor Fusion device
  Documentation: iio: add Open Sensor Fusion driver overview
  iio: osf: add protocol decoding
  iio: osf: add validated stream parser
  iio: osf: add UART transport and core receive path
  iio: osf: add IIO devices from capability reports
  iio: osf: add core KUnit tests
  iio: osf: add IIO KUnit tests

 .../bindings/iio/opensensorfusion,osf.yaml    |   52 +
 .../devicetree/bindings/vendor-prefixes.yaml  |    2 +
 Documentation/iio/index.rst                   |    1 +
 Documentation/iio/open-sensor-fusion.rst      |   77 ++
 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       |  465 ++++++++
 drivers/iio/opensensorfusion/osf_core.h       |   75 ++
 drivers/iio/opensensorfusion/osf_core_test.c  | 1046 +++++++++++++++++
 drivers/iio/opensensorfusion/osf_iio.c        |  338 ++++++
 drivers/iio/opensensorfusion/osf_iio.h        |   22 +
 drivers/iio/opensensorfusion/osf_iio_test.c   |  325 +++++
 drivers/iio/opensensorfusion/osf_protocol.c   |  215 ++++
 drivers/iio/opensensorfusion/osf_protocol.h   |  101 ++
 drivers/iio/opensensorfusion/osf_serdev.c     |  148 +++
 drivers/iio/opensensorfusion/osf_stream.c     |  231 ++++
 drivers/iio/opensensorfusion/osf_stream.h     |   53 +
 20 files changed, 3195 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: 69fa76f0af3414cc189c3b0b807cb59e327ecc00
-- 
2.43.0

On Sat, 19 Sep 2026 03:24:38 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:

> Specification status: OSF-D2H 0.0 spec-1 has completed project technical
> stability review, has been adopted by the project owner, and is published
> as a fixed specification.
> 
> Canonical specification:
> https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/spec/osf-d2h-0.0.md
> 
> Errata process:
> https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/errata/README.md
> 
> Current adoption/publication record:
> https://github.com/opensensorfusion/opensensorfusion-protocol/blob/0cabccf63ac01d0eb82dd9882739ff58eed4a76c/reviews/publication-record-20260918.md
> 
> The specification was frozen before adoption/publication, so its embedded
> status snapshot is intentionally historical. The dated publication record
> above establishes the current adopted/public state. This is project review
> and adoption, not an external maintainer approval.
> 
> This series adds the Open Sensor Fusion UART receive path and IIO devices
> discovered from capability reports. It exposes accelerometer, gyroscope,
> magnetometer and temperature data through RAW/SCALE and buffered scans.
> Device Tree describes the sensor hub; its individual streams are discovered
> at runtime.
> 
> The receiver validates supported descriptors and sample scales, keeps
> discovery open after empty or unsupported initial inventories, and checks
> repeated inventories before allowing new data to use registered metadata.
> A supported descriptor changing meaning faults the session until an
> explicit teardown and rebind. Existing v9 cache, scan-layout and buffer
> lifetime fixes are retained.
> 
> Based on Jonathan Cameron's IIO testing branch:
> 69fa76f0af3414cc189c3b0b807cb59e327ecc00
> 
> Changes since v9:
> - Publish and reference the reviewed/adopted OSF-D2H 0.0 specification,
>   errata process and dated publication evidence.
> - Tolerate reserved padding, validate descriptor/sample scales, keep
>   discovery open after empty/unsupported reports, and compare repeated
>   capability reports.
> - Fail closed on changed descriptor meaning instead of publishing data
>   with stale metadata.
> - Add focused KUnit coverage for these lifecycle and validation cases.
> - Use managed UART/IIO/power teardown and dev_warn_probe() for the
>   controller baud-rate warning, addressing Andy's probe-path feedback.
> - Split the former combined UART/core/IIO driver patch into transport/core,
>   IIO registration, core KUnit, and IIO KUnit patches following review.
> - Use validated/unvalidated terminology for framing/CRC results throughout
>   the stream/core/transport code, tests and diagnostics. CRC detects
>   accidental corruption; it does not provide cryptographic authentication.
> 
> Prior validation on the identical source tree:
> identical source tree evidence reused; no builds rerun for DCO packaging.
> - All eight intermediate apply/config/relevant builds.
> - Independent transport/core and IIO module link/MODPOST.
> - GCC/Clang W=1 vmlinux and modules.
> - GCC and Clang KUnit: core 16 + IIO 2, all 18 pass in each run.
> - Core-only intermediate KUnit: all 16 pass.
> - ARM64 Image, selected OSF module and Pi4 DTB.
> - Targeted DT binding/style and IIO documentation.
> 
> The terminology-only diff was verified mechanically. Wire semantics and
> data-path behavior are unchanged; the receive diagnostic key is validated=.
> Hardware testing was not repeated for this terminology revision or this
> post-DCO packaging audit; previous hardware evidence remains historical.
> 
> Human DCO is complete. No email has been sent.
> 
> Jinseob Kim (8):
>   dt-bindings: iio: add Open Sensor Fusion device
>   Documentation: iio: add Open Sensor Fusion driver overview
>   iio: osf: add protocol decoding
>   iio: osf: add validated stream parser
>   iio: osf: add UART transport and core receive path
>   iio: osf: add IIO devices from capability reports
>   iio: osf: add core KUnit tests
>   iio: osf: add IIO KUnit tests
> 
>  .../bindings/iio/opensensorfusion,osf.yaml    |   52 +
>  .../devicetree/bindings/vendor-prefixes.yaml  |    2 +
>  Documentation/iio/index.rst                   |    1 +
>  Documentation/iio/open-sensor-fusion.rst      |   77 ++
>  MAINTAINERS                                   |    8 +
>  drivers/iio/Kconfig                           |    1 +
>  drivers/iio/Makefile                          |    1 +
>  drivers/iio/opensensorfusion/Kconfig          |   27 +
Any reason not to push it one level deeper and put it under IMUs?
I'm not that keen to grow the top level menu for this as all the
other entries are about type of sensor, not one specific sensor.

> Any reason not to push it one level deeper and put it under IMUs?
> I'm not that keen to grow the top level menu for this as all the
> other entries are about type of sensor, not one specific sensor.

Yes, I agree that adding an Open Sensor Fusion entry at the IIO top
level is not ideal.

My hesitation with putting it under imu/ is that Open Sensor Fusion is
not intended to be an IMU. The current Linux profile exposes
accelerometer, gyroscope, magnetometer and temperature data, but the
hardware/firmware architecture is a general sensor hub and fusion
device. Other OSF hardware variants can aggregate sources such as
pressure sensors, GNSS/RTK-GNSS, motor encoders and LiDAR in addition
to inertial sensors.

Would drivers/iio/common/opensensorfusion/ be a better fit?

There are already sensor-hub/common implementations such as the
ChromeOS EC sensors and Samsung SSP sensor hub under
drivers/iio/common/.

That would avoid growing the IIO top-level menu without classifying
the device itself as an IMU.

Thanks,
Jinseob

2026년 9월 20일 (일) 오전 11:05, Jonathan Cameron <jic23@kernel.org>님이 작성:
>
> On Sat, 19 Sep 2026 03:24:38 +0900
> Jinseob Kim <kimjinseob88@gmail.com> wrote:
>
> > Specification status: OSF-D2H 0.0 spec-1 has completed project technical
> > stability review, has been adopted by the project owner, and is published
> > as a fixed specification.
> >
> > Canonical specification:
> > https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/spec/osf-d2h-0.0.md
> >
> > Errata process:
> > https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/errata/README.md
> >
> > Current adoption/publication record:
> > https://github.com/opensensorfusion/opensensorfusion-protocol/blob/0cabccf63ac01d0eb82dd9882739ff58eed4a76c/reviews/publication-record-20260918.md
> >
> > The specification was frozen before adoption/publication, so its embedded
> > status snapshot is intentionally historical. The dated publication record
> > above establishes the current adopted/public state. This is project review
> > and adoption, not an external maintainer approval.
> >
> > This series adds the Open Sensor Fusion UART receive path and IIO devices
> > discovered from capability reports. It exposes accelerometer, gyroscope,
> > magnetometer and temperature data through RAW/SCALE and buffered scans.
> > Device Tree describes the sensor hub; its individual streams are discovered
> > at runtime.
> >
> > The receiver validates supported descriptors and sample scales, keeps
> > discovery open after empty or unsupported initial inventories, and checks
> > repeated inventories before allowing new data to use registered metadata.
> > A supported descriptor changing meaning faults the session until an
> > explicit teardown and rebind. Existing v9 cache, scan-layout and buffer
> > lifetime fixes are retained.
> >
> > Based on Jonathan Cameron's IIO testing branch:
> > 69fa76f0af3414cc189c3b0b807cb59e327ecc00
> >
> > Changes since v9:
> > - Publish and reference the reviewed/adopted OSF-D2H 0.0 specification,
> >   errata process and dated publication evidence.
> > - Tolerate reserved padding, validate descriptor/sample scales, keep
> >   discovery open after empty/unsupported reports, and compare repeated
> >   capability reports.
> > - Fail closed on changed descriptor meaning instead of publishing data
> >   with stale metadata.
> > - Add focused KUnit coverage for these lifecycle and validation cases.
> > - Use managed UART/IIO/power teardown and dev_warn_probe() for the
> >   controller baud-rate warning, addressing Andy's probe-path feedback.
> > - Split the former combined UART/core/IIO driver patch into transport/core,
> >   IIO registration, core KUnit, and IIO KUnit patches following review.
> > - Use validated/unvalidated terminology for framing/CRC results throughout
> >   the stream/core/transport code, tests and diagnostics. CRC detects
> >   accidental corruption; it does not provide cryptographic authentication.
> >
> > Prior validation on the identical source tree:
> > identical source tree evidence reused; no builds rerun for DCO packaging.
> > - All eight intermediate apply/config/relevant builds.
> > - Independent transport/core and IIO module link/MODPOST.
> > - GCC/Clang W=1 vmlinux and modules.
> > - GCC and Clang KUnit: core 16 + IIO 2, all 18 pass in each run.
> > - Core-only intermediate KUnit: all 16 pass.
> > - ARM64 Image, selected OSF module and Pi4 DTB.
> > - Targeted DT binding/style and IIO documentation.
> >
> > The terminology-only diff was verified mechanically. Wire semantics and
> > data-path behavior are unchanged; the receive diagnostic key is validated=.
> > Hardware testing was not repeated for this terminology revision or this
> > post-DCO packaging audit; previous hardware evidence remains historical.
> >
> > Human DCO is complete. No email has been sent.
> >
> > Jinseob Kim (8):
> >   dt-bindings: iio: add Open Sensor Fusion device
> >   Documentation: iio: add Open Sensor Fusion driver overview
> >   iio: osf: add protocol decoding
> >   iio: osf: add validated stream parser
> >   iio: osf: add UART transport and core receive path
> >   iio: osf: add IIO devices from capability reports
> >   iio: osf: add core KUnit tests
> >   iio: osf: add IIO KUnit tests
> >
> >  .../bindings/iio/opensensorfusion,osf.yaml    |   52 +
> >  .../devicetree/bindings/vendor-prefixes.yaml  |    2 +
> >  Documentation/iio/index.rst                   |    1 +
> >  Documentation/iio/open-sensor-fusion.rst      |   77 ++
> >  MAINTAINERS                                   |    8 +
> >  drivers/iio/Kconfig                           |    1 +
> >  drivers/iio/Makefile                          |    1 +
> >  drivers/iio/opensensorfusion/Kconfig          |   27 +
> Any reason not to push it one level deeper and put it under IMUs?
> I'm not that keen to grow the top level menu for this as all the
> other entries are about type of sensor, not one specific sensor.
>

On Sun, 20 Sep 2026 13:22:58 +0900
Kim Jinseob <kimjinseob88@gmail.com> wrote:

> > Any reason not to push it one level deeper and put it under IMUs?
> > I'm not that keen to grow the top level menu for this as all the
> > other entries are about type of sensor, not one specific sensor.  
> 
> Yes, I agree that adding an Open Sensor Fusion entry at the IIO top
> level is not ideal.
> 
> My hesitation with putting it under imu/ is that Open Sensor Fusion is
> not intended to be an IMU. The current Linux profile exposes
> accelerometer, gyroscope, magnetometer and temperature data, but the
> hardware/firmware architecture is a general sensor hub and fusion
> device. Other OSF hardware variants can aggregate sources such as
> pressure sensors, GNSS/RTK-GNSS, motor encoders and LiDAR in addition
> to inertial sensors.
> 
> Would drivers/iio/common/opensensorfusion/ be a better fit?
> 
> There are already sensor-hub/common implementations such as the
> ChromeOS EC sensors and Samsung SSP sensor hub under
> drivers/iio/common/.
> 
> That would avoid growing the IIO top-level menu without classifying
> the device itself as an IMU.

Lets just start a new directory (maybe move some others later) for
sensorhubs.  Common is meant for library type modules rather than
this purpose.  Often those are parts of sensorhubs.

So how about
driver/iio/sensorhubs/osf/
?
> 
> Thanks,
> Jinseob
> 
> 2026년 9월 20일 (일) 오전 11:05, Jonathan Cameron <jic23@kernel.org>님이 작성:
> >
> > On Sat, 19 Sep 2026 03:24:38 +0900
> > Jinseob Kim <kimjinseob88@gmail.com> wrote:
> >  
> > > Specification status: OSF-D2H 0.0 spec-1 has completed project technical
> > > stability review, has been adopted by the project owner, and is published
> > > as a fixed specification.
> > >
> > > Canonical specification:
> > > https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/spec/osf-d2h-0.0.md
> > >
> > > Errata process:
> > > https://github.com/opensensorfusion/opensensorfusion-protocol/blob/ca9cdea1ae550c2b4d6f29f87877adae99470744/errata/README.md
> > >
> > > Current adoption/publication record:
> > > https://github.com/opensensorfusion/opensensorfusion-protocol/blob/0cabccf63ac01d0eb82dd9882739ff58eed4a76c/reviews/publication-record-20260918.md
> > >
> > > The specification was frozen before adoption/publication, so its embedded
> > > status snapshot is intentionally historical. The dated publication record
> > > above establishes the current adopted/public state. This is project review
> > > and adoption, not an external maintainer approval.
> > >
> > > This series adds the Open Sensor Fusion UART receive path and IIO devices
> > > discovered from capability reports. It exposes accelerometer, gyroscope,
> > > magnetometer and temperature data through RAW/SCALE and buffered scans.
> > > Device Tree describes the sensor hub; its individual streams are discovered
> > > at runtime.
> > >
> > > The receiver validates supported descriptors and sample scales, keeps
> > > discovery open after empty or unsupported initial inventories, and checks
> > > repeated inventories before allowing new data to use registered metadata.
> > > A supported descriptor changing meaning faults the session until an
> > > explicit teardown and rebind. Existing v9 cache, scan-layout and buffer
> > > lifetime fixes are retained.
> > >
> > > Based on Jonathan Cameron's IIO testing branch:
> > > 69fa76f0af3414cc189c3b0b807cb59e327ecc00
> > >
> > > Changes since v9:
> > > - Publish and reference the reviewed/adopted OSF-D2H 0.0 specification,
> > >   errata process and dated publication evidence.
> > > - Tolerate reserved padding, validate descriptor/sample scales, keep
> > >   discovery open after empty/unsupported reports, and compare repeated
> > >   capability reports.
> > > - Fail closed on changed descriptor meaning instead of publishing data
> > >   with stale metadata.
> > > - Add focused KUnit coverage for these lifecycle and validation cases.
> > > - Use managed UART/IIO/power teardown and dev_warn_probe() for the
> > >   controller baud-rate warning, addressing Andy's probe-path feedback.
> > > - Split the former combined UART/core/IIO driver patch into transport/core,
> > >   IIO registration, core KUnit, and IIO KUnit patches following review.
> > > - Use validated/unvalidated terminology for framing/CRC results throughout
> > >   the stream/core/transport code, tests and diagnostics. CRC detects
> > >   accidental corruption; it does not provide cryptographic authentication.
> > >
> > > Prior validation on the identical source tree:
> > > identical source tree evidence reused; no builds rerun for DCO packaging.
> > > - All eight intermediate apply/config/relevant builds.
> > > - Independent transport/core and IIO module link/MODPOST.
> > > - GCC/Clang W=1 vmlinux and modules.
> > > - GCC and Clang KUnit: core 16 + IIO 2, all 18 pass in each run.
> > > - Core-only intermediate KUnit: all 16 pass.
> > > - ARM64 Image, selected OSF module and Pi4 DTB.
> > > - Targeted DT binding/style and IIO documentation.
> > >
> > > The terminology-only diff was verified mechanically. Wire semantics and
> > > data-path behavior are unchanged; the receive diagnostic key is validated=.
> > > Hardware testing was not repeated for this terminology revision or this
> > > post-DCO packaging audit; previous hardware evidence remains historical.
> > >
> > > Human DCO is complete. No email has been sent.
> > >
> > > Jinseob Kim (8):
> > >   dt-bindings: iio: add Open Sensor Fusion device
> > >   Documentation: iio: add Open Sensor Fusion driver overview
> > >   iio: osf: add protocol decoding
> > >   iio: osf: add validated stream parser
> > >   iio: osf: add UART transport and core receive path
> > >   iio: osf: add IIO devices from capability reports
> > >   iio: osf: add core KUnit tests
> > >   iio: osf: add IIO KUnit tests
> > >
> > >  .../bindings/iio/opensensorfusion,osf.yaml    |   52 +
> > >  .../devicetree/bindings/vendor-prefixes.yaml  |    2 +
> > >  Documentation/iio/index.rst                   |    1 +
> > >  Documentation/iio/open-sensor-fusion.rst      |   77 ++
> > >  MAINTAINERS                                   |    8 +
> > >  drivers/iio/Kconfig                           |    1 +
> > >  drivers/iio/Makefile                          |    1 +
> > >  drivers/iio/opensensorfusion/Kconfig          |   27 +  
> > Any reason not to push it one level deeper and put it under IMUs?
> > I'm not that keen to grow the top level menu for this as all the
> > other entries are about type of sensor, not one specific sensor.
> >