Re: supporting binary (near-far) proximity sensors over gpio

[Jeff LaBundy <jeff@labundy.com>]

Hi Sicelo and David,

On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:
> On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
> >
> > Hi
> >
> > Some phones have 1-bit proximity sensors, which simply toggle a GPIO
> > line to indicate that an object is near or far. Thresholds are set at
> > hardware level. One such sensor is OSRAM SFH 7741 [1], which is used on
> > the Nokia N900.
> >
> > It is currently exported over evdev, emitting the SW_FRONT_PROXIMITY key
> > code [2].
> >
> > So the question is: should a new, general purpose iio-gpio driver be
> > written, that would switch such a proximity sensor to the iio framework?
> > Or evdev is really the best place to support it?
> >
> > There are a couple of people who are willing to write such an iio
> > driver, if iio is the way to go.
> >
> > Regards,
> > Sicelo
> >
> > [1] https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > [2] https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> >
> Since this is really a proximity switch (it is either on or off)
> rather than measuring a proximity value over a continuous range, it
> doesn't seem like a good fit for the iio subsystem. If the sensor is
> on a phone, then it is likely to detect human presence so the input
> subsystem does seem like the right one for that application.
> 
> More at https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> 

I tend to agree; if there are only two discrete states as is the case for a
GPIO, then this is technically a switch and not a sensor. Therefore, input
seems like a better fit; that is just my $.02.

FWIW, a similar discussion came up a few years ago in [1] and again the key
differentiator was whether the output is discrete or continuous.

Kind regards,
Jeff LaBundy

[1] https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/