Hi Jonathan, Thanks for the valuable insights! DT Binding Flexibility: I see how increased flexibility can complicate matching rules. I'll lean towards a part-specific binding unless there's a strong case for generalization, and I'll review adc.yaml for best practices. MCU-Assisted vs. Direct SPI: I’ll check the IIO tree (togreg branch) for SPI offload logic. Adapting it for an MCU is intriguing but likely beyond GSoC’s scope—could be a stretch goal if time permits. Reference & Guidelines: I’ll align with recent ADC drivers and iio/dummy/, ensuring consistency with IIO standards. Appreciate the guidance—it's helping refine the approach. Let me know if there’s anything else worth considering! Best, Prince Kumar On Tue, Mar 11, 2025 at 1:02 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Mon, 10 Mar 2025 10:33:44 +0530 > Prince Kumar <855princekumar@xxxxxxxxx> 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 > -- Regards, Prince Kumar Phone: +91-8557032850(M), 8556911521(M)
