Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp2739560rwi; Fri, 28 Oct 2022 10:34:55 -0700 (PDT) X-Google-Smtp-Source: AMsMyM57/KZbKNkwtERdUeiLGeOX3XN46qfESZDc1OqZjEtjYZjcNphZdL4CcoNjAP6m+2nRQw7D X-Received: by 2002:aa7:d996:0:b0:461:88b8:c581 with SMTP id u22-20020aa7d996000000b0046188b8c581mr523396eds.111.1666978495291; Fri, 28 Oct 2022 10:34:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666978495; cv=none; d=google.com; s=arc-20160816; b=h3IAAs1EtCLG7VBdiq/uIqZs6XEPdYw/JO9zGVsUTKxOEJ9NZQMhftzfPKo+NrVBSU FznZ7PMcfsHLQlyT7BPo9TI+z0INrGqABE3apHeMlfDnhFh7xOQLcZXotwrs40T8zh9b bnv6tX+Kd0srgWpxAEbR0SqTzEp50SS85YK6sKo2WJgl/9Ihg144krekjStSi0o7s0CZ 57NxeISpu3cGsY6VpLScMbnvB+ZcnTXLV03NSx1cACbddIpr3V1cLlRA8q4no+GMLcr0 5OQ4sNRygZtrJaLnKyEjA8FXqZnONd7Mp99QHi5iEkmvAWZnsUUw5+4Qsnsg3FqMHWj0 G+LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=nna6HJB9YaSUvl24pk2Q4b610mDplKaSBUmBELm3DPc=; b=JigXR9E+lJBgjzHRJrNk9YYZmvL9sDOGY2wdG1aXTS5Ehh1eOj7TBvY/Dq7r3hhaeM XeaCGnk209cKTauxWiIjiW0V9BFA1pp3Lirmctk/rCb7Ys5uOWqRvulxd8MPeHPs7jRq 1cBv71ntbQf8z7v0qpxdEqrGdwn7n9OywgoKsAwJB+5GK0ghT4UxFtpdQ6kjE3SdM7+0 waYVbjuWCZzTf5xW8bJ6FABtVnngrbKa+qp96wK0wOqa+IyxcymPNv0EFqF3M9/brAnP pQm9W9T4HyvMZLmMhwMUNs/IHAZUadDvW/WqZ4bz1HIx/R32V1BCg1NcI/PqKToOCH7i Cxgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc34-20020a17090716a200b0078d8db64fffsi5779925ejc.20.2022.10.28.10.34.29; Fri, 28 Oct 2022 10:34:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231131AbiJ1RNn (ORCPT + 99 others); Fri, 28 Oct 2022 13:13:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230499AbiJ1RN1 (ORCPT ); Fri, 28 Oct 2022 13:13:27 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D5BD768CFE; Fri, 28 Oct 2022 10:12:18 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D8A121FB; Fri, 28 Oct 2022 10:12:24 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A29C93F703; Fri, 28 Oct 2022 10:12:17 -0700 (PDT) Date: Fri, 28 Oct 2022 18:12:11 +0100 From: Cristian Marussi To: Guenter Roeck Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, Daniel Lezcano , linux-hwmon@vger.kernel.org Subject: Re: [PATCH 7/8] hwmon: (scmi) Register explicitly with Thermal Framework Message-ID: References: <20221028140833.280091-1-cristian.marussi@arm.com> <20221028140833.280091-7-cristian.marussi@arm.com> <7acc7a49-debb-abdb-f01c-f8adef4c1f0e@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7acc7a49-debb-abdb-f01c-f8adef4c1f0e@roeck-us.net> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 28, 2022 at 09:34:05AM -0700, Guenter Roeck wrote: > On 10/28/22 09:15, Cristian Marussi wrote: > > On Fri, Oct 28, 2022 at 08:58:58AM -0700, Guenter Roeck wrote: > > > On 10/28/22 08:35, Cristian Marussi wrote: > > > [ ... ] > > > > > > + /* > > > > > > + * Try to register a temperature sensor with the Thermal Framework: > > > > > > + * skip sensors not defined as part of any thermal zone (-ENODEV) but > > > > > > + * report any other errors related to misconfigured zones/sensors. > > > > > > + */ > > > > > > + tzd = devm_thermal_of_zone_register(dev, th_sensor->info->id, th_sensor, > > > > > > + &scmi_hwmon_thermal_ops); > > > > > > + if (IS_ERR(tzd)) { > > > > > > + devm_kfree(dev, th_sensor); > > > > > > + > > > > > > + if (PTR_ERR(tzd) != -ENODEV) > > > > > > + return PTR_ERR(tzd); > > > > > > + > > > > > > + dev_info(dev, "Sensor '%s' not attached to any thermal zone.\n", > > > > > > + sensor->name); > > > > > > > > > > There were complaints about this message as it is noisy. If you send > > > > > another version, please drop it unless attaching each sensor to a thermal > > > > > zone is strongly expected. If you don't send another version, I'll drop it > > > > > while applying. > > > > > > > > > > > > > Ok fine for me. I am waiting to have some feedback from Sudeep too, but > > > > I do not have plan for another version as of now. > > > > > > > > As a side note, though, I understand the 'noisiness' argument, but, > > > > sincerely this same message in the original HWMON code was the only > > > > reason why I spotted that something was wrong with the SCMI/HWMON > > > > interactions and discovered the indexes/ids mismatch...if not for > > > > that it would have gone un-noticed that a perfectly configured > > > > ThermalZone/Sensor was not working properly... > > > > (un-noticed at least until something would have been burnt to fire > > > > in my house .. joking :P) > > > > > > > > > > Good point. > > > > > > Did you ever check the returned error code ? Maybe we could use it to > > > distinguish "it is not attached to a thermal zone because it is not > > > associated with one" from "attaching to a thermal zone failed because > > > its configuration is bad/incomplete". > > > > > > > Yes, it is what I do already indeed, in this regards I mimicked what > > the hwmon-thermal bridge was doing. > > > > In scmi_thermal_sensor_register() this message is printed out only > > if Thermal registration returned -ENODEV and no err is reported > > (which means teh specified sensor was not found attached to any TZ), > > while in the caller of scmi_thermal_sensor_register() for any error > > returned but -ENOMEM I print: > > > > "Thermal zone misconfigured for %s. err=%d\n", > > > > since any error reported by Thermal other than ENODEV and ENOMEM > > means the DT parsing unveiled some configuration anomaly. > > > > Ok, then let's hope that this finds misconfigurations and drop the > info message. The mismatch of indexes at hand won't be catched being reported by Thermal as misconfig but just as not found ENODEV. Anyway it is fine for me to drop the message. > > I just noticed another problem in your code: > > + if (ret == -ENOMEM) > + return ret; > + else if (ret) > + dev_warn(dev, > + "Thermal zone misconfigured for %s. err=%d\n", > + sensor->name, ret); > > Static analyzers will rightfully notice that else after return is unnecessary. > Please rewrite and drop the else. I think something like > Ah yes...my bad. > if (ret) { > if (ret == -ENOMEM) > return ret; > dev_warn(dev, > "Thermal zone misconfigured for %s. err=%d\n", > sensor->name, ret); > } > > would be better since ret would only be evaluated once in the no-error case. > I'll resend this one with the fix and the dropped message. Thanks, Cristian