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 056EFC433FE for ; Mon, 23 May 2022 15:23:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237790AbiEWPXp (ORCPT ); Mon, 23 May 2022 11:23:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237844AbiEWPXk (ORCPT ); Mon, 23 May 2022 11:23:40 -0400 Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 160A45DBEE for ; Mon, 23 May 2022 08:23:02 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id s5so17606793ljd.10 for ; Mon, 23 May 2022 08:23:02 -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=D5XQc8wBj+L7y1AKbIXLkcUnNCOQ5528vAYo2Vyy7WQ=; b=M7gmNtjCllRiORAgUIpKMPSb7oS9uKwtrDvNNzoyTSoMLPRhnQOtG/+dKE/mFFVndU OfXjCys6aayQms2XeXouvsn8NgCDzlz0jOVSflxi7+EqCuu+XZjYixHkZyqBHuLr7CDl dD4XtHTv7NOSdCzZTaYJCqNAZvGSGBAPr1ly0HApxqUZGYG8+iDidxUBZAb9UlWAqHV0 Coi2FFoPTpsFeNwdSX11azNbYK6bnKxbsLyffFRXG71CUcsDmlq618ZtEM6OHvDrntvy 7THTrF2vJ0lk90FcFauZANDwpRTJULBxAKwr6HbwVfOpds4TPAnexwSdK0fzsqFNybYo v+lg== 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=D5XQc8wBj+L7y1AKbIXLkcUnNCOQ5528vAYo2Vyy7WQ=; b=l2iwVH0i+VsqiJ6Bx0+LHIu0V9venuse1dnFfvDzy0ArTi66Q9B6FPBhPyb3QaGW4C PQU2R6lkZ7l2DmHyger53u5RfZMew/TrYUl0Zf4o6oDvcIU8RH6E0wLxbalgt1uXe13x 1kHcu3gCRO/2RThpyggNHcG0x+caTE0T80yhDcEDkdIn1pHGjppvxRWnXZZCsPbBotSB QrSYRgBif8V7MMZuVqqASoUXzrXqfm0++V1dfUV+Mwu7rCQnstI+EWLSnDbhhrF0WgHW B91tO1kMlV0CDW8pbmvTGYgejXNmiUipJiRQc2H7JSnNaEpxdwYyVDTbHV7DURMLy49S 3sAw== X-Gm-Message-State: AOAM532zQ7htKY8Phs31XdzJNV2nGdD5h0MmHheoyum1HeJUvZywD8aO h0WJKz2fcFEGfGGNY/jYlCOYfw== X-Google-Smtp-Source: ABdhPJyVAM7kdjjShrP2QVKN0ERRYTn2eTJCgTp0tcXYWrz6bJpRhAVwFD/O3F0/8vaeprEbpanvdw== X-Received: by 2002:a2e:9655:0:b0:253:d575:9a6d with SMTP id z21-20020a2e9655000000b00253d5759a6dmr12647403ljh.207.1653319380816; Mon, 23 May 2022 08:23:00 -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 j16-20020a2e3c10000000b00253c33d30f0sm1889534lja.87.2022.05.23.08.22.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 May 2022 08:23:00 -0700 (PDT) Message-ID: Date: Mon, 23 May 2022 17:22:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v1 11/19] dt-bindings: reset: npcm: Add support for NPCM8XX Content-Language: en-US To: Geert Uytterhoeven Cc: Tomer Maimon , Avi Fishman , Tali Perry , Joel Stanley , Patrick Venture , Nancy Yuen , Benjamin Fair , Rob Herring , Krzysztof Kozlowski , Michael Turquette , Stephen Boyd , Philipp Zabel , Greg KH , Daniel Lezcano , Thomas Gleixner , Wim Van Sebroeck , Guenter Roeck , Catalin Marinas , Will Deacon , Arnd Bergmann , Olof Johansson , Jiri Slaby , Shawn Guo , =?UTF-8?Q?Bj=c3=b6rn_Andersson?= , Marcel Ziswiler , Vinod Koul , Biju Das , Nobuhiro Iwamatsu , Robert Hancock , =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= , Lubomir Rintel , arm-soc , devicetree , Linux Kernel Mailing List , linux-clk , "open list:SERIAL DRIVERS" , Linux Watchdog Mailing List , Linux ARM References: <20220522155046.260146-1-tmaimon77@gmail.com> <20220522155046.260146-12-tmaimon77@gmail.com> <86cd6a37-70ad-3a90-bc8a-dcd8b41f1175@linaro.org> <62562cdf-93e3-f642-5bbd-48329eff33ea@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/05/2022 17:11, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Mon, May 23, 2022 at 4:26 PM Krzysztof Kozlowski > wrote: >> On 23/05/2022 16:22, Geert Uytterhoeven wrote: >>> On Mon, May 23, 2022 at 4:03 PM Tomer Maimon wrote: >>>> On Mon, 23 May 2022 at 12:01, Krzysztof Kozlowski wrote: >>>>> On 22/05/2022 17:50, Tomer Maimon wrote: >>>>>> Add binding document and device tree binding >>>>>> constants for Nuvoton BMC NPCM8XX reset controller. >>>>>> >>>>>> Signed-off-by: Tomer Maimon >>> >>>>>> --- /dev/null >>>>>> +++ b/include/dt-bindings/reset/nuvoton,npcm8xx-reset.h >>>>>> @@ -0,0 +1,124 @@ >>>>>> +/* SPDX-License-Identifier: GPL-2.0 */ >>>>>> +// Copyright (c) 2022 Nuvoton Technology corporation. >>>>>> + >>>>>> +#ifndef _DT_BINDINGS_NPCM8XX_RESET_H >>>>>> +#define _DT_BINDINGS_NPCM8XX_RESET_H >>>>>> + >>>>>> +#define NPCM8XX_RESET_IPSRST1 0x20 >>>>>> +#define NPCM8XX_RESET_IPSRST2 0x24 >>>>>> +#define NPCM8XX_RESET_IPSRST3 0x34 >>>>>> +#define NPCM8XX_RESET_IPSRST4 0x74 >>>>> >>>>> What are these? All IDs should be incremental, decimal and start from 0. >>>> >>>> Register offset, we use the same method in NPCM7xx. please refer >>>> https://elixir.bootlin.com/linux/v5.18/source/include/dt-bindings/reset/nuvoton,npcm7xx-reset.h >>>> >>>> and the driver asserts the reset according to the reset include definitions >>> >>> So if they're easy to look up the values, you could do without the >>> definitions? Cfr. the interrupts properties in .dtsi files, where we >>> typically just use the hardcoded numbers. >>> >>> If you do decide to keep them, a comment explaining their origins >>> would be useful. >>> >>>>>> + >>>>>> +/* Reset lines on IP1 reset module (NPCM8XX_RESET_IPSRST1) */ >>>>>> +#define NPCM8XX_RESET_GDMA0 3 >>>>> >>>>> IDs start from 0 and do not have holes. >>>> >>>> This represents the reset BIT in the reset register. >>> >>> Likewise, I think it's a good idea to document that in a comment, cfr. >>> https://elixir.bootlin.com/linux/v5.18/source/include/dt-bindings/power/r8a7795-sysc.h#L8 >> >> Renesas is also doing it not correct (just like many others). The >> bindings are not for register bits or offsets. Such data can be DTS but >> not part of bindings. > > I think you are taking a too-extremist standpoint. > The two extremes are: > 1. Numbers correspond to hardware numbers, and are easy to look up > in the hardware documentation (e.g. GIC SPI interrupt numbers). > => Use the hardcoded numbers in DTS. And such numbers (like GIC_SPI interrupt numbers) do not go to bindings. They go to DTS only. > 2. Numbers do not correspond to hardware numbers, so we had to > invent our own definitions and numbers, usually loosely > based on some table in the hardware documentation. > The driver will have to look up the numbers in a data > structure, to know how to program the hardware. > The numbers become part of the DT ABI, and cannot be changed > (header file is append-only). > => Use the binding definitions in DTS. Correct. However this patch is some mixture of both approaches. The same pointed by Arnd: https://lore.kernel.org/linux-devicetree/CAK8P3a0fDJQvGLEtG0fxLkG08Fh9V7LEMPsx4AaS+2Ldo_xWxw@mail.gmail.com/ > We are taking the middle ground: there is a one-to-one relation between > numbers and hardware numbers that can be looked up in or derived from > the hardware documentation, but the conversion is non-trivial (for the > casual human reviewer), or the documentation refers to names instead > of numbers in most sections (e.g. named power domains). Then why not > let the numbers match some feature in the hardware (e.g. register > offset or register bit)? Because you are embedding the device programming model into the bindings. It's the same as having properties: "vendor,value-for-register-xxx" We do not create bindings to describe programming model but hardware. Using the values from programming model is fragile and ties the bindings to that one programming model. Programming model can change, e.g. by mistake, but bindings should stay independent. > >> Imagine now you made mistake in this register >> offset and hardware uses slightly different value. What now? Change >> bindings? No. Bindings hold here ID, the abstraction, and ID stays fixed. > > I see no difference here with using the wrong interrupt number in an > interrupts property in DTS. What do we do in that case? Fix the DTS. Yes, fix the DTS. DTS are not the bindings. You can fix the DTS. You cannot fix the bindings because you affect both driver and DTS. > > BTW, are you aware of any driver that transforms interrupt numbers > obtained from DTS, because the DTS used the wrong number? Again, what do the DTS has here at all? The interrupt numbers are also not included in the bindings, so what does it prove? Best regards, Krzysztof 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 55D5DC433EF for ; Mon, 23 May 2022 15:24:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DT4YchFPmLwXsfNYEsJfTCt16IYuPLn/1ZM2H79QwpY=; b=RlP7lUuodYFqd3 aBctWvUkrW9lLu1eosqOLzAni7Kox/X7OalGkRakSwAXylkb/x477kE5cmfLLOqv5567HZt/Qh9XS fJEroI++9vgSjnWC6vxwF6dM5KWJFMNnYn5MsWbZ9+l3ecIyKRjEhugOLM4neFplV+b5HjhFp2Rtb 6sBhSCoyqKrDaFNV1VYSlOdaDAaFeENOqARgUQTpgkv6Rz2fX2pZkn3omr5bAceopO7osxNaRDyUk G+z+vkpNRNRHzwrIfIwJ1QR3xk/Phhkoi8kjx16lq85EjyG5kgWo/8mRixWgZzzSq/CB5Obny1Pbq jAdAvNl9SnJpPqY22hJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nt9tw-004ugO-Ta; Mon, 23 May 2022 15:23:21 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nt9tu-004uek-TR for linux-arm-kernel@bombadil.infradead.org; Mon, 23 May 2022 15:23:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=D5XQc8wBj+L7y1AKbIXLkcUnNCOQ5528vAYo2Vyy7WQ=; b=dFBX9ujh4yF+aiGuRM4xTYqDbO 7QELQHOQUUxUL2hVO6lJFjHZqB1L6HxZ5b1cuIYzepb50C6efiVBfmaTCBLTHY7245gK0EvG3LdUn ndpKmRDmbsMrBUSXGVoTPYv7EC6jzywz5snOlqxHeeLlAf02/h020sa7mtH5NNdN7St3ESp5lS+zv 6S7sY6TQ+UMbVtGgl+uj6+fjZWkuMP1lWwZo6Ib4LWRqpNpJ1XnZQfCirz6CypaDoKfQW3sa45lr+ ID5IXo1BPwaKopt9nqbtVmtbFRZLNdzXNcKcyyX5qfHU0hwRUvdeJN0Y/QjIzJMCAvtK8/lIslj38 UqekY5+g==; Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nt9tk-0015ix-9R for linux-arm-kernel@lists.infradead.org; Mon, 23 May 2022 15:23:12 +0000 Received: by mail-lj1-x235.google.com with SMTP id 1so4276933ljh.8 for ; Mon, 23 May 2022 08:23:02 -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=D5XQc8wBj+L7y1AKbIXLkcUnNCOQ5528vAYo2Vyy7WQ=; b=M7gmNtjCllRiORAgUIpKMPSb7oS9uKwtrDvNNzoyTSoMLPRhnQOtG/+dKE/mFFVndU OfXjCys6aayQms2XeXouvsn8NgCDzlz0jOVSflxi7+EqCuu+XZjYixHkZyqBHuLr7CDl dD4XtHTv7NOSdCzZTaYJCqNAZvGSGBAPr1ly0HApxqUZGYG8+iDidxUBZAb9UlWAqHV0 Coi2FFoPTpsFeNwdSX11azNbYK6bnKxbsLyffFRXG71CUcsDmlq618ZtEM6OHvDrntvy 7THTrF2vJ0lk90FcFauZANDwpRTJULBxAKwr6HbwVfOpds4TPAnexwSdK0fzsqFNybYo v+lg== 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=D5XQc8wBj+L7y1AKbIXLkcUnNCOQ5528vAYo2Vyy7WQ=; b=sB83tW3HPtTpcJZgkheYsX7jTPpQuU1eyLAsgK40YrznT+g8pbjw7WrB8siuZ3Szdm YEliNo/P4fS/kYKAhdC2+Zd0xK8nCXSXm5d+siRN+Z4RiTkqJgYql+JejqfVQiQAUI/v 3tr/olkPvFHwvY8tM3S1N79/Zz+PY+q3aGzuEvxjsO33OGDnhw0H6EfUBKBPYSTomE8w u0ykvH7ag97/Qtn2GfvMptaeiF42UM/M+lVmaZlExSkqzrEjOuxMHBCkKokLPIwiEu8x zZVBc1zIj+ZmKTgobYg2e3sgp39QzQBlnKrGId5NXYRgfOdoxQY8BD2A6SC7OZ6MqSnN pNfg== X-Gm-Message-State: AOAM531UWWS+h2eDhihDGk7ryV3K7obV2jI0qpGyApbV/0mFbPZR78TZ rllah5M2w6SzrMqFAaqh8P2Sig== X-Google-Smtp-Source: ABdhPJyVAM7kdjjShrP2QVKN0ERRYTn2eTJCgTp0tcXYWrz6bJpRhAVwFD/O3F0/8vaeprEbpanvdw== X-Received: by 2002:a2e:9655:0:b0:253:d575:9a6d with SMTP id z21-20020a2e9655000000b00253d5759a6dmr12647403ljh.207.1653319380816; Mon, 23 May 2022 08:23:00 -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 j16-20020a2e3c10000000b00253c33d30f0sm1889534lja.87.2022.05.23.08.22.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 May 2022 08:23:00 -0700 (PDT) Message-ID: Date: Mon, 23 May 2022 17:22:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v1 11/19] dt-bindings: reset: npcm: Add support for NPCM8XX Content-Language: en-US To: Geert Uytterhoeven Cc: Tomer Maimon , Avi Fishman , Tali Perry , Joel Stanley , Patrick Venture , Nancy Yuen , Benjamin Fair , Rob Herring , Krzysztof Kozlowski , Michael Turquette , Stephen Boyd , Philipp Zabel , Greg KH , Daniel Lezcano , Thomas Gleixner , Wim Van Sebroeck , Guenter Roeck , Catalin Marinas , Will Deacon , Arnd Bergmann , Olof Johansson , Jiri Slaby , Shawn Guo , =?UTF-8?Q?Bj=c3=b6rn_Andersson?= , Marcel Ziswiler , Vinod Koul , Biju Das , Nobuhiro Iwamatsu , Robert Hancock , =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= , Lubomir Rintel , arm-soc , devicetree , Linux Kernel Mailing List , linux-clk , "open list:SERIAL DRIVERS" , Linux Watchdog Mailing List , Linux ARM References: <20220522155046.260146-1-tmaimon77@gmail.com> <20220522155046.260146-12-tmaimon77@gmail.com> <86cd6a37-70ad-3a90-bc8a-dcd8b41f1175@linaro.org> <62562cdf-93e3-f642-5bbd-48329eff33ea@linaro.org> From: Krzysztof Kozlowski In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220523_162308_818193_FD8EBA2C X-CRM114-Status: GOOD ( 35.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 23/05/2022 17:11, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Mon, May 23, 2022 at 4:26 PM Krzysztof Kozlowski > wrote: >> On 23/05/2022 16:22, Geert Uytterhoeven wrote: >>> On Mon, May 23, 2022 at 4:03 PM Tomer Maimon wrote: >>>> On Mon, 23 May 2022 at 12:01, Krzysztof Kozlowski wrote: >>>>> On 22/05/2022 17:50, Tomer Maimon wrote: >>>>>> Add binding document and device tree binding >>>>>> constants for Nuvoton BMC NPCM8XX reset controller. >>>>>> >>>>>> Signed-off-by: Tomer Maimon >>> >>>>>> --- /dev/null >>>>>> +++ b/include/dt-bindings/reset/nuvoton,npcm8xx-reset.h >>>>>> @@ -0,0 +1,124 @@ >>>>>> +/* SPDX-License-Identifier: GPL-2.0 */ >>>>>> +// Copyright (c) 2022 Nuvoton Technology corporation. >>>>>> + >>>>>> +#ifndef _DT_BINDINGS_NPCM8XX_RESET_H >>>>>> +#define _DT_BINDINGS_NPCM8XX_RESET_H >>>>>> + >>>>>> +#define NPCM8XX_RESET_IPSRST1 0x20 >>>>>> +#define NPCM8XX_RESET_IPSRST2 0x24 >>>>>> +#define NPCM8XX_RESET_IPSRST3 0x34 >>>>>> +#define NPCM8XX_RESET_IPSRST4 0x74 >>>>> >>>>> What are these? All IDs should be incremental, decimal and start from 0. >>>> >>>> Register offset, we use the same method in NPCM7xx. please refer >>>> https://elixir.bootlin.com/linux/v5.18/source/include/dt-bindings/reset/nuvoton,npcm7xx-reset.h >>>> >>>> and the driver asserts the reset according to the reset include definitions >>> >>> So if they're easy to look up the values, you could do without the >>> definitions? Cfr. the interrupts properties in .dtsi files, where we >>> typically just use the hardcoded numbers. >>> >>> If you do decide to keep them, a comment explaining their origins >>> would be useful. >>> >>>>>> + >>>>>> +/* Reset lines on IP1 reset module (NPCM8XX_RESET_IPSRST1) */ >>>>>> +#define NPCM8XX_RESET_GDMA0 3 >>>>> >>>>> IDs start from 0 and do not have holes. >>>> >>>> This represents the reset BIT in the reset register. >>> >>> Likewise, I think it's a good idea to document that in a comment, cfr. >>> https://elixir.bootlin.com/linux/v5.18/source/include/dt-bindings/power/r8a7795-sysc.h#L8 >> >> Renesas is also doing it not correct (just like many others). The >> bindings are not for register bits or offsets. Such data can be DTS but >> not part of bindings. > > I think you are taking a too-extremist standpoint. > The two extremes are: > 1. Numbers correspond to hardware numbers, and are easy to look up > in the hardware documentation (e.g. GIC SPI interrupt numbers). > => Use the hardcoded numbers in DTS. And such numbers (like GIC_SPI interrupt numbers) do not go to bindings. They go to DTS only. > 2. Numbers do not correspond to hardware numbers, so we had to > invent our own definitions and numbers, usually loosely > based on some table in the hardware documentation. > The driver will have to look up the numbers in a data > structure, to know how to program the hardware. > The numbers become part of the DT ABI, and cannot be changed > (header file is append-only). > => Use the binding definitions in DTS. Correct. However this patch is some mixture of both approaches. The same pointed by Arnd: https://lore.kernel.org/linux-devicetree/CAK8P3a0fDJQvGLEtG0fxLkG08Fh9V7LEMPsx4AaS+2Ldo_xWxw@mail.gmail.com/ > We are taking the middle ground: there is a one-to-one relation between > numbers and hardware numbers that can be looked up in or derived from > the hardware documentation, but the conversion is non-trivial (for the > casual human reviewer), or the documentation refers to names instead > of numbers in most sections (e.g. named power domains). Then why not > let the numbers match some feature in the hardware (e.g. register > offset or register bit)? Because you are embedding the device programming model into the bindings. It's the same as having properties: "vendor,value-for-register-xxx" We do not create bindings to describe programming model but hardware. Using the values from programming model is fragile and ties the bindings to that one programming model. Programming model can change, e.g. by mistake, but bindings should stay independent. > >> Imagine now you made mistake in this register >> offset and hardware uses slightly different value. What now? Change >> bindings? No. Bindings hold here ID, the abstraction, and ID stays fixed. > > I see no difference here with using the wrong interrupt number in an > interrupts property in DTS. What do we do in that case? Fix the DTS. Yes, fix the DTS. DTS are not the bindings. You can fix the DTS. You cannot fix the bindings because you affect both driver and DTS. > > BTW, are you aware of any driver that transforms interrupt numbers > obtained from DTS, because the DTS used the wrong number? Again, what do the DTS has here at all? The interrupt numbers are also not included in the bindings, so what does it prove? Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel