[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b9b3ccaf-7ad1-485a-9ee8-9a9922936e79@linaro.org>
Date: Thu, 25 Apr 2024 08:56:52 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Nikolaos Pasaloukos <nikolaos.pasaloukos@...ize.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: James Cowgill <james.cowgill@...ize.com>,
Matt Redfearn <matthew.redfearn@...ize.com>,
Neil Jones <neil.jones@...ize.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 4/7] dt-bindings: clock: Add binding constants for
BLZP1600
On 24/04/2024 18:14, Nikolaos Pasaloukos wrote:
>> No, they cannot be invalid. IDs start from 0 and are incremented by one.
>> If you have holes, it is not a binding.
>>
>> Drop the header or use it properly, so as virtual IDs.
>>
>> Best regards,
>> Krzysztof
>>
> My intention was to avoid using magic numbers on the DeviceTree. That's why I added them here.
> Also, we have some custom drivers which we plan to upload and their schemas need those files.
> The alternative would be to use magic numbers for our clocks and resets.
>
> In the commit message and on the header file I have mentioned that these are numbers matching
> the hardware specification (1 to 1) of the chip not just enums.
> Some IDs are invalid because of a hardware gap, some others are invalid because the SCMI
> service will return an error that the number is invalid.
>
> Is there another way to prevent the magic numbers in the schemas and device-tree.
>
> Thank you very much for your fast and detailed review.
Bindings describe the interface between DTS and drivers (OS or some sort
of other software). The purpose of binding headers is to document the
constants which are used by both, because they are part of that
interface. Therefore constants are pure abstraction.
Let me rephrase the question: Why you do not have headers for interrupt
numbers? All addresses? GPIO pin numbers?
Best regards,
Krzysztof
Powered by blists - more mailing lists