Re: Proposal Discussion: ADE9113 IIO Driver Development for Linux Kernel

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 10 Mar 2025 10:33:44 +0530
Prince Kumar <855princekumar@gmail.com> wrote:

> Hi Jonathan,
> 
> Thanks for your valuable feedback! Your insights are really helpful in
> refining my approach and ensuring alignment with best practices.
> 
> 1. DT Binding Flexibility:
>    I initially considered making the DT binding adaptable for similar
> SPI-based ADCs to potentially support minor hardware variations with
> minimal changes. However, your point about maintainability makes
> sense, and I see that most existing bindings tend to be more specific.
> I’ll revisit this and reconsider whether a part-specific approach
> would be more appropriate. If there are examples of flexible but
> maintainable bindings worth looking into, I’d appreciate any pointers.

The problem with increasing flexibility is that in usually means
more complex matching rules (see allOf/oneOf statements in existing
bindings) to ensure we require what is needed for a given specific
device.  Those are a lot harder to read than separate files but do
make sense if there are only one or two minor differences between
a small number of devices.

> 
> 2. MCU-Assisted vs. Direct SPI:
>    This was more of an exploratory idea rather than a fully defined
> plan. My initial thought was to assess whether offloading certain
> operations to an MCU (e.g., pre-processing or buffering) could offer
> benefits over direct SPI communication with the Linux system. Given
> that this isn’t a typical approach, I’ll take a step back and ensure I
> properly evaluate the feasibility and trade-offs before including it
> in the proposal. If there are existing implementations that explore
> similar optimizations, I’d be keen to study them.

There is SPI offload logic in the kernel that will merge this cycle.
(it's in the IIO tree on git.kernel.org togreg branch

Expanding that to MCU based handling (all implementations are currently
FPGA based) would be an interesting project. May be too complex to fit
in the timescale of a GSOC.  Perhaps a valid stretch goal though if the
rest falls in place quickly.

Jonathan