Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Tue, 22 Feb 2022 08:23:35 +0100
From:   Krzysztof Adamski <krzysztof.adamski@nokia.com>
To:     Guenter Roeck <linux@roeck-us.net>,
        Rob Herring <robh+dt@kernel.org>
Cc:     linux-hwmon@vger.kernel.org, Agathe Porte <agathe.porte@nokia.com>,
        Jean Delvare <jdelvare@suse.com>, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/2] dt-bindings: hwmon: add tmp464.yaml
Message-ID: <YhSPd79vHLO+73ln@localhost.localdomain>
References: <20220218150908.1947772-1-linux@roeck-us.net>
 <YhNWVLHYVtCvdGhi@localhost.localdomain>
 <66e6b131-274f-454b-44f6-17df879d71a9@roeck-us.net>
 <YhQDGHD3S0qwP2OB@localhost.localdomain>
 <238e6fb0-cd77-4772-3e92-23941dc74403@roeck-us.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <238e6fb0-cd77-4772-3e92-23941dc74403@roeck-us.net>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a0l3UU5iYmdyMFd0YWUxK3E2dklOb2FJZjU5M1I3UnRDUmRBZy81VFBJb01k?=
 =?utf-8?B?QklUTGNRSWo5WVpXVXVKTXZMelRWY3dDR3FZVXZBRWo1em9rWXBzSEdXTWxF?=
 =?utf-8?B?aHRvVVBsM2UxNGd5TkV0UGttL2paWVlVZUFnRmYyUlFPSmM2aTAxNFdVd1Bh?=
 =?utf-8?B?blZLeDh2WG8vTVM1dk96Q0tPYzBCdmlYZE54MmNxS3RzUC9jeEExNHdBeUNs?=
 =?utf-8?B?UmN1c3liTFE2OHllUVVQRGI4dEFJaVR1VU9pZXFUeEg3U3RVTmRiR2xlMEpa?=
 =?utf-8?B?WVlSd3hyMVdPS1VXSTVLcmZ3R1czVGNlTHE3OWJsbEZuakNwSXQyYytUeW9R?=
 =?utf-8?B?bnJ0N2p3SnB5d3R1WFNXbFFkSS9EY3cwelZGaC9nYWJZRXBTdkFEbGNtdUlW?=
 =?utf-8?B?blQ5TGtHblByakJGZFVOV0pLc1hBZks1UTR6NXVBdEdtUnJNU2tyT0pXei9r?=
 =?utf-8?B?Nkc1bHErd21RSC85UmpPdXUzM1NodWNZTEg2M255ZUZUZnV3TGl1K2ljbVY0?=
 =?utf-8?B?UUhrY0NsZlBndlFyVDdLdUR2SU10MTZCbEgvVm1LVW5DNVJaQWFadDFzckl1?=
 =?utf-8?B?N2JIelBRUGM0anlMSlZmeHBqcDM1QVIwNE9DZlpjS3RVK044d2sxdkNaaW9X?=
 =?utf-8?B?REhEMXdRekF3R2tiV2t2QVdJbUMvUEhqNnZQMFlKN09lMUd5RllMd2pBTnRM?=
 =?utf-8?B?a0FaUExwaWJ0cEM4WFREZWpWVENUdXB1UFVVTVZwZmluUzZoT3R5bUtTWnhI?=
 =?utf-8?B?T3EyaENrWDMxZWIyZW1scHRMRE5iTzVjV0Fsam8xZkNVZHhlbUJGTytoWWxr?=
 =?utf-8?B?ZVNNZSt6TmFON0lhOXpSUXd5WHVxQktWVUpncE9YL2NEYkZnalRxMzd4YUs3?=
 =?utf-8?B?NHoxTDVMZkZLTnhSdENxdTZTWmxjaURCU3pPVG5ia2ZTTktsSjUxejRteUxX?=
 =?utf-8?B?bGlDeHRqaU0yVEtJTGFQeTV1eHBvM3JacWlzeTlGOHI1M1J0Mk5oTndWTy9K?=
 =?utf-8?B?MHViNnkzbUZWNUR2M1FrMmsyOGxoQ1ZzaFJWMFZPdTNHWjZSSUpTVnBQY2p1?=
 =?utf-8?B?T2hDaHVaeEgxclI4OWxFUm5rNDNCcStDaDFwM0w0Y2J1Uy9EWDZSbnY1ZFZy?=
 =?utf-8?B?eWt1RS82TEsrOFhhTFhOV2IvNW51WjhJazFZWVRyS0RQTFVtTkNONXk1UU1O?=
 =?utf-8?B?aVJDaDlqR0g0eW8yc1BHY3Bsd3Y4QlNSaXdIYVQyOW0xYTJ0SGRPRE5LUHEv?=
 =?utf-8?B?YWdQb05oYVd4akVzcllCMUw5bzZvdXZvbjdSK1pHY0xzR1AxVDVGc2RVYmhK?=
 =?utf-8?B?ZGpmazVCRHV0UlVxaktvdk9MODVrVG5aM0FsN3lUQWJBWnpveXpoelFzdExu?=
 =?utf-8?B?clVFa1cxaDh0MVNHUWRES3ZEeWF4OURTeno2SGR2dUJxR1pXQ3h4aC9YcWxr?=
 =?utf-8?B?RktFcmt2ck9IcUlJZElZbEZXamp3TUxoMTFRZ0Jmbkh0S29VbldqWGNrVEpS?=
 =?utf-8?B?S29SQjJlWGcvVjRaZ0pzdGJ0RjhnWC90dTdiMGRVVURmRmM0Y3ZySGp4MWtk?=
 =?utf-8?B?Yy9NOVE3djlnb3hVb1VTTGJ1L0RvUUxTYzArbzNkQ2VpU0EvVlhLZUc5R0dO?=
 =?utf-8?B?aGNRTjZ3ZHBrSFZ6Mi9aVytmWFE3MHdxUS9tK1l2QWQrT3hzblNZTkxrYUNN?=
 =?utf-8?B?VExHanQ5WU5DdUZ6Q0VnaEN1S0pxRTd5M2ROcm00aDkzZFlsMW9UTzBqeGFL?=
 =?utf-8?B?U0c0VEhnWHJ4WTJOM0lyb04xMElzTEVReXFPb0lGcHZxNE1YaklQYzQ5YjVM?=
 =?utf-8?B?YlJHOE0vQ3k1UlpERXErVG5meno2ZUZBZmh4TmdsWlVOQVl2V09wTDZzbEpv?=
 =?utf-8?B?aUswU2I4aTRYZVBqcS90T0NBN1lLSVVRT3dCdFkzSFcwTm02MTE1VHpKQ3Jq?=
 =?utf-8?B?c3FUSzh3dW0vQms4Z2NQbjJJanJsc09EeitGb2lDZENKU3R0a0ZhaGx5MzQx?=
 =?utf-8?B?aFFzQnpNaSthMDFsM1VrR1RnNjZSNVJ4NFZJU1FmUE9IOWQ4VDNpQllQZ1hP?=
 =?utf-8?B?c3NNQ216Lzh5cHN2Q3ZFeXdRM3JNWXlqWUVRekpBSTRMTXRUQUwrM2w2RHBW?=
 =?utf-8?B?Sks1cVF0MWJxcytHTzI4L1RjclYrcE1ZaXNXRlhrRmV3QVoyaUZvcjI1OFFE?=
 =?utf-8?B?bHA4Uk9jUndtc2cwdVhGYzkwOG5LWm1tTWNiUW1tSzRrL0l0QUhMOTNPeHZi?=
 =?utf-8?B?amZpNndycEdTdUdSMWpPTnZ1RjV3PT0=?=
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 65f44832-257a-44fe-154a-08d9f5d444d2
X-MS-Exchange-CrossTenant-AuthSource: DU2PR07MB8110.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2022 07:23:48.8469
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: h1wiKmsCJnzW2Z6fKfGsKeiPciUJUBBqDrKw48JLztIQk2NrtSCpGkiaTZpKYrG1co0cv4MDrFyuu48ZPku+lO6Hgiowh7dQTmBtt7H9o9A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5217
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Dnia Mon, Feb 21, 2022 at 02:11:17PM -0800, Guenter Roeck napisał(a):
>On 2/21/22 13:24, Krzysztof Adamski wrote:
>>Dnia Mon, Feb 21, 2022 at 08:16:15AM -0800, Guenter Roeck napisał(a):
>>>>I still thing we should have the same format here and in tmp421, for
>>>>consistency. If use the same property name, "ti,n-factor" but on tmp421
>>>>you have use 32bit value while here you have to use 8bit (which is weird
>>>>in DT, BTW), it might be confusing.
>>>>Back when we did this for TMP421, there was some discussion and we
>>>>settled on this approach, why do it differently now?
>>>>
>>>
>>>I seem to recall from that discussion that there was supposedly no way to
>>>express negative numbers in devicetree. Obviously that is incorrect.
>>
>>Well, I would still argue it *is* correct. DT only support unsigned
>>numbers and, really, only 32 or 64 bit. See the chapter 2.2.4 Properties
>>in:
>>https://github.com/devicetree-org/devicetree-specification/releases/download/v0.4-rc1/devicetree-specification-v0.4-rc1.pdf
>>
>>Devicetree also supports array of bytes, and this is how we get the
>>/bits/ magic but this is just a syntactic suggar. The same is true about
>>negative values. Just decompile your compiled DTB and you will see.
>>To put it in other words - DTS does support negative values, DTB don't.j
>>
>>>In addition to that, I strongly suspect that the tmp421 code as written
>>>does not work. Its value range is specified as 0..255, but it is read with
>>>    err = of_property_read_s32(child, "ti,n-factor", &val);
>>>and range checked with
>>>    if (val > 127 || val < -128) {
>>>               dev_err(dev, "n-factor for channel %d invalid (%d)\n",
>>>                      i, val);
>>>               return -EINVAL;
>>>       }
>>>
>>>That just looks wrong. Either the value range is 0..255 and checked
>>>as 0 .. 255, or it is -128 .. 127 and must be both checked and specified
>>>accordingly. This made me look into the code and I found how negative
>>>numbers are supposed to be handled.
>>
>>It worked for me when I tested that. I could redo the test, if you are
>>unsure. The code also looks good to me. I wasn't convinced for this
>>format in yaml but after the whole discussion we had, we settled on
>>that, with Robs blessing :)
>>
>
>It is hard for me to believe that you can enter, say, 255 into the dts file
>and of_property_read_s32() reads it as -1. If so, of_property_read_s32()
>could never support values of 128 and above, which seems unlikely.
>
>Now, I can imagine that one can enter 0xffffffff and of_property_read_s32()
>returns -1, but that isn't what is documented for tmp421.
>

Yes, you are correct, you have to enter either <(-1)> or <0xffffffff>
(which is the same thing). I was quite confused on how to specify that
in DT bindings and apparently maybe we did not understand each other
well enough back when the patch was submitted. The code and the
description is correct, though, so the question is how to properly set
"minimum" and "maximum" value.

I think I should at least update the example of tmp421 in the binding to
use <(-1)> notation to make it obvious that it works this way. But I
guess we need Rob to help us understand how this should be specified.

In any case, if you drop usage of /bits 8/ and keep the property naitive
32 bit, both tmp421 and tmp464 bindings will be compatible with each
other.

@Rob, if I want a property ti,n-factor be in in range from <(-128)> to
<127>, so that we can use of_property_read_s32() and then use just one
byte of that, how to specify that in yaml file? For TMP421, we currently
have:

  ti,n-factor:
    description: |
      The value (two's complement) to be programmed in the channel specific N correction register.
      For remote channels only.
    $ref: /schemas/types.yaml#/definitions/uint32
    items:
      minimum: 0
      maximum: 255

which is confusing.

Guenter is proposing to use
  $ref: /schemas/types.yaml#/definitions/int8
  items:
    minimum: -128
    maximum: 127

and of_property_read_u8() for the same property on another driver, so
usage of /bits/ 8 is required. Which approach is better in your opinion?

Krzysztof


Krzysztof