Date: Wed, 12 Aug 2026 14:27:02 -0400
From: Marco Chen <marcochen.dev@gmail.com>
To: jic23@kernel.org
Cc: dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org, 
	matt@ranostay.sg, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, 
	skhan@linuxfoundation.org, linux-kernel-mentees@lists.linux.dev, pmeerw@pmeerw.net
Subject: [RFC] iio: health: max30102: proximity power saving TODO and
 datasheet history
Message-ID: <any69uXah07eA8lR@xiaolong>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

The proximity power saving TODO in max30102.c was added in the original
driver commit b3c590ce14b1 ("iio: health: add MAX30102 oximeter driver
support") in Feb 2017. At that time, the MAX30102 datasheet documented a
Proximity Function and Proximity Mode Interrupt Threshold register. Both
were removed in revision 1 of that datasheet on October 2018. The MAX30101
datasheet did the same in its revision 1 on June 2018.

That also explains the PROX_INT defines in max30102.c, as they were
correct in revision 0 of the datasheet when the commit was made.

Since there is no current documentation for the proximity function on
the MAX30102 or MAX30101, I don't think this TODO should be implemented
for those parts. Does this seem like the right decision?

However, the feature is still well-documented on the MAX30105. Is
proximity power saving worth implementing there? I don't have a MAX30105
but I am more than willing to purchase one and develop and test on it,
and I have access to a logic analyzer to verify the I2C transactions.

For the implementation, I would add MAX30105-gated defines for the
PILOT_PA (0x10) and PROX_INT_THRESH (0x30) registers and handle PROX_INT 
in the interrupt handler. The MAX30105 transitions out of proximity mode 
automatically once the ADC count exceeds the threshold, so PROX_INT is a 
notification to start getting data, rather than a mode switch.

For the ABI, I was thinking of using an IIO_PROXIMITY channel with an
iio_event_spec for the threshold and enable, similar to what was done in
cm36651.c. Is this the right approach?

This feature would then be enabled through the event enable, so with the
event disabled, the driver would behave the same as it does today. This
is important because with proximity active, enabling the buffer would
not produce data until an object is detected.

One interaction with a patch that was applied recently [1]: enabling 
PROX_INT falsifies the assumption that FIFO_RDY is the only enabled 
interrupt source. So the handler would need to distinguish between 
causes, likely meaning that max30102_fifo_count() will need to be 
refactored a little. 

Thank you.

[1] https://lore.kernel.org/linux-iio/20260808195450.25420-1-marcochen.dev@gmail.com/