On Wed, May 20, 2026 at 1:47 PM Jinseob Kim <kimjinseob88@gmail.com> wrote:
>
> Open Sensor Fusion is a UART-attached sensor aggregation device. The current
> prototype sends OSF protocol v0 frames over a host UART link. This RFC adds the
> first Linux IIO receive path for that UART stream.
>
> The first transport is serdev UART. USB, real sensor reads, fusion output, and
> production timestamp correlation are intentionally left out of this series.
>
> The driver code is kept in one patch for the first RFC to avoid intermediate
> non-buildable states. The internal files are still split by protocol, stream,
> core, transport, and IIO code.
>
> Current validation coverage:
>
> - STM32F405 test firmware OSF protocol v0 UART stream at 115200 8N1.
> - Raspberry Pi 4 serdev probe and receive path to osf_core_receive_frame().
> - CAPABILITY_REPORT-driven IIO device registration.
> - IIO read_raw for accel, gyro, magn, and temp samples.
> - IIO software kfifo buffer userspace read.
> - scan decode helper for buffered samples.
> - dt_binding_check pass for the binding.
> - checkpatch.pl --strict with ERROR 0, WARNING 0, CHECK 0.
> - W=1 source compile/link phase clean in the staging kernel tree.
> - modpost unresolved symbol warnings came from the staging tree missing
> Module.symvers.
>
> Known limits:
>
> - The sample source is synthetic stream data, not real ICM-42688-P or MMC5983MA
> sensor reads.
> - The IIO timestamp is Linux host receive time. Device time correlation is still
> open.
> - Runtime capability removal is not implemented.
> - The staging layout uses drivers/iio/opensensorfusion/. The final directory is
> open for review.
>
> Review feedback wanted on the IIO device layout, timestamp policy, binding
> shape, and driver directory.
> 16 files changed, 1706 insertions(+)
No.
Split it to at least 5 patches (as far as I can briefly see it's
achievable): base + feature1 + feature2 + …
--
With Best Regards,
Andy Shevchenko