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
---
[1]: https://wiki.linuxfoundation.org/gsoc/2024-gsoc-iio-driver
[2]: Microchip MCP4821 DAC:
https://lore.kernel.org/lkml/[email protected]/
LiteOn LTR390 light sensor:
https://lore.kernel.org/lkml/[email protected]/
Aosong AGS02MA air quality sensor:
https://lore.kernel.org/lkml/[email protected]/
[3]: https://lore.kernel.org/linux-iio/[email protected]/
https://lore.kernel.org/linux-iio/YlXR0d7waKW9xncd@fedora/
On Tue, 19 Mar 2024 11:35:27 +0530
Anshul Dalal <[email protected]> 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/[email protected]/
> LiteOn LTR390 light sensor:
> https://lore.kernel.org/lkml/[email protected]/
> Aosong AGS02MA air quality sensor:
> https://lore.kernel.org/lkml/[email protected]/
> [3]: https://lore.kernel.org/linux-iio/[email protected]/
> https://lore.kernel.org/linux-iio/YlXR0d7waKW9xncd@fedora/