Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2782665yba; Fri, 10 May 2019 19:32:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqy4L4H/S0y6dGQTPl4kr1qGZcUwC6Si/Yab4yTtN2dQCym8OV35a3CuwPu6flEiyRg1rnvm X-Received: by 2002:a63:4346:: with SMTP id q67mr17404932pga.241.1557541946409; Fri, 10 May 2019 19:32:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557541946; cv=none; d=google.com; s=arc-20160816; b=rOKhsEKMlL0bKuGvCFY0mk060qW/2/3rW5rigo/yIRzxwsy3Pz9Ptxwi5S0L4UQGlC XzFsxfbkOPbcYgqx7H7GCXRRgH68GhWupnoFHQ++xv3p2z7sCr86AEn6SnOMSKioW7Jx gWY/dRL2PKcXfLAyL2aN9uXw/pAsTcUg95KhCr1f9kpXpt1JBmsyFCe4FjvtZUV1uyCz 9hCz9xiseYJlq2HgFU9qUlwhIn3EHdA4o4vs6+PE/1yown8vrxqVbIeVvGNA/7paDAuh si/5sJe14OLYTRDDFafdZ57aGG1WR+Nw22NDExzB1GDa7LN1fNSGNpoTWTWfGtH7qLSO MnmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=QkHid6lisLXvpmq0JMNlVb1recKQukJ7PuauuXWUQBw=; b=usgdlwd2QmtQLPJ0k+aA/bWia+1suQoc0xmLGazkHaO9chNOWYEhmNt1sUCo68f+YL U5f03e5g3LHdyzqP6s0RQ5YvQRV55gvQtIHpr52k60GU3a+VCRT6zzXAIawtQlvvITqN e/gQXyAOIg6w5MZ9jGJSkb4Aj6ZGiw3VLnUxjyjOZk4ZA/KXnb1tNq5Uzgd/t7CIPDFG iXUZ0CLNxchEyAAdfaCrbx0oV5qsveB9U+QRxUFgjHXodBEXLvKHeFoGn8MLLL7zSmcs uRlOCD1oytd0f3j7SHwbaSKl3+7qPGDJHfkEOY0v0Q5xIPVvJaNEbItBhebZ/XcvMImB 8amw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=CFYwUdlb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q73si9784291pfi.5.2019.05.10.19.32.09; Fri, 10 May 2019 19:32:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=CFYwUdlb; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728363AbfEKCbV (ORCPT + 99 others); Fri, 10 May 2019 22:31:21 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:35253 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728208AbfEKCbV (ORCPT ); Fri, 10 May 2019 22:31:21 -0400 Received: by mail-qt1-f193.google.com with SMTP id a39so8074785qtk.2 for ; Fri, 10 May 2019 19:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QkHid6lisLXvpmq0JMNlVb1recKQukJ7PuauuXWUQBw=; b=CFYwUdlb6kDt1NhEEjrC0A0nuRHWn/prCx1A1kIqu1GhRZfmdY8bgahc02/X19llbd fvxssMqrQQ6Z/4ELAilm0gKIZ0OkiTljAKrePdvGDo8GmzBW4bSQ+Pk9F/xHwraaTGug hP27VQvggJlYqYGyMP2FvkeRHxg3gYVJdXK60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QkHid6lisLXvpmq0JMNlVb1recKQukJ7PuauuXWUQBw=; b=pPCQVSHo438qUIz4oCI60HCIH8x5Ien8vh1DbWiQ+YRCW+NJ+kzSNNhWmvZTqBewjt iGEgBoBKw03ElslNgOGcoHXXvZbMypfxx03+TbwRk4ChSP0+t0e8nHedNiOZI4COmmqX J0FKpXicZ0TAgAc0nHoEO14GPVlqyrdVBjtXejPF26y8wuHzk3EWjTCxD+b7D661X+J7 DZCNe8BxvmYuHUcJ5N9fijzIHIlxCs8XtpQ8HkJbF59VcvNSWxdTQ7NeXotrTnMHOifV DwAQ/QNCyFTFrtk4lCbeaImRC5vzp0/Mm7iqGoPsw5fI2XqA0HULLQ84zN9PzuvPcDgw aCeQ== X-Gm-Message-State: APjAAAWatBTK+0yB8rVa//yIRhxJ63ux2SuM7Z0WPj/vw9kXFTvj0c2A p1SYsIDTTVQeYtAAlFJSyo0KdLhbPAtRCIUfUE9vrg== X-Received: by 2002:a0c:ee28:: with SMTP id l8mr11862487qvs.67.1557541879585; Fri, 10 May 2019 19:31:19 -0700 (PDT) MIME-Version: 1.0 References: <1556793795-25204-1-git-send-email-michael.kao@mediatek.com> <1556793795-25204-8-git-send-email-michael.kao@mediatek.com> In-Reply-To: <1556793795-25204-8-git-send-email-michael.kao@mediatek.com> From: Nicolas Boichat Date: Sat, 11 May 2019 11:31:08 +0900 Message-ID: Subject: Re: [PATCH 7/8] thermal: mediatek: add another get_temp ops for thermal sensors To: "michael.kao" Cc: Fan Chen , James Liao , dawei.chien@mediatek.com, louis.yu@mediatek.com, roger.lu@mediatek.com, Zhang Rui , Eduardo Valentin , Daniel Lezcano , Rob Herring , Mark Rutland , Matthias Brugger , devicetree@vger.kernel.org, "moderated list:ARM/Mediatek SoC support" , lkml , linux-arm Mailing List , linux-pm@vger.kernel.org, Hsin-Yi Wang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 2, 2019 at 7:45 PM michael.kao wrote: > > From: Michael Kao > > Provide thermal zone to read thermal sensor > in the SoC. We can read all the thermal sensors > value in the SoC by the node /sys/class/thermal/ > > Signed-off-by: Michael Kao > --- > drivers/thermal/mtk_thermal.c | 68 ++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 60 insertions(+), 8 deletions(-) > > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c > index cb41e46..d5c78b0 100644 > --- a/drivers/thermal/mtk_thermal.c > +++ b/drivers/thermal/mtk_thermal.c > @@ -230,6 +230,11 @@ enum { > > struct mtk_thermal; > > +struct mtk_thermal_zone { > + struct mtk_thermal *mt; > + int id; > +}; > + > struct thermal_bank_cfg { > unsigned int num_sensors; > const int *sensors; > @@ -612,7 +617,7 @@ static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank) > * not immediately shut down. > */ > if (temp > 200000) > - temp = 0; > + temp = -EACCES; EACCES/permission denied doesn't really seem to be the right error code here. Maybe EAGAIN? > > if (temp > max) > max = temp; > @@ -623,7 +628,8 @@ static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank) > > static int mtk_read_temp(void *data, int *temperature) > { > - struct mtk_thermal *mt = data; > + struct mtk_thermal_zone *tz = data; > + struct mtk_thermal *mt = tz->mt; > int i; > int tempmax = INT_MIN; > > @@ -636,16 +642,48 @@ static int mtk_read_temp(void *data, int *temperature) > > mtk_thermal_put_bank(bank); > } > - I'd drop that change. > *temperature = tempmax; > > return 0; > } > > +static int mtk_read_sensor_temp(void *data, int *temperature) > +{ > + struct mtk_thermal_zone *tz = data; > + struct mtk_thermal *mt = tz->mt; > + const struct mtk_thermal_data *conf = mt->conf; > + int id = tz->id - 1; > + int temp = INT_MIN; No need to initialize temp. > + u32 raw; > + > + if (id < 0) > + return -EACCES; EINVAL? > + > + raw = readl(mt->thermal_base + conf->msr[id]); > + > + temp = raw_to_mcelsius(mt, id, raw); > + > + /* > + * The first read of a sensor often contains very high bogus > + * temperature value. Filter these out so that the system does > + * not immediately shut down. > + */ > + nit: Drop this blank line > + if (temp > 200000) > + return -EACCES; Again, EAGAIN, maybe? > + > + *temperature = temp; > + return 0; > +} > + > static const struct thermal_zone_of_device_ops mtk_thermal_ops = { > .get_temp = mtk_read_temp, > }; > > +static const struct thermal_zone_of_device_ops mtk_thermal_sensor_ops = { > + .get_temp = mtk_read_sensor_temp, > +}; > + > static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num, > u32 apmixed_phys_base, u32 auxadc_phys_base, > int ctrl_id) > @@ -878,6 +916,7 @@ static int mtk_thermal_probe(struct platform_device *pdev) > struct resource *res; > u64 auxadc_phys_base, apmixed_phys_base; > struct thermal_zone_device *tzdev; > + struct mtk_thermal_zone *tz; > > mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL); > if (!mt) > @@ -959,11 +998,24 @@ static int mtk_thermal_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, mt); > > - tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, mt, > - &mtk_thermal_ops); > - if (IS_ERR(tzdev)) { > - ret = PTR_ERR(tzdev); > - goto err_disable_clk_peri_therm; > + for (i = 0; i < mt->conf->num_sensors + 1; i++) { > + tz = kmalloc(sizeof(*tz), GFP_KERNEL); Are we leaking this pointer? Should this be devm_kmalloc? > + if (!tz) > + return -ENOMEM; > + > + tz->mt = mt; > + tz->id = i; > + > + tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, i, > + tz, (i == 0) ? > + &mtk_thermal_ops : &mtk_thermal_sensor_ops); > + > + if (IS_ERR(tzdev)) { > + if (IS_ERR(tzdev) != -EACCES) { Why would EACCES ever happen? AFAICT devm_thermal_zone_of_sensor_register does not actually try to read the temperature value? Or does the error come from somewhere else? > + ret = PTR_ERR(tzdev); > + goto err_disable_clk_peri_therm; > + } > + } > } > > return 0; > -- > 1.9.1 > > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek