[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240810112712.191d6576@jic23-huawei>
Date: Sat, 10 Aug 2024 11:27:12 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Barnabás Czémán <barnabas.czeman@...nlining.org>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Jonathan Albrieux <jonathan.albrieux@...il.com>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux@...nlining.org
Subject: Re: [PATCH v2 1/3] iio: magnetometer: ak8975: Fix reading for
ak099xx sensors
On Tue, 06 Aug 2024 19:54:56 +0200
Barnabás Czémán <barnabas.czeman@...nlining.org> wrote:
> On August 6, 2024 6:19:25 PM GMT+02:00, Jonathan Cameron <jic23@...nel.org> wrote:
> >On Tue, 06 Aug 2024 08:10:18 +0200
> >Barnabás Czémán <barnabas.czeman@...nlining.org> wrote:
> >
> >Hi Barnabás,
> >
> >Welcome to IIO.
> >
> >> ST2 register read should be placed after read measurment data,
> >> because it will get correct values after it.
> >
> >What is the user visible result of this? Do we detect errors when none
> >are there? Do we have a datasheet reference for the status being
> >update on the read command, not after the trigger?
>
> Second read will fail. In the datasheet ST2 comes after measurment data read. Here is some explanation from datasheet.
>
> "When ST2 register is read, AK09918 judges that data reading is finished. Stored measurement data is
> protected during data reading and data is not updated. By reading ST2 register, this protection is
> released. It is required to read ST2 register after data reading."
>
Thanks. Please add more of that detail to the patch description for v3.
> So if ST2 is read before measurment it will stuck at protected mode.
> >>
> >Needs a Fixes tag to let us know how far to backport the fix.
> I think it is broken since 09912 was added but i cannot verify i have only devices with 09918.
> >
I wasn't meaning devices, but rather what patch broke the kernel code.
It might be the original driver introduction.
If we can add a Fixes tag that makes it much easier for stable + distributions
to work out whether to pick the fix up or not.
Powered by blists - more mailing lists