Looking for a sensor driver to contribute

Looking for a sensor driver to contribute

[Olivier Tanoh]

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

Re: Looking for a sensor driver to contribute

[Joshua Crofts]

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/ 

-- 
Kind regards,
Joshua Crofts

Re: Looking for a sensor driver to contribute

[Jonathan Cameron]

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