On Mon, 3 Mar 2025 22:15:38 +0530 Prince Kumar <855princekumar@xxxxxxxxx> wrote: > Dear Linux IIO Maintainers, > > I hope you are doing well. I am interested in contributing to the > Linux Industrial I/O (IIO) subsystem as part of GSoC 2025 under the > Linux Foundation. I would appreciate your feedback on my project idea > to ensure it aligns with the community's goals and best practices. > > Project Proposal: ADE9113 IIO Driver Development > > My goal is to develop a mainline-compatible Linux kernel driver for > the ADE9113 ADC (or similar SPI-based ADCs), enabling seamless > integration into the IIO subsystem. The driver will expose sensor data > via sysfs, libiio, and standard Linux interfaces, making it accessible > for various applications. > > Technical Approach > 1. IIO Driver Implementation: > Develop a modular and reusable kernel driver for ADE9113, ensuring > compliance with IIO standards. > Implement buffered and direct register read/write methods for > real-time data access. > > 2. Extensibility & Optimization: > Design the driver with flexible Device Tree (DT) bindings, allowing > support for other SPI-based ADCs with similar architectures. This is an interesting comment. On what basis do you plan to decide the trade off between flexibility and maintainability of that binding? It's rare to put much effort into making a DT binding for a specific part flexible in this way (as opposed to generic shared bindings that aren't specific to a part like this in adc.yaml) > Explore an MCU-assisted vs. direct SPI approach to evaluate > performance and CPU overhead trade-offs. Perhaps expand a little on this. You are talking about something not particularly standard so anyone reviewing this doc is likely to want to know if it is a well thought out plan or just a vague idea. > > 3. Testing & Documentation: > Provide unit tests using kselftest or libiio to validate the driver. > Write comprehensive kernel documentation to guide future contributors. > Ensure compatibility with existing Linux tools for IIO sensor data > visualization. > > Community Involvement & Next Steps > I have reviewed existing IIO ADC drivers and the Linux IIO framework > to ensure this proposal aligns with upstream development goals. I > would greatly appreciate your input on: > > Feasibility: Is this project a good fit for IIO and GSoC? > Driver Design: Are there any best practices or existing reference > drivers I should study? Generally no, but we have the dummy fake driver in iio/dummy/ that is there to exercise interfaces etc without hardware. Otherwise we don't maintain any specific driver to current best practice so you may just want to look at recent drivers for suitable references. > Additional Considerations: Are there specific IIO guidelines I should follow? Follow local coding style. There are subtle differences across the kernel but mostly we want to see a driver that 'looks and smells' like other drivers. Keep innovation to where it is needed. In most cases copying and adapting is a better plan than inventing something new. Jonathan > > I am eager to receive feedback and refine my approach to make a > meaningful contribution. Looking forward to your thoughts! > > Best regards, > Prince Kumar >
