From: me@herrie.org
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Herman van Hazendonk" <github.com@herrie.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Denis Ciocca" <denis.ciocca@gmail.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Denis Ciocca" <denis.ciocca@st.com>,
"Linus Walleij" <linusw@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
Date: Wed, 24 Jun 2026 06:18:45 +0200 [thread overview]
Message-ID: <edcf262b530a88ee602fa07edc8382ac@herrie.org> (raw)
In-Reply-To: <ajrjRdEkZAho8h1E@ashevche-desk.local>
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!
Herman
next prev parent reply other threads:[~2026-06-24 4:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 13:02 [PATCH v2 0/3] iio: lsm303dlh-magn: endianness + boot-time fullscale selection Herman van Hazendonk
2026-06-16 13:02 ` [PATCH v2 1/3] iio: common: st_sensors: honour channel endianness in read_axis_data Herman van Hazendonk
2026-06-17 10:02 ` Andy Shevchenko
2026-06-23 19:23 ` Jonathan Cameron
2026-06-16 13:02 ` [PATCH v2 2/3] dt-bindings: iio: st,st-sensors: add st,fullscale-milligauss Herman van Hazendonk
2026-06-16 15:41 ` Conor Dooley
2026-06-23 19:26 ` Jonathan Cameron
2026-06-16 13:02 ` [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property Herman van Hazendonk
2026-06-17 10:05 ` Andy Shevchenko
2026-06-23 19:29 ` Jonathan Cameron
2026-06-23 19:49 ` Andy Shevchenko
2026-06-24 4:18 ` me [this message]
2026-06-24 15:09 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edcf262b530a88ee602fa07edc8382ac@herrie.org \
--to=me@herrie.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=denis.ciocca@gmail.com \
--cc=denis.ciocca@st.com \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=github.com@herrie.org \
--cc=jic23@kernel.org \
--cc=justinstitt@google.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linusw@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox