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

[me]

On 2026-06-14 20:44, Jonathan Cameron wrote:
> On Fri,  5 Jun 2026 12:08:42 +0200
> Herman van Hazendonk <github.com@xxxxxxxxxx> 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@xxxxxxxxxx>
> > ---
> >  .../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