Re: [PATCH v7 5/5] iio: osf: add UART IIO driver

From: Kim Jinseob

Date: Fri Jul 10 2026 - 11:35:14 EST


> This is only defined in this patch but is used in patch 4. Make sure your
> code builds after each patch so as to avoid breaking code bisection.

I changed patch 4 in my local next revision so that the stream parser no
longer depends on osf_core.h or osf_core_receive_frame().

The stream parser now accepts a typed frame handler and an opaque context.
Patch 5 provides the wrapper that calls osf_core_receive_frame().

I compiled the sources introduced by patches 3 and 4 separately using
temporary uncommitted Kbuild harnesses, and built and linked the
complete module after patch 5.

> This feels like going too far to deduplicate just this. Put a copy inline
> in each of the other macros where it is used and drop this one.

I removed OSF_SCAN_TYPE_S32 and placed the scan_type initializer
directly in both channel macros.

> Looking at this again, why do we care about holding the device
> in buffered mode for this? Races should be safe without that
> big hammer. A simple check on iio_buffer_enabled() should ensure
> data is only pushed when it is enabled, or just after it is disabled
> (which should always be safe).

I replaced the buffer-mode claim and release with an iio_buffer_enabled() check.

The one-axis and three-axis cases now return directly from
iio_push_to_buffers_with_ts(), and the default case directly returns
-EPROTO. The zero-initialized scan structures and aligned timestamps
are unchanged.

Thanks,

Jinseob