Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 24 Jun 2026 06:18:45 +0200
me@herrie.org wrote:

> On 2026-06-23 21:49, Andy Shevchenko wrote:
> > On Tue, Jun 23, 2026 at 08:29:16PM +0100, Jonathan Cameron wrote:  
> >> On Tue, 16 Jun 2026 15:02:06 +0200
> >> Herman van Hazendonk <github.com@herrie.org> wrote:
> >>   
> >> > The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
> >> > highest-sensitivity full-scale supported by the chip -- as the
> >> > starting range. For the LSM303DLH that is +/-1.3 G; for the
> >> > LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
> >> >
> >> > That is the right default for "minimal noise floor at a desk", but
> >> > it leaves no margin for boards that pick up appreciable DC bias from
> >> > nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
> >> > LSM303DLH magnetometer is mounted close enough to the surrounding
> >> > power planes that X reads back as the chip's 0xF000 overflow
> >> > sentinel (== -4096 raw, the value the chip publishes when the ADC
> >> > saturates) on every sample at the chip-default range, while Y and Z
> >> > fall well within the +/-1.3 G window.
> >> >
> >> > Parse the st,fullscale-milligauss device-tree property (documented
> >> > separately in dt-bindings/iio/st,st-sensors.yaml) in the
> >> > magnetometer common probe to select the initial fs_avl entry by its
> >> > mg value. The DT binding pins the accepted value set per compatible
> >> > via allOf/if-then enum clauses, so a malformed mg value fails
> >> > dt_binding_check rather than reaching the driver. Sensors with a
> >> > fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
> >> > register to switch and the property is rejected outright for them
> >> > in the binding; the parse block is additionally gated on fs.addr as
> >> > defence in depth against stale DTBs.
> >> >
> >> > Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
> >> > LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
> >> > 4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
> >> > they are 4000, 8000, 12000, 16000.
> >> >
> >> > Empirical scale sweep on the HP TouchPad confirmed that on this
> >> > board any fs_avl >= 1 produces non-saturated X readings:
> >> >
> >> >     scale (0.001 G/LSB)  | X raw    Y raw    Z raw
> >> >     --------------------+-------------------------------
> >> >             1.100        | -4096    44       46    (X saturated)
> >> >             0.855        |  -547    37       37    (clean)
> >> >             0.670        |  -433    94      103    (clean)
> >> >             0.450        |  -266    44       71    (clean)
> >> >             0.400        |  -235    34       65    (clean)
> >> >             0.330        |  -196    27       56    (clean)
> >> >             0.230        |  -145    15       40    (clean)
> >> >
> >> > 2500 mg is the natural choice for tenderloin: comfortably outside
> >> > the saturation regime while keeping useful precision for compass
> >> > applications.
> >> >
> >> > Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch
> >> > Assisted-by: Sashiko:claude-opus-4-7  
> >> Hmm. First time I remember seeing Sashiko credited like this. Seems 
> >> like pretty much
> >> every patch series of any complexity would end up crediting sashiko.
> >> Out of curiosity were you just looking at reports, or were you running 
> >> it locally to
> >> help with development?  
> > 
> > I believe it's the second one, because LKML version uses Gemini (as far 
> > as I
> > understand the case). At least that's why I haven't commented on this 
> > tag.  
> I have the whole toolchain running locally to avoid too many submissions 
> and
> feedback from Sashiko with Gemini after submitting. For small drivers I 
> can run
> Gemini locally as well, usually stick with Claude Opus 4.7 since that's 
> what I
> have a subscription for. For very complicated and large drivers Claude 
> Opus
> tends to time out even with 1 or 2 hour, so I fall back to Claude Haiku 
> 4.5
> (which catches quite a few things, but is not as thorough as Opus or 
> Gemini).
> 
> Seeing Sashiko tends to provide different feedback on different rounds, 
> I try
> to only submit when Sashiko and all others are clean.
> 
> Hope this clarifies!
Thank!  I loose track of all these models :)  So the summary is very
useful. I've been meaning to get a similar flow in place myself for
checking local stuff (not that I'm doing any development at the moment)

Jonathan

> 
> Herman