From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC710C433FE for ; Fri, 20 May 2022 14:09:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350109AbiETOJq (ORCPT ); Fri, 20 May 2022 10:09:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241098AbiETOJq (ORCPT ); Fri, 20 May 2022 10:09:46 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B933215A774 for ; Fri, 20 May 2022 07:09:44 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id u30so14515834lfm.9 for ; Fri, 20 May 2022 07:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=vuard3BQ666lW15aUwYrkgb69w+ZvJIZ35EbD+Vs+zo=; b=SMr1ToApPMAr9Z5v6I9b4LxuG57q3qN1bc0VWC2SBLBJ+mgdsPuBtTXHo8p8sK7Zex b1mSJzkATNbMBnZAh56xU5yBq5+iH2qWh0Z39zovRtV16d7H0NmOESjttleG9spSaUBD aMtSK//VkCE6aZgZwGBzW4ye/GXHVY+oLOKWbeD58Zd/OVN36L8jH1vN/Si36HlrNk7v k2WMQ+VgbaRJmFS+T4gS8Gm4sQHgbzJ0JnUWGZ4y/jXp/ljgNKHhW0bdcRp4UMNwyIDR aDs0PSA7khqyokgSEEmHAXXJiuzCwWsKemRwd+vDgIzPmIBrqlkn+cBOIpT+aoIEcmMw g77A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=vuard3BQ666lW15aUwYrkgb69w+ZvJIZ35EbD+Vs+zo=; b=S1o8uyvssLADBGWlEFNVb7E1tVWoLRRiZngKlSvVD6X8CmNV10kyS6BveIq1Jgz3pl K/TjjRnSpz3DP7l2rnP9EWnCWxpXC90SOiNLSVf0sFGxCUW481iXFaWpWcpuxMes0In8 Q4iLooLU3V4xUWeD9oWrwA4Q843M0e3EbW9bAVAvsuNwG4qSPKL7N/fgaW10VqgTPe6A 4pl4mCw5cohqzb/8N28zkxo2XyC49Ajz43wK+pwaP7Ow9M94PRAV1t7la0ECEZhHzboY b/wrFFiZU7AORlypOFLSQWAygTQVYLTuit4FwrGYU55r5UbC6LnhpZo/zaqpB4D7Swhs Z9XA== X-Gm-Message-State: AOAM530CpRHBfwfgFsHQjpMVpE0/7dr/g7z6z/HBcJayQS0TXubf/uoV fowUJin9j029ijj1WwLaSdd+/w== X-Google-Smtp-Source: ABdhPJxxF1FwBSixCKHv92Vfo4lkEASO1M7bSD7Y9WkXBg51EB/xFL5QKddl2zfo7G9YgSwk4F5+Uw== X-Received: by 2002:a05:6512:280e:b0:473:a0c9:5bdf with SMTP id cf14-20020a056512280e00b00473a0c95bdfmr6999980lfb.337.1653055783140; Fri, 20 May 2022 07:09:43 -0700 (PDT) Received: from [192.168.0.17] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id m12-20020ac2424c000000b00473c87152bcsm673434lfl.127.2022.05.20.07.09.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 May 2022 07:09:42 -0700 (PDT) Message-ID: Date: Fri, 20 May 2022 16:09:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH 3/8] dt-bindings: hwmon: Allow specifying channels for lm90 Content-Language: en-US To: Guenter Roeck , Slawomir Stepien , linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org Cc: jdelvare@suse.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, przemyslaw.cencner@nokia.com, krzysztof.adamski@nokia.com, alexander.sverdlin@nokia.com, Slawomir Stepien References: <20220520093243.2523749-1-sst@poczta.fm> <20220520093243.2523749-4-sst@poczta.fm> <3ea92486-0cf9-ce3d-d1b6-7a76f1d5a129@linaro.org> <0b84d109-d6be-dfba-99bb-0b7136af875e@roeck-us.net> From: Krzysztof Kozlowski In-Reply-To: <0b84d109-d6be-dfba-99bb-0b7136af875e@roeck-us.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 20/05/2022 15:42, Guenter Roeck wrote: >> >>> + A descriptive name for this channel, like "ambient" or "psu". >>> + >>> + offset: >>> + description: | >> >> This does not look like standard property, so you need vendor and unit >> suffix. >> > > Temperature offset is a standard property for temperature sensor The original description was strictly connected to registers, so that one as not a standard. It seems it was just a wording... > chips with external channels, implemented by a diode or transistor. > Making it non-standard will mean that we'll have lots of > "vendor,offset" properties, one each for each vendor selling > temperature sensor chips with external channels. This gets > more complicated here because the lm90 driver does support chips > from several different vendors. Almost all of them support > this functionality. Which vendor do you select in this case ? > > I would suggest to use temperature-offset-milliseconds, though. Yes, this sounds good. Just not seconds but millicelsius, I guess? > >>> + The value (millidegree Celsius) to be programmed in the channel specific offset register >>> + (if supported by device). >> >> You described programming model which should not be put in the bindings. >> Please describe the hardware. >> > > It is a configuration value, which is hardware dependent because > it depends on the temperature diode or transistor connected to the chip. Sure, so this could be reworded "Offset against some base value for each channel temperature", or something similar (you know better than me). Referring to registers and where exactly this should be programmed in the device is related to device programming model, not to bindings. Best regards, Krzysztof