Re: [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 6072 bytes --]

Hey,

On Mon, Jun 08, 2026 at 08:43:37AM +0900, Jinseob Kim wrote:
> This RFC series adds an Industrial I/O driver for Open Sensor Fusion
> sensor aggregation devices.
> 
> Open Sensor Fusion is an open hardware project for sensor
> aggregation devices. The Linux IIO driver is an initial host-side
> implementation for OSF devices. The driver receives OSF frames over
> UART, uses device capability reports to discover supported sensor
> streams, and exposes supported raw sensor data through IIO devices.
> 
> This series is still marked RFC because the DT binding identity, the
> supported OSF protocol subset, and protocol extension and backward
> compatibility rules are still under review. The v4 series
> intentionally models the Linux device as a generic Open Sensor Fusion
> device rather than an OSF GREEN board-specific device. OSF GREEN is
> the prototype board used for current runtime testing, not the Linux DT
> compatible or driver identity.

Other than the fact that new revisions must not be sent as a diff on top
of a prior revision, please stop sending new versions without actually
replying to my v1 comments. In particular:

| What does "v0" mean here? Is the data format not complete yet?
| Are versions of the protocol likely to be backwards compatible?
| Will the device identify what version of the protocol it implements?

This version drops mention of v0 in the binding, but I don't know if that
means the version is fully discoverable or if you've moved to a stable
revision etc. You need to spell this stuff out to us, I'm not going to
read a github repository to figure this out - I have hundreds of patches
to get through every day. It's your responsibility to explain it all.

> The current wire format uses the OSF0 magic for protocol major
> version 0. That is kept as an internal wire-format detail for

For example, what does "OSF0 magic" mean? Is that a detectable version
number in a consistent place across revisions? Or will OSF1 magic be
incompatible. From a devicetree point of view, that's important because
if the magic is in different places in different revisions, the
compatible needs to convey what revision the device implements.

> compatibility with existing firmware, tools, and runtime smoke
> evidence. The public driver identity remains Open Sensor Fusion / OSF,
> with protocol versioning handled by the protocol major/minor fields.

This sounds like versioning is discoverable, but you need to spell this
out in the commit message for the binding.

Thanks,
Conor.

> 
> Project links:
> https://www.opensensorfusion.org/
> https://github.com/opensensorfusion
> https://github.com/opensensorfusion/opensensorfusion-hardware
> https://github.com/opensensorfusion/opensensorfusion-linux
> 
> Runtime testing so far has used an OSF GREEN prototype connected to a
> Raspberry Pi over UART. On Raspberry Pi 6.12.75+rpt-rpi-v8, the
> driver registered osf-accel, osf-gyro, osf-magn, and osf-temp from a
> capability report. Raw reads and software kfifo buffer reads were
> tested for all four IIO devices.
> 
> Changes since v3:
> 
> * Explain why the series is still RFC.
> * Move the DT binding out of iio/imu because the device is a sensor
>   aggregation device rather than an IMU.
> * Replace the OSF GREEN board-specific compatible with the generic
>   opensensorfusion,osf compatible.
> * Treat OSF GREEN as tested prototype hardware / board model
>   information, not as the Linux compatible string.
> * Rename the kernel documentation to open-sensor-fusion.rst and
>   reduce it to a driver-facing overview.
> * Add the IIO documentation toctree entry.
> * Keep full protocol details and compatibility rules in project
>   documentation rather than duplicating the full wire specification in
>   the kernel tree.
> * Avoid using OSF0 as the public driver identity; keep it only as the
>   current wire magic for protocol major version 0.
> * Add FourCC-style wire magic handling in the decoder.
> * Use GENMASK() for the capability flags mask.
> * Clarify signed 32-bit little-endian sample decoding.
> * Stop counting normal partial UART receive waits as partial frame
>   errors.
> * Avoid decoding complete frames twice in the stream/core path.
> * Remove the local scan[] bounce before
>   iio_push_to_buffers_with_ts_unaligned() and pass the values buffer
>   directly.
> * Remove the meaningless temperature available_scan_masks entry.
> * Update MAINTAINERS paths for the new binding and documentation
>   names.
> 
> Jinseob Kim (6):
>   dt-bindings: iio: add Open Sensor Fusion device
>   Documentation: iio: add Open Sensor Fusion driver overview
>   iio: osf: add protocol decoding
>   iio: osf: add stream parser
>   iio: osf: add UART transport
>   iio: osf: register IIO devices from capabilities
> 
>  .../iio/imu/opensensorfusion,osf-green.yaml   |  43 ---
>  .../bindings/iio/opensensorfusion,osf.yaml    |  43 +++
>  Documentation/iio/index.rst                   |   1 +
>  .../iio/open-sensor-fusion-protocol-v0.rst    | 308 ------------------
>  Documentation/iio/open-sensor-fusion.rst      |  62 ++++
>  MAINTAINERS                                   |  26 +-
>  drivers/iio/opensensorfusion/Kconfig          |   4 +-
>  drivers/iio/opensensorfusion/osf_core.c       |   9 +-
>  drivers/iio/opensensorfusion/osf_iio.c        |  15 +-
>  drivers/iio/opensensorfusion/osf_protocol.c   |   4 +-
>  drivers/iio/opensensorfusion/osf_protocol.h   |   4 +-
>  drivers/iio/opensensorfusion/osf_serdev.c     |   2 +-
>  drivers/iio/opensensorfusion/osf_stream.c     |  38 +--
>  13 files changed, 145 insertions(+), 414 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
>  create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
>  delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
>  create mode 100644 Documentation/iio/open-sensor-fusion.rst
> 
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]