[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <348c3416-be44-b912-98ef-7f394bd408c0@linaro.org>
Date: Fri, 27 Jan 2023 09:32:52 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Jules Maselbas <jmaselbas@...ray.eu>
Cc: Yann Sionneau <ysionneau@...ray.eu>, Arnd Bergmann <arnd@...db.de>,
Jonathan Corbet <corbet@....net>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Mark Rutland <mark.rutland@....com>,
Eric Biederman <ebiederm@...ssion.com>,
Kees Cook <keescook@...omium.org>,
Oleg Nesterov <oleg@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Waiman Long <longman@...hat.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <npiggin@...il.com>,
Paul Moore <paul@...l-moore.com>,
Eric Paris <eparis@...hat.com>,
Christian Brauner <brauner@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Guillaume Thouvenin <gthouvenin@...ray.eu>,
Clement Leger <clement@...ment-leger.fr>,
Vincent Chardon <vincent.chardon@...ys-design.com>,
Marc Poulhiès <dkm@...aplop.net>,
Julian Vetter <jvetter@...ray.eu>,
Samuel Jones <sjones@...ray.eu>,
Ashley Lesdalons <alesdalons@...ray.eu>,
Thomas Costis <tcostis@...ray.eu>,
Marius Gligor <mgligor@...ray.eu>,
Jonathan Borne <jborne@...ray.eu>,
Julien Villette <jvillette@...ray.eu>,
Luc Michel <lmichel@...ray.eu>,
Louis Morhet <lmorhet@...ray.eu>,
Julien Hascoet <jhascoet@...ray.eu>,
Jean-Christophe Pince <jcpince@...il.com>,
Guillaume Missonnier <gmissonnier@...ray.eu>,
Alex Michon <amichon@...ray.eu>,
Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <git@...0n.name>,
Shaokun Zhang <zhangshaokun@...ilicon.com>,
John Garry <john.garry@...wei.com>,
Guangbin Huang <huangguangbin2@...wei.com>,
Bharat Bhushan <bbhushan2@...vell.com>,
Bibo Mao <maobibo@...ngson.cn>,
Atish Patra <atishp@...shpatra.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Qi Liu <liuqi115@...wei.com>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Catalin Marinas <catalin.marinas@....com>,
Mark Brown <broonie@...nel.org>,
Janosch Frank <frankja@...ux.ibm.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Benjamin Mugnier <mugnier.benjamin@...il.com>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, linux-audit@...hat.com,
linux-riscv@...ts.infradead.org, bpf@...r.kernel.org
Subject: Re: [RFC PATCH v2 02/31] Documentation: Add binding for
kalray,kv3-1-core-intc
On 26/01/2023 17:10, Jules Maselbas wrote:
>>> + reg:
>>> + maxItems: 0
>>
>> ??? No way... What's this?
> This (per CPU) interrupt controller is not memory mapped at all, it is
> controlled and configured through system registers.
>
> I do not have found existing .yaml bindings for such devices, only the
> file snps,archs-intc.txt has something similar.
>
> I do not know what is the best way to represent such devices in the
> device-tree. Any suggestions are welcome.
You cannot have an array property with 0 items. How would it look like
in DTS? There are many, many bindings which are expressing it. Just drop
the reg.
>
>>
>>> + "kalray,intc-nr-irqs":
>>
>> Drop quotes.
>>
>>> + description: Number of irqs handled by the controller.
>>
>> Why this is variable per board? Why do you need it ?
> This property is not even used in our device-tree, this will be removed
> from the documentation and from the driver as well.
>
>>> +
>>> +required:
>>> + - compatible
>>> + - "#interrupt-cells"
>>> + - interrupt-controller
>>
>> missing additionalProperties: false
>>
>> This binding looks poor, like you started from something odd. Please
>> don't. Take the newest reviewed binding or better example-schema and use
>> it to build yours. This would solve several trivial mistakes and style
>> issues.
> I am starting over from the example-schema.
>
>>> +
>>> +examples:
>>> + - |
>>> + intc: interrupt-controller {
>>
>> What's the IO address space?
> As said above, this is not a memory mapped device, but is accessed
> through system registers.
Sure, but then you cannot define a reg which was confusing...
Best regards,
Krzysztof
Powered by blists - more mailing lists