On 14/02/2023 13:40, Binbin Zhou wrote: > On Tue, Feb 14, 2023 at 5:53 PM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 13/02/2023 13:15, Binbin Zhou wrote: >>> Add Loongson Extended I/O Interrupt controller binding with DT schema >>> format using json-schema. >>> >>> Signed-off-by: Binbin Zhou <zhoubinbin@xxxxxxxxxxx> >>> --- >>> .../loongson,eiointc.yaml | 80 +++++++++++++++++++ >>> 1 file changed, 80 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml >>> new file mode 100644 >>> index 000000000000..88580297f955 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,eiointc.yaml >>> @@ -0,0 +1,80 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: "http://devicetree.org/schemas/interrupt-controller/loongson,eiointc.yaml#"; >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; >> >> Drop quotes from bopth. >> >>> + >>> +title: Loongson Extended I/O Interrupt Controller >>> + >>> +maintainers: >>> + - Binbin Zhou <zhoubinbin@xxxxxxxxxxx> >>> + >>> +description: | >>> + This interrupt controller is found on the Loongson-3 family chips and >>> + Loongson-2K0500 chip and is used to distribute interrupts directly to >>> + individual cores without forwarding them through the HT's interrupt line. >>> + >>> +allOf: >>> + - $ref: /schemas/interrupt-controller.yaml# >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - loongson,eiointc-1.0 >> >> Why not using SoC based compatible? It is preferred. > > Hi Krzysztof: > > So far, from the datasheet, I know that only the EXIOINTC of the > Loongson-2K0500 is different from the other chips, and that is the > "loongson,eio-num-vecs" below, which is 128, while all the others are > 256. > My original idea was to add this property to make compatible > consistent, and also to make it easier to add new chips if they have > different eio-num-vecs. We talk about different things. SoC based compatibles are preferred over version ones. This was on the lists expressed many times. Please provide a reason why you deviate from general recommendation. Flexibility and genericness of bindings is not a reason - it's the opposite of the argument, thus this will be a: NAK. :( > >> >>> + >>> + reg: >>> + minItems: 1 >>> + maxItems: 3 >> >> You need to describe the items. >> >>> + >>> + interrupt-controller: true >>> + >>> + interrupts: >>> + description: >>> + Interrupt source of the CPU interrupts. >> >> You need to describe the items. > > Do you mean a more detailed description? I mean constraints on interrupts and/or description if they are not obvious. Best regards, Krzysztof
