On Tue, 19 Mar 2024 11:35:27 +0530 Anshul Dalal <anshulusr@xxxxxxxxx> wrote: > Hello everyone, > > I am Anshul Dalal, a pre-final year student at SRMIST (India). I am > pursuing my Bachelor's in Computer Science and Engineering and wish to > participate in GSoC 2024 as part of The Linux Foundation under the IIO > worksgroup. > > Following the suggestion from the IIO GSoC page[1], I would like to work > on a driver for AD7294-2. I am interested in the device since it offers > a wide array of functionality that is different from my past IIO > drivers[2]. I have prepared a draft proposal and would like to get early > feedback: > https://docs.google.com/document/d/1zf9yDq2-Ba8Vqh10w1cYI3buHzh0qIYwzf7xBkaEzDM > > I'm aware of interest in the same device from other contributors[3]. If > required, I'm ready to work on any other part suggested by the company > or the IIO community. > > Best regards, > Anshul Hi Anshul, As you note, there are threads elsewhere discussing the suitability of this part. Given the potentially competitive nature of proposals, I'm only going to give general comments based on a quick look at your proposal. I'll stick to the sort of thing that might help everyone proposing such a project. 1) Maintainer / reviewer bandwidth is often the biggest unknown in a project targeting upstream - so get that underway in plenty of time. Treat it as a risk and plan mitigation where you can. 2) Allow time for revisions - this is a fairly complex device, so there may well be more complex changes requested such as ABI redesigns and they may take a non trivial amount of time. For reference one GSOC intern some years ago did 3 major rewrites; the code was excellent (until after the GSOC had nearly finished I'd been assuming he was an experienced consultant - not an intern!) Our understanding of what was the best path was driven by seeing and discussing each revision. Whilst that was much earlier in the evolution of IIO event now a moderate amount of time makes sense. 3) Don't wait until the end to send stuff for review - you will probably be crossing kernel development cycles (with a merge window to cause everything to grind to a halt) and reviewer / maintainer vacations etc. As such, structure a driver development plan to be suitable for partial upstreaming mid way. If you like play guess the kernel release dates feel free to put that alongside your plan. Guessing my holidays is a harder target :) Trying to upstream a driver alongside further development, parallel's up the time for reviewers to respond with developing more advanced features. Note that full time kernel developers do this sort of thing all the time as a complex feature often takes multiple cycles (and sometimes multiple years) to get fully upstream. So I'd revisit your plan with these points in mind. It is a complex trade off of keeping the plan simple and easy to understand, and incorporating an idea of what else is going on in parallel. Also think about other risks and how they might be rectified or work might continue whilst they are being (a classic being failure to establish reliable comms with the chip). Jonathan > > --- > > [1]: https://wiki.linuxfoundation.org/gsoc/2024-gsoc-iio-driver > [2]: Microchip MCP4821 DAC: > https://lore.kernel.org/lkml/20231220151954.154595-1-anshulusr@xxxxxxxxx/ > LiteOn LTR390 light sensor: > https://lore.kernel.org/lkml/20231208102211.413019-1-anshulusr@xxxxxxxxx/ > Aosong AGS02MA air quality sensor: > https://lore.kernel.org/lkml/20231215162312.143568-1-anshulusr@xxxxxxxxx/ > [3]: https://lore.kernel.org/linux-iio/20240229184636.13368-1-danascape@xxxxxxxxx/ > https://lore.kernel.org/linux-iio/YlXR0d7waKW9xncd@fedora/
