Re: [PATCH 2/3] dt-bindings: iio: st,st-sensors: add st,fullscale-mg

[me@herrie.org]

On 2026-06-14 20:44, Jonathan Cameron wrote:
> On Fri,  5 Jun 2026 12:08:42 +0200
> Herman van Hazendonk <github.com@herrie.org> wrote:
> 
>> Add an optional st,fullscale-mg property that selects the initial
>> full-scale range of an ST MEMS sensor at probe time, expressed in
>> milligauss for magnetometers (and analogous engineering units for
>> other ST sensor families that may grow this property in the future).
>> 
>> The property is purely additive: if absent, drivers fall back to
>> their existing chip default, and if present but unsupported by the
>> specific sensor the driver warns and falls back. No existing in-tree
>> DTS is affected.
>> 
>> The motivating case is the LSM303DLH magnetometer on the HP TouchPad
>> (apq8060 / tenderloin) where the kernel's chip-default +/-1.3 G range
>> saturates the X axis to the chip's 0xF000 overflow sentinel out of
>> probe, because the chip is mounted close to surrounding power planes
>> and picks up enough DC bias to exceed the smallest range. The driver
>> core hardcodes fs_avl[0] as the starting range, so userspace cannot
>> recover without racing the driver to write the in_magn_x_scale sysfs
>> attribute after probe. st,fullscale-mg lets the device tree declare
>> a wider initial range up-front and avoids the race entirely.
> 
> I'm trying to understand what you mean here by racing.
> 
> If we get this overflow condition the chip is wedged until reset, or
> userspace simply has to change the range to recover?
> 
> I'm wondering if a UDEV rule is sufficient in theory to fix this.
> 
> I'm not necessarily against having the range in DT as it is effectively
> hardware dependent but just want to make sure I fully understand the 
> issue.
> 
> Jonathan
> 
> 
> 
>> 
>> Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
>> ---
>>  .../devicetree/bindings/iio/st,st-sensors.yaml | 18 
>> ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml 
>> b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
>> index a1a958215cdb..335f38e9f78f 100644
>> --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
>> +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
>> @@ -126,6 +126,24 @@ properties:
>>    mount-matrix:
>>      description: an optional 3x3 mounting rotation matrix.
>> 
>> +  st,fullscale-mg:
>> +    description: |
>> +      Selects the initial sensor full-scale at probe time, expressed 
>> in
>> +      milligauss for magnetometers (or analogous engineering units 
>> for
>> +      other sensor families that may grow this property in the 
>> future).
>> +      The value must match one of the sensor-specific full-scale 
>> ranges
>> +      supported by the chip; if the chip does not support the 
>> requested
>> +      range the driver falls back to its built-in default.
>> +
>> +      This is intended for boards where the magnetometer chip picks 
>> up
>> +      enough DC bias from nearby PCB structures (power planes, 
>> ferrous
>> +      shields, etc.) that the kernel's chip-default 
>> highest-sensitivity
>> +      range saturates one or more axes to the chip's overflow 
>> sentinel,
>> +      and userspace observes that axis as permanently stuck. 
>> Declaring
>> +      a wider initial range avoids the saturation at the cost of a
>> +      slightly coarser quantisation.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +
>>  allOf:
>>    - if:
>>        properties:
Hi Jonathan,

"racing" was loose wording on my part. The chip is not wedged. Once 
userspace writes a wider range to in_magn_x_scale,
the next conversion comes back with sensible data and everything works. 
A UDEV rule on add of the IIO device would, in principle, fix
the steady-state problem.

What I was clumsily pointing at is the probe-time window: the IIO 
consumers in our stack (sensorfw's iio-sensors-adaptor, geomagnetic
/ orientation services) start polling in_magn_x_raw essentially the 
moment the device node appears, and they treat the saturated
0xF000 sentinel as a legitimate sample rather than as overflow. Until 
the UDEV rule fires and the kernel commits the new range, every
read returns the stuck sentinel, so orientation/compass features are 
wrong from boot for some non-trivial number of samples (and on
slow-boot paths the consumer may have already cached a bogus calibration 
baseline by the time UDEV catches up).

So the trade-off as I see it is:

- UDEV rule: works for steady state, fully out-of-tree, but the 
per-board configuration ends up split between two places (DTS for
"this board has an LSM303DLH at i2c@... in this orientation"; UDEV for 
"and by the way it needs a wider range or its raw readings are
nonsense"). The wider-range requirement is purely a property of how the 
magnetometer is mounted on the board, which is what DT is for.

- st,fullscale-mg in DT: keeps all hardware-dependent calibration in one 
place, available before any IIO consumer can open the device,
and harmless on boards that don't need it (absent property existing 
chip-default behaviour, no   DTS in tree changes).

I'm happy to drop the wording about "racing" in v2 and replace it with a 
more accurate description of the early-consumer issue if that
reads better. And of course if you'd rather we ship a UDEV rule 
downstream instead of adding a binding, I'll yield, but my read is that
this is hardware-dependent enough to belong in DT.

Thanks,
Herman