From: Jonathan Cameron <jic23@kernel.org>
To: Anshul Dalal <anshulusr@gmail.com>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
ciprian.hegbeli@analog.com, marcelo.schmitt@analog.com,
dragos.bogdan@analog.com
Subject: Re: iio: GSoC 2024: RFC on AD7294-2 driver proposal
Date: Tue, 26 Mar 2024 18:52:07 +0000 [thread overview]
Message-ID: <20240326185207.20f8987e@jic23-huawei> (raw)
In-Reply-To: <20240319060528.1238089-1-anshulusr@gmail.com>
On Tue, 19 Mar 2024 11:35:27 +0530
Anshul Dalal <anshulusr@gmail.com> 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@gmail.com/
> LiteOn LTR390 light sensor:
> https://lore.kernel.org/lkml/20231208102211.413019-1-anshulusr@gmail.com/
> Aosong AGS02MA air quality sensor:
> https://lore.kernel.org/lkml/20231215162312.143568-1-anshulusr@gmail.com/
> [3]: https://lore.kernel.org/linux-iio/20240229184636.13368-1-danascape@gmail.com/
> https://lore.kernel.org/linux-iio/YlXR0d7waKW9xncd@fedora/
prev parent reply other threads:[~2024-03-26 18:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 6:05 iio: GSoC 2024: RFC on AD7294-2 driver proposal Anshul Dalal
2024-03-26 18:52 ` Jonathan Cameron [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240326185207.20f8987e@jic23-huawei \
--to=jic23@kernel.org \
--cc=anshulusr@gmail.com \
--cc=ciprian.hegbeli@analog.com \
--cc=dragos.bogdan@analog.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).