Re: iio: GSoC 2024: RFC on AD7294-2 driver proposal

[Jonathan Cameron]

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/