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 EFBBDC61DA4 for ; Thu, 16 Feb 2023 09:31:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229991AbjBPJbB (ORCPT ); Thu, 16 Feb 2023 04:31:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229827AbjBPJa6 (ORCPT ); Thu, 16 Feb 2023 04:30:58 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE8969D; Thu, 16 Feb 2023 01:30:57 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4C6BD61EF4; Thu, 16 Feb 2023 09:30:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AED1EC4339E; Thu, 16 Feb 2023 09:30:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676539856; bh=OdLf0lflbfPh6eJsxKZzkNPd+cBrLw4Nsh++3rLbo3U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lrYYx/UanFz71hs7kc/V2NG6UVveJtdnW2kR8C9HvO3hi0eQQO8VMeO6bPeuoj6tf Q6+HcJaB0Lpkli/UkxYeA9H4uIb/9ptldb3+7xRigtmf81ly82b9rADOAEozGBpUGG I/kfsYE6CT77A3/+RbEImNPtsj9Z2rVEQhvKBnmmNJmhWdhDsu/V68gxIwu7zOVGvD ztY3R3ubKykpJBfzNsfN47px7RWyJ6e4Ef1AfqtqGPJL0LSbrM3JI+FywkfRCvLxkx VgScCCPikOgVT8YSgPkdEetlGFkMbnBXG5oZfobwS3g0XpJ/vdstEAgal80WqQRfzY YqVXxwLWzSd3w== Received: by mail-ej1-f51.google.com with SMTP id he33so3586122ejc.11; Thu, 16 Feb 2023 01:30:56 -0800 (PST) X-Gm-Message-State: AO0yUKWeFUALvuhEnQci/npGa37BF/8TvPz89lILmsH9Epzw9F6mD6X+ f8ETk8EzTFOuOZF5Z8xoPIcCoJ6uE214t1scyNI= X-Google-Smtp-Source: AK7set98w9l2vIAxaf28W6wZ9k6ybYWesA0iLcj/ZtNswakBr1+s5dpgWQLdGVrV0xaSQr0Etr3j6M7lrYYXqzIrFmk= X-Received: by 2002:a17:906:245b:b0:8b0:e909:9136 with SMTP id a27-20020a170906245b00b008b0e9099136mr2621638ejb.1.1676539854884; Thu, 16 Feb 2023 01:30:54 -0800 (PST) MIME-Version: 1.0 References: <23068d0c-d37c-0563-e1c1-e4d112059f5b@linaro.org> <49c8255e-66f3-fa1f-2949-1f03f77a0fa4@linaro.org> In-Reply-To: <49c8255e-66f3-fa1f-2949-1f03f77a0fa4@linaro.org> From: Huacai Chen Date: Thu, 16 Feb 2023 17:30:45 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V2 1/2] dt-bindings: interrupt-controller: Add Loongson EIOINTC To: Krzysztof Kozlowski Cc: Binbin Zhou , Binbin Zhou , Jiaxun Yang , Thomas Gleixner , Marc Zyngier , Rob Herring , Krzysztof Kozlowski , Jianmin Lv , Huacai Chen , linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, loongarch@lists.linux.dev, devicetree@vger.kernel.org, loongson-kernel@lists.loongnix.cn Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Krzysztof, On Thu, Feb 16, 2023 at 4:10 PM Krzysztof Kozlowski wrote: > > On 16/02/2023 02:46, Binbin Zhou wrote: > > On Tue, Feb 14, 2023 at 8:43 PM Krzysztof Kozlowski > > wrote: > >> > >> On 14/02/2023 13:40, Binbin Zhou wrote: > >>> On Tue, Feb 14, 2023 at 5:53 PM Krzysztof Kozlowski > >>> 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 > >>>>> --- > >>>>> .../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 > >>>>> + > >>>>> +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. :( > >> > >> > > Hi Krzysztof: > > > > Allow me to give a brief overview of the current status of eiointc (DT-based): > > Loongson-3A series supports eiointc; > > Loongson-2K1000 does not support eiointc now; > > Loongson-2K0500 supports eiointc, with differences from > > Loongson-3, e.g. only up to 128 devices are supported; > > Loongson-2K2000 supports eiointc, similar to Loongson-3. > > .... > > > > As can be seen, there is now a bit of confusion in the chip's design of eiointc. > > > > The design of eiointc is probably refined step by step with the chip. > > The same version of eiointc can be used for multiple chips, and the > > same chip series may also use different versions of eiointc. Low-end > > chips may use eiointc-2.0, and high-end chips may use eiointc-1.0, > > depending on the time it's produced. > > > > So in the Loongson-2K series I have defined the current state as > > eiointc-1.0, using the dts property to indicate the maximum number of > > devices supported by eiointc that can be used directly in the driver. > > > > If there are new changes to the design later on, such as the > > definition of registers, we can call it eiointc-2.0, which can also > > cover more than one chip. > > Just go with SoC-based compatibles. If your version is not specific > enough, then it is not a good way to represent the hardware. EIOINTC is a bit like the existing LIOINTC which is already use version to represent hardware. Huacai > > Best regards, > Krzysztof >