From: Jonathan Cameron <jic23@kernel.org>
To: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: Olivier Tanoh <olivier.tanoh19@gmail.com>, linux-iio@vger.kernel.org
Subject: Re: Looking for a sensor driver to contribute
Date: Mon, 27 Jul 2026 01:58:24 +0100 [thread overview]
Message-ID: <20260727015824.39da2987@jic23-huawei> (raw)
In-Reply-To: <20260724123953.000000fc@gmail.com>
On Fri, 24 Jul 2026 12:39:53 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> On Fri, 24 Jul 2026 11:51:32 +0200
> Olivier Tanoh <olivier.tanoh19@gmail.com> wrote:
>
> > Hi all,
> >
> > I'm an embedded Linux engineer looking to contribute a sensor driver to IIO.
> >
> > I've already sent a first (trivial) patch to staging to learn the
> > submission workflow, and I've studied the structure of existing IIO
> > drivers, si7005.c in particular to understand probe, channel
> > definitions and read_raw.
> >
> > Before picking a target, I wanted to ask : are there sensors people
> > have been asking for that currently have no IIO driver? Or families
> > where a recent variant is missing?
> >
> > I have I2C hardware available for testing (Raspberry Pi CM4), so I can
> > buy a part and validate the driver on real hardware.
> >
> > Any pointers would be appreciated.
> >
> > Thanks,
> > Olivier Tanoh
> >
>
> Hi Olivier,
>
> It's really up to you to find something that that is missing in IIO. I'd recommend
>
> - checking out newly released parts, preferably ones with an existing breakout
> board to make testing easier. Stores like Adafruit are great for these.
> - finding an out-of-tree driver that is authored by a silicon manufacturer,
> mobile phone vendor etc. and move the driver upstream (a good example of this
> recently is a a patch series for the Sharp GP2AP070S, which has an out-of-tree
> driver in the Exynos7870 kernel tree [1])
>
> You don't just have to add new drivers, there is a lot of code that needs cleaning
> up :) I'm sure others will chime in with more ideas.
>
> [1] https://lore.kernel.org/all/20260723-gp2ap070s-v1-0-b8ca3a4c10dd@disroot.org/
>
All good suggestions. To add my 2 cents.
Find something you are interested in working with and where you feel the device
complexity matches how large a project you want. For example I'd avoid an IMU
if you want something small. Just see how much work Chris Morgan has put into
one of those! Likewise big complex energy monitors or similar.
One option would be to look at the few things we still have in staging. However
before you go too far on that I'd suggest looking in the lore archives for
previous attempts. Some of those are still there for good reason and solving
that will be a far from simple project!
Thanks,
Jonathan
prev parent reply other threads:[~2026-07-27 0:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 9:51 Looking for a sensor driver to contribute Olivier Tanoh
2026-07-24 10:39 ` Joshua Crofts
2026-07-27 0:58 ` 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=20260727015824.39da2987@jic23-huawei \
--to=jic23@kernel.org \
--cc=joshua.crofts1@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=olivier.tanoh19@gmail.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