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

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 15 Jun 2026 13:16:52 +0200
me@herrie.org wrote:

> 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. 

Should this perhaps be returning -ERANGE or similar to indicate a failed
read via the return value rather than reading out something
that requires device specific userspace to handle?

Not that this changes the requirements as obviously it still doesn't work
when we want a reading!

> 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.

Fair enough to it being board dependent.

> 
> - 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.
I'm fine with the DT solution with some of this extra info captured
in the commit message.

Thanks,

Jonathan

> 
> Thanks,
> Herman