linux-kernel - Re: [PATCH 0/3] drivers/thermal/qcom/tsens: Add ability to read and shift-in non-contiguous calibration data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZC7xSG7qVZ7vlOB7@gerhold.net>
Date:   Thu, 6 Apr 2023 18:20:34 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     amitk@...nel.org, thara.gopinath@...il.com, agross@...nel.org,
        andersson@...nel.org, konrad.dybcio@...aro.org, rafael@...nel.org,
        daniel.lezcano@...aro.org, rui.zhang@...el.com,
        dmitry.baryshkov@...aro.org, linux-pm@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] drivers/thermal/qcom/tsens: Add ability to read and
 shift-in non-contiguous calibration data

On Thu, Apr 06, 2023 at 03:58:47PM +0100, Bryan O'Donoghue wrote:
> On MSM8939 the last sensor has calibration data that cannot be extracted in
> one big read.
> 
> Rather than have a lot of MSM8939 specific code this series makes a generic
> modification to allow any other calibration data that is non-contiguous to
> be extracted and recovered.
> 
> For example s9-p2 takes bits 1-5 from @4b and bit 13 from @4d. The bit from
> bit13 then becomes the sixth bit in the calibration data.
> 
> tsens_s9_p2: s9-p2@4b {
>     reg = <0x4b 0x1>;
>     bits = <1 5>;
> };
> 
> tsens_s9_p2_msb: s9-p2-msb@4d {
>     reg = <0x4d 0x1>;
>     bits = <13 1>;
> };

As far as I can tell the sensor with the non-contiguous calibration data
is the one with hwid=10, so do you mean s10-p2 instead of s9-p2 here?

It's easy to mix up the numbering: Since hwid=4 is missing for MSM8939,
the sensor 9 in the calibration code downstream (TSENS9_8939_POINT*)
actually refers to hwid=10. hwid=9 is sensor 8 in the calibration code
(TSENS8_8939_POINT*).

Sensor hwid=10 was disabled for MSM8939 in the tsens driver because it
seems unused, only exists on MSM8939 v3.0, and specifically to avoid
having to handle this non-contiguous calibration data, see commit
903238a33c11 ("thermal/drivers/tsens: limit num_sensors to 9 for msm8939"):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=903238a33c116edf5f64f7a3fd246e6169cccfa6

> On msm8939 last (hwid=10) sensor was added in the hw revision 3.0.
> Calibration data for it was placed outside of the main calibration  
> data blob, so it is not accessible by the current blob-parsing code.
>
> Moreover data for the sensor's p2 is not contiguous in the fuses. This
> makes it hard to use nvmem_cell API to parse calibration data in a
> generic way.
>
> Since the sensor doesn't seem to be actually used by the existing
> hardware, disable the sensor for now.
>
> Fixes: 332bc8ebab2c ("thermal: qcom: tsens-v0_1: Add support for MSM8939")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>

So with sensor hwid=10 disabled, I think this patch series is actually
not needed? :)

Thanks,
Stephan