Hi,
On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria <amit.kucheria@xxxxxxxxxx> wrote:
> SDM845 uses v2 of the TSENS IP block but the get_temp() function
> appears to be identical across v2.x.y in code seen so far. We use the
> generic get_temp() function defined as part of ops_generic_v2.
>
> Signed-off-by: Amit Kucheria <amit.kucheria@xxxxxxxxxx>
> ---
> drivers/thermal/qcom/tsens-v2.c | 6 +++++-
> drivers/thermal/qcom/tsens.c | 3 +++
> drivers/thermal/qcom/tsens.h | 5 ++++-
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
> index 34ba6c7..f40150f 100644
> --- a/drivers/thermal/qcom/tsens-v2.c
> +++ b/drivers/thermal/qcom/tsens-v2.c
> @@ -69,8 +69,12 @@ static const struct tsens_ops ops_generic_v2 = {
> .get_temp = get_temp_tsens_v2,
> };
>
> +const struct tsens_data data_tsens_v2 = {
> + .ops = &ops_generic_v2,
> +};
> +
> +/* Kept around for backward compatibility with old msm8996.dtsi */
> const struct tsens_data data_8996 = {
> .num_sensors = 13,
> .ops = &ops_generic_v2,
> };
Something seems fishy here. You have a ".num_sensors" for sdm8996
hardcoded to 13 but you don't have a ".num_sensors" for your new v2.
Where does num_sensors get set for everyone else? In patch #3 you
have a new "#qcom,sensors" but:
1. Nothing reads this as far as I can tell, so that means everyone
will end up with 0 sensors.
2. On your 2nd block of sensors in the sdm8996 device tree (see
earlier patch in the series) you try to set qcom,sensors to 8. ...but
since you still have a compatible of "qcom,msm8996-tsens" you'll get
13. That seems wrong. ...or did I miss something?
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
