Message ID | 20221025035128.21068-2-zhuyinbo@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp793435wru; Mon, 24 Oct 2022 21:06:02 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5EHHmI3IDVqhmOaR5q216Kkoxi+CU7fjkiLkuzhuMXId57I31ZPuQAC0uuFZDE1fvCR3PG X-Received: by 2002:a62:4e89:0:b0:56c:12c0:aaf7 with SMTP id c131-20020a624e89000000b0056c12c0aaf7mr2939501pfb.0.1666670761947; Mon, 24 Oct 2022 21:06:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666670761; cv=none; d=google.com; s=arc-20160816; b=pHuf08ynjymHEp2PybSyVe1nE5nXulePBcVfnaHaA1VvC27fh2qS2GAZgF7iPs2rJG /zwqolEvGglNURaViRqUCKUHdRf7CGUVV6GasgHzPSsICrVUw1zOmvKUSIBhL765Jj1U nCAgwFPgq2psBtujTQtIs7AwS+w9NXO0ZY5UDeYAtb2RpnzeUaZ7nVjfp5Dx6508prpR 5DGnpyxstU3E1I0UzCZDQ8Fmwd/U+/npUU53kbAXwHQ3L9xgZMv4rqkhnraprhCINPsN bfNMN9v7Bp/guWIlnhsHGN54+JKd9PMqPrrFkzcdGPz6HdkUv8lmwFnAC5Pg17qWMV0K ZH9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from; bh=lHv9O4mSrYrk44urCzqILd1IXIDNp+PYgGvLcf/g2rg=; b=KZbCrjbIklrP9E38o7PCHV0yf61FytfwCbkR4qz7us0+M5IQoln/pfESyy2uaGwEh2 M3hnuIbWQuZYjdqlu6lZ73BMF4qqabepfCztMW+ZVRYVtoyC6VIiRJnnDNczQoZBkZrA SCvbOPx9CbARYkYXWCU5ZMC2uhOZVggjhJxj9Ohxk0yxCKddWRAsMnaB7kmfoRieQv9a bGrWzFo3auuza1mscPFJKl3bxVvXygri//6bJxndO2rSqYcfptDm2HLCOpcRHNpBWCkR mtPOVg/NQono+W5B1kkXc/H+bTxSNs/jDBp8z99+q3jjIk3cbYd1XNSohoT2McWkJch+ QVtg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jj12-20020a170903048c00b00176e85e5ceasi1463011plb.405.2022.10.24.21.05.41; Mon, 24 Oct 2022 21:06:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229776AbiJYDvt (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Mon, 24 Oct 2022 23:51:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229574AbiJYDvm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Oct 2022 23:51:42 -0400 Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3870F7C76A; Mon, 24 Oct 2022 20:51:38 -0700 (PDT) Received: from loongson.cn (unknown [10.180.13.64]) by gateway (Coremail) with SMTP id _____8BxnrdJXVdjak8CAA--.4174S3; Tue, 25 Oct 2022 11:51:37 +0800 (CST) Received: from localhost.localdomain (unknown [10.180.13.64]) by localhost.localdomain (Coremail) with SMTP id AQAAf8AxDuJBXVdj2rMEAA--.18366S3; Tue, 25 Oct 2022 11:51:35 +0800 (CST) From: Yinbo Zhu <zhuyinbo@loongson.cn> To: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Arnd Bergmann <arnd@arndb.de>, Hector Martin <marcan@marcan.st>, Lubomir Rintel <lkundrak@v3.sk>, Conor Dooley <conor.dooley@microchip.com>, Linus Walleij <linus.walleij@linaro.org>, Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>, Heiko Stuebner <heiko@sntech.de>, Brian Norris <briannorris@chromium.org>, Sven Peter <sven@svenpeter.dev>, loongarch@lists.linux.dev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Yinbo Zhu <zhuyinbo@loongson.cn> Subject: [PATCH v2 2/2] dt-bindings: soc: add loongson2 guts Date: Tue, 25 Oct 2022 11:51:28 +0800 Message-Id: <20221025035128.21068-2-zhuyinbo@loongson.cn> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20221025035128.21068-1-zhuyinbo@loongson.cn> References: <20221025035128.21068-1-zhuyinbo@loongson.cn> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8AxDuJBXVdj2rMEAA--.18366S3 X-CM-SenderInfo: 52kx5xhqerqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoW7uF15Xw4UCw17Xw1fKr4UArb_yoW8ZrW7pr nxC34rGrW0vF17uws3GFyIk3W5Cr97CasFgFZrtw1UKF9rA3W3Zw13KF1DZa13Ary8GFW2 9F97WrWUKF48CaUanT9S1TB71UUUUbJqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bfkFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUAVWUZwA2ocxC64 kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28E F7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAaw2AFwI0_Jw0_GFyle2I262IYc4CY 6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2IEw4CE5I8CrV C2j2WlYx0E2Ix0cI8IcVAFwI0_Jw0_WrylYx0Ex4A2jsIE14v26r4j6F4UMcvjeVCFs4IE 7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x 0EwIxGrwCF04k20xvE74AGY7Cv6cx26rWl4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xF xVAFwI0_Jw0_GFylx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWw C2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Xr0_ Ar1lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJV WUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIY CTnIWIevJa73UjIFyTuYvjxUIbyCDUUUU X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747630960443564325?= X-GMAIL-MSGID: =?utf-8?q?1747630960443564325?= |
Series |
[v2,1/2] soc: loongson: add GUTS driver for loongson2 platforms
|
|
Commit Message
Yinbo Zhu
Oct. 25, 2022, 3:51 a.m. UTC
Add the loongson2 soc guts driver binding with DT schema format
using json-schema.
Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
---
.../soc/loongson/loongson,ls2k-guts.yaml | 37 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml
Comments
On 24/10/2022 23:51, Yinbo Zhu wrote: > Add the loongson2 soc guts driver binding with DT schema format > using json-schema. > > Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn> > --- > .../soc/loongson/loongson,ls2k-guts.yaml | 37 +++++++++++++++++++ Looks like wrong location, although difficult to judge because you did not describe the hardware at all. If this is chipinfo-like device, then Documentation/devicetree/bindings/hwinfo/. > MAINTAINERS | 1 + > 2 files changed, 38 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml > > diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml > new file mode 100644 > index 000000000000..2502f8aeb74d > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml > @@ -0,0 +1,37 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-guts.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Loongson2 GUTS driver. Drop "driver." unless you refer to some hardware (like motor driver?). > + > +maintainers: > + - Yinbo Zhu <zhuyinbo@loongson.cn> > + > +description: | > + GUTS driver was to manage and access global utilities block. Initially Drop "driver" and describe instead what is GUTS, including its acronym, > + only reading SVR and registering soc device are supported. Entire sentence describe Linux driver - drop it. Instead describe the device, the hardware. > + > +properties: > + compatible: > + const: loongson,ls2k-guts > + > + reg: > + maxItems: 1 > + > + little-endian: true > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + guts: guts@1fe00000 { Node names should be generic. https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation Best regards, Krzysztof
在 2022/10/26 上午3:40, Krzysztof Kozlowski 写道: > On 24/10/2022 23:51, Yinbo Zhu wrote: >> Add the loongson2 soc guts driver binding with DT schema format >> using json-schema. >> >> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn> >> --- >> .../soc/loongson/loongson,ls2k-guts.yaml | 37 +++++++++++++++++++ > > Looks like wrong location, although difficult to judge because you did > not describe the hardware at all. If this is chipinfo-like device, then > Documentation/devicetree/bindings/hwinfo/. My guts driver is refer fsl platform. It was was to manage and access global utilities register block for SoC and it was only used in SoC platform. when driver need use Soc ops to do some function the this driver was needed. the dcfg (device config) was a function in guts (global utilities) block. For these type of driver, other platforms were initially placed on Documentation/devicetree/bindings/arm/ if it is arm/arm64 architecture. Later, move it to the soc directory. Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml So, do you still think it is inappropriate to place it in the soc dir? > > >> MAINTAINERS | 1 + >> 2 files changed, 38 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >> >> diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >> new file mode 100644 >> index 000000000000..2502f8aeb74d >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >> @@ -0,0 +1,37 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-guts.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Loongson2 GUTS driver. > > Drop "driver." unless you refer to some hardware (like motor driver?). this need refer hardware soc datasheet to gain soc register (global utilities register block ). so keep "driver" string that whether was more appropriate? > >> + >> +maintainers: >> + - Yinbo Zhu <zhuyinbo@loongson.cn> >> + >> +description: | >> + GUTS driver was to manage and access global utilities block. Initially > > Drop "driver" and describe instead what is GUTS, including its acronym, > >> + only reading SVR and registering soc device are supported. > > Entire sentence describe Linux driver - drop it. Instead describe the > device, the hardware. > >> + >> +properties: >> + compatible: >> + const: loongson,ls2k-guts >> + >> + reg: >> + maxItems: 1 >> + >> + little-endian: true >> + >> +required: >> + - compatible >> + - reg >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + guts: guts@1fe00000 { > > Node names should be generic. dcfg/scfg (device cfg/ soc cfg)was the key function of guts (global utilities) block. and guts name I was refer fsl soc driver. "drivers/soc/fsl/guts.c" this binding file was follows of fsl guts. Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml or, I was use scfg as node name, Do you think it's appropriate? > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation > > > Best regards, > Krzysztof >
On 26/10/2022 03:22, Yinbo Zhu wrote: > > > 在 2022/10/26 上午3:40, Krzysztof Kozlowski 写道: >> On 24/10/2022 23:51, Yinbo Zhu wrote: >>> Add the loongson2 soc guts driver binding with DT schema format >>> using json-schema. >>> >>> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn> >>> --- >>> .../soc/loongson/loongson,ls2k-guts.yaml | 37 +++++++++++++++++++ >> >> Looks like wrong location, although difficult to judge because you did >> not describe the hardware at all. If this is chipinfo-like device, then >> Documentation/devicetree/bindings/hwinfo/. > My guts driver is refer fsl platform. It was was to manage and access > global utilities register block for SoC and it was only used in SoC > platform. when driver need use Soc ops to do some function the this > driver was needed. the dcfg (device config) was a function in guts > (global utilities) block. I can barely understand it. > For these type of driver, other platforms were initially placed on > Documentation/devicetree/bindings/arm/ if it is arm/arm64 > architecture. Later, move it to the soc directory. > > Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml How is this related? This is Layerscape, not Loongson2. Describe the hardware you are adding bindings for. > > So, do you still think it is inappropriate to place it in the soc dir? >> >> >>> MAINTAINERS | 1 + >>> 2 files changed, 38 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>> new file mode 100644 >>> index 000000000000..2502f8aeb74d >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>> @@ -0,0 +1,37 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-guts.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Loongson2 GUTS driver. >> >> Drop "driver." unless you refer to some hardware (like motor driver?). > this need refer hardware soc datasheet to gain soc register (global > utilities register block ). > so keep "driver" string that whether was more appropriate? What? I cannot parse it. Did you understand my comment? If yes, please point to Wikipedia article explaining this "Driver" you refer to. >> >>> + >>> +maintainers: >>> + - Yinbo Zhu <zhuyinbo@loongson.cn> >>> + >>> +description: | >>> + GUTS driver was to manage and access global utilities block. Initially >> >> Drop "driver" and describe instead what is GUTS, including its acronym, >> >>> + only reading SVR and registering soc device are supported. >> >> Entire sentence describe Linux driver - drop it. Instead describe the >> device, the hardware. >> >>> + >>> +properties: >>> + compatible: >>> + const: loongson,ls2k-guts >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + little-endian: true >>> + >>> +required: >>> + - compatible >>> + - reg >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + guts: guts@1fe00000 { >> >> Node names should be generic. > dcfg/scfg (device cfg/ soc cfg)was the key function of guts (global > utilities) block. and guts name I was refer fsl soc driver. > "drivers/soc/fsl/guts.c" > this binding file was follows of fsl guts. > Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml > Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml > > or, I was use scfg as node name, Do you think it's appropriate? No, these are not generic node names. > > >> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation Best regards, Krzysztof
在 2022/10/26 下午10:10, Krzysztof Kozlowski 写道: > On 26/10/2022 03:22, Yinbo Zhu wrote: >> >> >> 在 2022/10/26 上午3:40, Krzysztof Kozlowski 写道: >>> On 24/10/2022 23:51, Yinbo Zhu wrote: >>>> Add the loongson2 soc guts driver binding with DT schema format >>>> using json-schema. >>>> >>>> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn> >>>> --- >>>> .../soc/loongson/loongson,ls2k-guts.yaml | 37 +++++++++++++++++++ >>> >>> Looks like wrong location, although difficult to judge because you did >>> not describe the hardware at all. If this is chipinfo-like device, then >>> Documentation/devicetree/bindings/hwinfo/. yes it is a chipinfo/socinfo device, I will following your advice. >> My guts driver is refer fsl platform. It was was to manage and access >> global utilities register block for SoC and it was only used in SoC >> platform. when driver need use Soc ops to do some function the this >> driver was needed. the dcfg (device config) was a function in guts >> (global utilities) block. > > I can barely understand it. My description is about chipinfo/socinfo definition. and I have a look /bindings/hwinfo/, I think move binding file to hwinfo that is okay for me. Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml > >> For these type of driver, other platforms were initially placed on >> Documentation/devicetree/bindings/arm/ if it is arm/arm64 >> architecture. Later, move it to the soc directory. >> >> Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml > > How is this related? This is Layerscape, not Loongson2. Describe the > hardware you are adding bindings for. The driver functions/type are the same, the driver was register a struct soc_device_attribute by soc_device_register then other peripheral driver can call SoC ops, such as soc_device_match. then layerscape guts module bindings are placed in Documentation/devicetree/bindings/soc/, the loongson guts module bindings was follow that layerscape and are placed in Documentation/devicetree/bindings/soc/ In a words, It is a question about where the binding file should be placed. I think move binding file to hwinfo that is okay for me. > >> >> So, do you still think it is inappropriate to place it in the soc dir? >>> >>> >>>> MAINTAINERS | 1 + >>>> 2 files changed, 38 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>>> new file mode 100644 >>>> index 000000000000..2502f8aeb74d >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>>> @@ -0,0 +1,37 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-guts.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Loongson2 GUTS driver. >>> >>> Drop "driver." unless you refer to some hardware (like motor driver?). >> this need refer hardware soc datasheet to gain soc register (global >> utilities register block ). >> so keep "driver" string that whether was more appropriate? > > What? I cannot parse it. > > Did you understand my comment? If yes, please point to Wikipedia article > explaining this "Driver" you refer to. I will remove the "driver" string. > > >>> >>>> + >>>> +maintainers: >>>> + - Yinbo Zhu <zhuyinbo@loongson.cn> >>>> + >>>> +description: | >>>> + GUTS driver was to manage and access global utilities block. Initially >>> >>> Drop "driver" and describe instead what is GUTS, including its acronym, >>> >>>> + only reading SVR and registering soc device are supported. >>> >>> Entire sentence describe Linux driver - drop it. Instead describe the >>> device, the hardware. >>> >>>> + >>>> +properties: >>>> + compatible: >>>> + const: loongson,ls2k-guts >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + little-endian: true >>>> + >>>> +required: >>>> + - compatible >>>> + - reg >>>> + >>>> +additionalProperties: false >>>> + >>>> +examples: >>>> + - | >>>> + guts: guts@1fe00000 { >>> >>> Node names should be generic. >> dcfg/scfg (device cfg/ soc cfg)was the key function of guts (global >> utilities) block. and guts name I was refer fsl soc driver. >> "drivers/soc/fsl/guts.c" >> this binding file was follows of fsl guts. >> Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml >> Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml >> >> or, I was use scfg as node name, Do you think it's appropriate? > > No, these are not generic node names. I was refer "ti,k3-socinfo.yaml", Do you think it's appropriate that socinfo as node name? > >> >> >>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation > > Best regards, > Krzysztof >
On 26/10/2022 23:52, Yinbo Zhu wrote: > > > 在 2022/10/26 下午10:10, Krzysztof Kozlowski 写道: >> On 26/10/2022 03:22, Yinbo Zhu wrote: >>> >>> >>> 在 2022/10/26 上午3:40, Krzysztof Kozlowski 写道: >>>> On 24/10/2022 23:51, Yinbo Zhu wrote: >>>>> Add the loongson2 soc guts driver binding with DT schema format >>>>> using json-schema. >>>>> >>>>> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn> >>>>> --- >>>>> .../soc/loongson/loongson,ls2k-guts.yaml | 37 +++++++++++++++++++ >>>> >>>> Looks like wrong location, although difficult to judge because you did >>>> not describe the hardware at all. If this is chipinfo-like device, then >>>> Documentation/devicetree/bindings/hwinfo/. > yes it is a chipinfo/socinfo device, I will following your advice. >>> My guts driver is refer fsl platform. It was was to manage and access >>> global utilities register block for SoC and it was only used in SoC >>> platform. when driver need use Soc ops to do some function the this >>> driver was needed. the dcfg (device config) was a function in guts >>> (global utilities) block. >> >> I can barely understand it. > My description is about chipinfo/socinfo definition. and I have a look > /bindings/hwinfo/, I think move binding file to hwinfo that is okay for me. > > Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml > >> >>> For these type of driver, other platforms were initially placed on >>> Documentation/devicetree/bindings/arm/ if it is arm/arm64 >>> architecture. Later, move it to the soc directory. >>> >>> Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml >> >> How is this related? This is Layerscape, not Loongson2. Describe the >> hardware you are adding bindings for. > The driver functions/type are the same, the driver was register a struct > soc_device_attribute by soc_device_register then other peripheral driver > can call SoC ops, such as soc_device_match. > > then layerscape guts module bindings are placed in > Documentation/devicetree/bindings/soc/, the loongson guts module > bindings was follow that layerscape and are placed in > Documentation/devicetree/bindings/soc/ > > In a words, It is a question about where the binding file should be > placed. I think move binding file to hwinfo that is okay for me. My review is limited to the scope I understand from what you wrote. You described so far something being only a soc info registers. For this the place is hwinfo. The Layerscape dcfg is more than that - it is a syscon, system register controller with at least one child device. If your device is exactly like that, describe it in bindings fully, not partially. These are then incomplete bindings. >> >>> >>> So, do you still think it is inappropriate to place it in the soc dir? >>>> >>>> >>>>> MAINTAINERS | 1 + >>>>> 2 files changed, 38 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>>>> new file mode 100644 >>>>> index 000000000000..2502f8aeb74d >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml >>>>> @@ -0,0 +1,37 @@ >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>>> +%YAML 1.2 >>>>> +--- >>>>> +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-guts.yaml# >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>>> + >>>>> +title: Loongson2 GUTS driver. >>>> >>>> Drop "driver." unless you refer to some hardware (like motor driver?). >>> this need refer hardware soc datasheet to gain soc register (global >>> utilities register block ). >>> so keep "driver" string that whether was more appropriate? >> >> What? I cannot parse it. >> >> Did you understand my comment? If yes, please point to Wikipedia article >> explaining this "Driver" you refer to. > I will remove the "driver" string. >> >> >>>> >>>>> + >>>>> +maintainers: >>>>> + - Yinbo Zhu <zhuyinbo@loongson.cn> >>>>> + >>>>> +description: | >>>>> + GUTS driver was to manage and access global utilities block. Initially >>>> >>>> Drop "driver" and describe instead what is GUTS, including its acronym, >>>> >>>>> + only reading SVR and registering soc device are supported. >>>> >>>> Entire sentence describe Linux driver - drop it. Instead describe the >>>> device, the hardware. >>>> >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: loongson,ls2k-guts >>>>> + >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + little-endian: true >>>>> + >>>>> +required: >>>>> + - compatible >>>>> + - reg >>>>> + >>>>> +additionalProperties: false >>>>> + >>>>> +examples: >>>>> + - | >>>>> + guts: guts@1fe00000 { >>>> >>>> Node names should be generic. >>> dcfg/scfg (device cfg/ soc cfg)was the key function of guts (global >>> utilities) block. and guts name I was refer fsl soc driver. >>> "drivers/soc/fsl/guts.c" >>> this binding file was follows of fsl guts. >>> Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml >>> Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml >>> >>> or, I was use scfg as node name, Do you think it's appropriate? >> >> No, these are not generic node names. > I was refer "ti,k3-socinfo.yaml", Do you think it's appropriate that > socinfo as node name? The blocks are called usually chipid and you can find examples for that. There are no examples using socinfo name. If the main purpose of this register block (and/or device) is to provide socinfo, then call it chipid. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml new file mode 100644 index 000000000000..2502f8aeb74d --- /dev/null +++ b/Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/loongson/loongson,ls2k-guts.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson2 GUTS driver. + +maintainers: + - Yinbo Zhu <zhuyinbo@loongson.cn> + +description: | + GUTS driver was to manage and access global utilities block. Initially + only reading SVR and registering soc device are supported. + +properties: + compatible: + const: loongson,ls2k-guts + + reg: + maxItems: 1 + + little-endian: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + guts: guts@1fe00000 { + compatible = "loongson,ls2k-guts"; + reg = <0x1fe00000 0x3ffc>; + little-endian; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 0f06dc83f7c6..b23474a5d8c1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11934,6 +11934,7 @@ LOONGSON2 SOC SERIES GUTS DRIVER M: Yinbo Zhu <zhuyinbo@loongson.cn> L: loongarch@lists.linux.dev S: Maintained +F: Documentation/devicetree/bindings/soc/loongson/loongson,ls2k-guts.yaml F: drivers/soc/loongson/loongson2_guts.c LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)