Re: [RFC PATCH] iio: proximity: sx9360: fix hardware gain encoding

[Arnav Kapoor <kapoorarnav43@gmail.com>]

On Sat, Nov 07, 2026 at 07:14:09PM +0000, Jonathan Cameron wrote:
> The default value is odd.  Do we have any idea what is in that top bit?
> I'm going to guess something harmless and that perhaps the gain value
> due to writing a 0 is either rejected, or actually mapped to same as 1.
>
> You are correct that we really need someone with datasheet access to
> sanity check this sone.

I still don't have the datasheet, but I found the vendor driver, which
is the closest thing I have. Samsung's Android kernels carry an sx9360
driver with a Semtech copyright, for example:

https://github.com/TeamWin/android_kernel_samsung_d2q/blob/master/drivers/sensors/sx9360.c

It decodes the same field like this:

	gain = (gain & 0x38) >> 3;
	if (gain > 0 && gain < 5)
		/* prints "x%u", 1 << (gain - 1) */
	else
		/* prints "Reserved" */

so codes 1 to 4 are gains 1 to 8 and 0 is reserved, which is what the
RFC does. Its init table writes 0x09 to PROXCTRL0_PHR and _PHM, i.e.
gain code 1 (x1) with bit 7 clear. That doesn't say what bit 7 does,
but the vendor's own default doesn't set it, so I think 0x80 is the
same typo as in sx9324 rather than something intentional. It also
doesn't say what the hardware does with code 0.

Sashiko flagged the same off-by-one on v2 and v3 of the write_gain()
series, though that is by the same analogy with the sx9324 fix, so it
isn't independent evidence.

If this is enough to go on, I'll respin the RFC as a patch on top of
v3 of that series, which needs SX9360_REG_PROX_CTRL0_GAIN_8 to become
0x4. Gwendal, Stephen, a confirmation from the datasheet would still
be very welcome.

Thanks,
Arnav