Re: [PATCH v10 0/8] iio: add Open Sensor Fusion UART support

[Jonathan Cameron <jic23@kernel.org>]

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.
> >