Message ID | 20230606193507.35024-1-AVKrasnov@sberdevices.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp3629334vqr; Tue, 6 Jun 2023 12:43:57 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6CDeNN9engW45dOLCoWueP+BTr8MapTut3I01xUej3tS56/Y8GmkWbvYx9NhnQ+MICGFFE X-Received: by 2002:a17:903:41c6:b0:1b1:ac87:b47a with SMTP id u6-20020a17090341c600b001b1ac87b47amr3754031ple.65.1686080637048; Tue, 06 Jun 2023 12:43:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686080637; cv=none; d=google.com; s=arc-20160816; b=GJ74Xk37pwJBY/nllE3Wd/uAIeTnTbrcxwA82jXRpjWilqFrxUGMib1ozFg767tYj6 8r98amwXi964NLapjeksLyB32YPCKtHfpXbEEaF2KX7ZRwRpJkxVejJrjY7xfQVGIiLc gbmtuBk8eNjeWotnjswEQLcX5eVn8kITUW85VQgkY/ntK1FDoFGld8Q+yNtg+0Y1wavt fAgs7Otns9Lm+tLd9EjWVNExTp1I62d1lqjCYknLJe/ZKCsAV96CBnLGxhGOYqFwzFRT tCwvjg3W0uNrXI5P6+i6I5lXns2dLMOX1qV6fEkmfaw/wxm4c7s8RgRsnMydARLeBYGF f00Q== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=/a/D+K5/RvpmyF70t6iC3BBkjuaMSTKw05HEPcEHC4s=; b=AwqK6PPffZjOw6Ch6f3NDsK+Q3UiLst1fRmeZT7KkblHLL3D+HjWbsmxTe2i7GTBIs ohf3jUldlglW7waOsLyCGa/PsUQrEM+UPwfD79kOUCUQo50NFQwJwf8gid2H9ifLEXYY g/59l/WvqH9ZXbZ+9yqfV6Y/hXKyEp3dFjzvR9HDNjBqIs4/n/yxOi7K2GZeM1p6Kp8S /D9XNTJ1sKWkuN6ROdf6B2HJhaYIBHoqzUHj7zIGAebwMfJBytSCZLw3iBNJKajDbg4Z p2nMBT/2CxFq73ltrLhLeOo26k5jAfE0aoU3Aw5+89tt3mC7XTCBsXJORZdc4AB020Wt Nzbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=U6ocXN1G; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l12-20020a170902d34c00b001adeb1635e1si7486024plk.155.2023.06.06.12.43.44; Tue, 06 Jun 2023 12:43:57 -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; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=U6ocXN1G; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238806AbjFFTky (ORCPT <rfc822;xxoosimple@gmail.com> + 99 others); Tue, 6 Jun 2023 15:40:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239166AbjFFTk2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 6 Jun 2023 15:40:28 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C89611731; Tue, 6 Jun 2023 12:40:20 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 5644C5FD04; Tue, 6 Jun 2023 22:40:18 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1686080418; bh=/a/D+K5/RvpmyF70t6iC3BBkjuaMSTKw05HEPcEHC4s=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=U6ocXN1G6uTrfaWco6cAeZM97dFR7tz6TUPf7CeCu5CPDjXQU2dre7b8dh0i+JaAK KqpPea98a9Weqoio4IuCXDQv2dpQGgtbwoSCvm8XjnJfQVFbqfnbB4D3Q5UBR9lyAK 8szkyAnbPVdaOpQoQfYawi3x2iLT6kpwIopS85LWSIYoDjNB0BB7k+60IAsnGgf+8z bNbRpjqIPeL6L+yDyQHQh2QB+zV0GTUEPp/7KGC8Zo94TH+VJeICPdbEuqkkMAJvbn HJalKIdx3G9HVCEMfKdfLC9dYslMShjC+j3ylvJiZCM5NcitWJhWFX/CXyqgChb047 Xga83sr0FzWCg== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Tue, 6 Jun 2023 22:40:16 +0300 (MSK) From: Arseniy Krasnov <AVKrasnov@sberdevices.ru> To: Liang Yang <liang.yang@amlogic.com>, Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com> CC: <oxffffaa@gmail.com>, <kernel@sberdevices.ru>, Arseniy Krasnov <AVKrasnov@sberdevices.ru>, <linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-amlogic@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v1] dt-bindings: nand: meson: Fix 'nand-rb' property Date: Tue, 6 Jun 2023 22:35:07 +0300 Message-ID: <20230606193507.35024-1-AVKrasnov@sberdevices.ru> X-Mailer: git-send-email 2.35.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH02.sberdevices.ru (172.16.1.5) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/06/06 14:43:00 #21444531 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,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?1767983690122385669?= X-GMAIL-MSGID: =?utf-8?q?1767983690122385669?= |
Series |
[v1] dt-bindings: nand: meson: Fix 'nand-rb' property
|
|
Commit Message
Arseniy Krasnov
June 6, 2023, 7:35 p.m. UTC
Add description of 'nand-rb' property. Use "Fixes" because this property
must be supported since the beginning. For this controller 'nand-rb' is
stored in the controller node (not in chip), because it has only single
r/b wire for all chips.
Fixes: fbc00b5e746f ("dt-bindings: nand: meson: convert txt to yaml")
Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
---
Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml | 3 +++
1 file changed, 3 insertions(+)
Comments
On Tue, 06 Jun 2023 22:35:07 +0300, Arseniy Krasnov wrote: > Add description of 'nand-rb' property. Use "Fixes" because this property > must be supported since the beginning. For this controller 'nand-rb' is > stored in the controller node (not in chip), because it has only single > r/b wire for all chips. > > Fixes: fbc00b5e746f ("dt-bindings: nand: meson: convert txt to yaml") > Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> > --- > Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml | 3 +++ > 1 file changed, 3 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: nand-rb: size (5) error for type uint32-array /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.example.dtb: nand-controller@ffe07800: nand-rb: b'true\x00' is not of type 'object', 'array', 'boolean', 'null' From schema: /usr/local/lib/python3.10/dist-packages/dtschema/schemas/dt-core.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230606193507.35024-1-AVKrasnov@sberdevices.ru The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Hi Arseniy, AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: > Add description of 'nand-rb' property. Use "Fixes" because this property > must be supported since the beginning. For this controller 'nand-rb' is > stored in the controller node (not in chip), because it has only single > r/b wire for all chips. Sorry if I mislead you in the first place, but you could definitely have two chips and only one with RB wired. It needs to be defined in the chips. Please keep the bindings and driver changes related to this in the same series. > > Fixes: fbc00b5e746f ("dt-bindings: nand: meson: convert txt to yaml") > Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> > --- > Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml > index 28fb9a7dd70f..866edf800b81 100644 > --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml > +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml > @@ -37,6 +37,8 @@ properties: > - const: core > - const: device > > + nand-rb: true > + > patternProperties: > "^nand@[0-7]$": > type: object > @@ -81,6 +83,7 @@ examples: > > pinctrl-0 = <&nand_pins>; > pinctrl-names = "default"; > + nand-rb = "true"; > > #address-cells = <1>; > #size-cells = <0>; Thanks, Miquèl
Hello Miquel, On 07.06.2023 10:58, Miquel Raynal wrote: > Hi Arseniy, > > AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: > >> Add description of 'nand-rb' property. Use "Fixes" because this property >> must be supported since the beginning. For this controller 'nand-rb' is >> stored in the controller node (not in chip), because it has only single >> r/b wire for all chips. > > Sorry if I mislead you in the first place, but you could definitely > have two chips and only one with RB wired. It needs to be defined in > the chips. Ok, so to clarify: is it ok, that in bindings this property will be placed in the chip, but in driver, i'm trying to read it from the controller node (thus in dts file it will be also in controller node)? Because in driver there is no sense to store this value in chip structure. In fact, in driver, I can read it from the chip node, but set 'no_rb_pin' flag in the controller structure. Thanks, Arseniy > > Please keep the bindings and driver changes related to this in the same > series. Ack > >> >> Fixes: fbc00b5e746f ("dt-bindings: nand: meson: convert txt to yaml") >> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >> --- >> Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml >> index 28fb9a7dd70f..866edf800b81 100644 >> --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml >> +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml >> @@ -37,6 +37,8 @@ properties: >> - const: core >> - const: device >> >> + nand-rb: true >> + >> patternProperties: >> "^nand@[0-7]$": >> type: object >> @@ -81,6 +83,7 @@ examples: >> >> pinctrl-0 = <&nand_pins>; >> pinctrl-names = "default"; >> + nand-rb = "true"; >> >> #address-cells = <1>; >> #size-cells = <0>; > > > Thanks, > Miquèl
On 07/06/2023 10:40, Arseniy Krasnov wrote: > Hello Miquel, > > On 07.06.2023 10:58, Miquel Raynal wrote: > >> Hi Arseniy, >> >> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >> >>> Add description of 'nand-rb' property. Use "Fixes" because this property >>> must be supported since the beginning. For this controller 'nand-rb' is >>> stored in the controller node (not in chip), because it has only single >>> r/b wire for all chips. >> >> Sorry if I mislead you in the first place, but you could definitely >> have two chips and only one with RB wired. It needs to be defined in >> the chips. > > Ok, so to clarify: is it ok, that in bindings this property will be placed in the > chip, but in driver, i'm trying to read it from the controller node (thus in > dts file it will be also in controller node)? No, because how would your DTS pass validation? I understand you did not test the bindings, but this will improve, right? > Because in driver there is no sense > to store this value in chip structure. Driver does not shape the DTS. Hardware does. Best regards, Krzysztof
On 07.06.2023 11:53, Krzysztof Kozlowski wrote: > On 07/06/2023 10:40, Arseniy Krasnov wrote: >> Hello Miquel, >> >> On 07.06.2023 10:58, Miquel Raynal wrote: >> >>> Hi Arseniy, >>> >>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >>> >>>> Add description of 'nand-rb' property. Use "Fixes" because this property >>>> must be supported since the beginning. For this controller 'nand-rb' is >>>> stored in the controller node (not in chip), because it has only single >>>> r/b wire for all chips. >>> >>> Sorry if I mislead you in the first place, but you could definitely >>> have two chips and only one with RB wired. It needs to be defined in >>> the chips. >> >> Ok, so to clarify: is it ok, that in bindings this property will be placed in the >> chip, but in driver, i'm trying to read it from the controller node (thus in >> dts file it will be also in controller node)? > > No, because how would your DTS pass validation? I understand you did not > test the bindings, but this will improve, right? Ok, i'll follow DTS layout in the driver, "test the bindings" You mean "make dt_binding_check"? > >> Because in driver there is no sense >> to store this value in chip structure. > > Driver does not shape the DTS. Hardware does. Ok, Thanks Thanks, Arseniy > > > > Best regards, > Krzysztof >
On 07.06.2023 12:08, Krzysztof Kozlowski wrote: > On 07/06/2023 10:57, Arseniy Krasnov wrote: >> >> >> On 07.06.2023 11:53, Krzysztof Kozlowski wrote: >>> On 07/06/2023 10:40, Arseniy Krasnov wrote: >>>> Hello Miquel, >>>> >>>> On 07.06.2023 10:58, Miquel Raynal wrote: >>>> >>>>> Hi Arseniy, >>>>> >>>>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >>>>> >>>>>> Add description of 'nand-rb' property. Use "Fixes" because this property >>>>>> must be supported since the beginning. For this controller 'nand-rb' is >>>>>> stored in the controller node (not in chip), because it has only single >>>>>> r/b wire for all chips. >>>>> >>>>> Sorry if I mislead you in the first place, but you could definitely >>>>> have two chips and only one with RB wired. It needs to be defined in >>>>> the chips. >>>> >>>> Ok, so to clarify: is it ok, that in bindings this property will be placed in the >>>> chip, but in driver, i'm trying to read it from the controller node (thus in >>>> dts file it will be also in controller node)? >>> >>> No, because how would your DTS pass validation? I understand you did not >>> test the bindings, but this will improve, right? >> >> Ok, i'll follow DTS layout in the driver, "test the bindings" You mean "make dt_binding_check"? > > Yes. They were sent without testing. > > But please also test your DTS with dtbs_check. Got it! Thanks, Arseniy > > > Best regards, > Krzysztof >
On 07/06/2023 10:57, Arseniy Krasnov wrote: > > > On 07.06.2023 11:53, Krzysztof Kozlowski wrote: >> On 07/06/2023 10:40, Arseniy Krasnov wrote: >>> Hello Miquel, >>> >>> On 07.06.2023 10:58, Miquel Raynal wrote: >>> >>>> Hi Arseniy, >>>> >>>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >>>> >>>>> Add description of 'nand-rb' property. Use "Fixes" because this property >>>>> must be supported since the beginning. For this controller 'nand-rb' is >>>>> stored in the controller node (not in chip), because it has only single >>>>> r/b wire for all chips. >>>> >>>> Sorry if I mislead you in the first place, but you could definitely >>>> have two chips and only one with RB wired. It needs to be defined in >>>> the chips. >>> >>> Ok, so to clarify: is it ok, that in bindings this property will be placed in the >>> chip, but in driver, i'm trying to read it from the controller node (thus in >>> dts file it will be also in controller node)? >> >> No, because how would your DTS pass validation? I understand you did not >> test the bindings, but this will improve, right? > > Ok, i'll follow DTS layout in the driver, "test the bindings" You mean "make dt_binding_check"? Yes. They were sent without testing. But please also test your DTS with dtbs_check. Best regards, Krzysztof
Hi Arseniy, avkrasnov@sberdevices.ru wrote on Wed, 7 Jun 2023 12:04:29 +0300: > On 07.06.2023 12:08, Krzysztof Kozlowski wrote: > > On 07/06/2023 10:57, Arseniy Krasnov wrote: > >> > >> > >> On 07.06.2023 11:53, Krzysztof Kozlowski wrote: > >>> On 07/06/2023 10:40, Arseniy Krasnov wrote: > >>>> Hello Miquel, > >>>> > >>>> On 07.06.2023 10:58, Miquel Raynal wrote: > >>>> > >>>>> Hi Arseniy, > >>>>> > >>>>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: > >>>>> > >>>>>> Add description of 'nand-rb' property. Use "Fixes" because this property > >>>>>> must be supported since the beginning. For this controller 'nand-rb' is > >>>>>> stored in the controller node (not in chip), because it has only single > >>>>>> r/b wire for all chips. > >>>>> > >>>>> Sorry if I mislead you in the first place, but you could definitely > >>>>> have two chips and only one with RB wired. It needs to be defined in > >>>>> the chips. > >>>> > >>>> Ok, so to clarify: is it ok, that in bindings this property will be placed in the > >>>> chip, but in driver, i'm trying to read it from the controller node (thus in > >>>> dts file it will be also in controller node)? The bindings and your driver internal representation are two different things. Anyway, as mentioned above, wiring the RB line to one die and not the other would be valid hardware design and would require the rb property to be in the chip node. Please perform a per-chip property read in the driver as well. > >>> > >>> No, because how would your DTS pass validation? I understand you did not > >>> test the bindings, but this will improve, right? > >> > >> Ok, i'll follow DTS layout in the driver, "test the bindings" You mean "make dt_binding_check"? > > > > Yes. They were sent without testing. > > > > But please also test your DTS with dtbs_check. > > Got it! > > Thanks, Arseniy > > > > > > > Best regards, > > Krzysztof > > Thanks, Miquèl
On 07.06.2023 12:36, Miquel Raynal wrote: > Hi Arseniy, > > avkrasnov@sberdevices.ru wrote on Wed, 7 Jun 2023 12:04:29 +0300: > >> On 07.06.2023 12:08, Krzysztof Kozlowski wrote: >>> On 07/06/2023 10:57, Arseniy Krasnov wrote: >>>> >>>> >>>> On 07.06.2023 11:53, Krzysztof Kozlowski wrote: >>>>> On 07/06/2023 10:40, Arseniy Krasnov wrote: >>>>>> Hello Miquel, >>>>>> >>>>>> On 07.06.2023 10:58, Miquel Raynal wrote: >>>>>> >>>>>>> Hi Arseniy, >>>>>>> >>>>>>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >>>>>>> >>>>>>>> Add description of 'nand-rb' property. Use "Fixes" because this property >>>>>>>> must be supported since the beginning. For this controller 'nand-rb' is >>>>>>>> stored in the controller node (not in chip), because it has only single >>>>>>>> r/b wire for all chips. >>>>>>> >>>>>>> Sorry if I mislead you in the first place, but you could definitely >>>>>>> have two chips and only one with RB wired. It needs to be defined in >>>>>>> the chips. >>>>>> >>>>>> Ok, so to clarify: is it ok, that in bindings this property will be placed in the >>>>>> chip, but in driver, i'm trying to read it from the controller node (thus in >>>>>> dts file it will be also in controller node)? > > The bindings and your driver internal representation are two different > things. Anyway, as mentioned above, wiring the RB line to one die and > not the other would be valid hardware design and would require the rb > property to be in the chip node. Please perform a per-chip property read > in the driver as well. Done, I resend both patches (bindings + driver update) as a single patchset. Your review comments for driver code were also fixed. > >>>>> >>>>> No, because how would your DTS pass validation? I understand you did not >>>>> test the bindings, but this will improve, right? >>>> >>>> Ok, i'll follow DTS layout in the driver, "test the bindings" You mean "make dt_binding_check"? >>> >>> Yes. They were sent without testing. >>> >>> But please also test your DTS with dtbs_check. Done Thanks, Arseniy >> >> Got it! >> >> Thanks, Arseniy >> >>> >>> >>> Best regards, >>> Krzysztof >>> > > > Thanks, > Miquèl
On 07.06.2023 17:58, Krzysztof Kozlowski wrote: > On 07/06/2023 16:52, Arseniy Krasnov wrote: >> >> >> On 07.06.2023 12:36, Miquel Raynal wrote: >>> Hi Arseniy, >>> >>> avkrasnov@sberdevices.ru wrote on Wed, 7 Jun 2023 12:04:29 +0300: >>> >>>> On 07.06.2023 12:08, Krzysztof Kozlowski wrote: >>>>> On 07/06/2023 10:57, Arseniy Krasnov wrote: >>>>>> >>>>>> >>>>>> On 07.06.2023 11:53, Krzysztof Kozlowski wrote: >>>>>>> On 07/06/2023 10:40, Arseniy Krasnov wrote: >>>>>>>> Hello Miquel, >>>>>>>> >>>>>>>> On 07.06.2023 10:58, Miquel Raynal wrote: >>>>>>>> >>>>>>>>> Hi Arseniy, >>>>>>>>> >>>>>>>>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >>>>>>>>> >>>>>>>>>> Add description of 'nand-rb' property. Use "Fixes" because this property >>>>>>>>>> must be supported since the beginning. For this controller 'nand-rb' is >>>>>>>>>> stored in the controller node (not in chip), because it has only single >>>>>>>>>> r/b wire for all chips. >>>>>>>>> >>>>>>>>> Sorry if I mislead you in the first place, but you could definitely >>>>>>>>> have two chips and only one with RB wired. It needs to be defined in >>>>>>>>> the chips. >>>>>>>> >>>>>>>> Ok, so to clarify: is it ok, that in bindings this property will be placed in the >>>>>>>> chip, but in driver, i'm trying to read it from the controller node (thus in >>>>>>>> dts file it will be also in controller node)? >>> >>> The bindings and your driver internal representation are two different >>> things. Anyway, as mentioned above, wiring the RB line to one die and >>> not the other would be valid hardware design and would require the rb >>> property to be in the chip node. Please perform a per-chip property read >>> in the driver as well. >> >> Done, I resend both patches (bindings + driver update) as a single patchset. Your review comments >> for driver code were also fixed. > > No, please send new version, not the same. New version means with fixed > comments and with patch changelog. Sorry, Yes, I mean new version, here it is: https://lore.kernel.org/linux-mtd/20230607145026.2899547-1-AVKrasnov@sberdevices.ru/ There I fixed bindings and tested it. Thanks, Arseniy > > Best regards, > Krzysztof >
On 07/06/2023 16:52, Arseniy Krasnov wrote: > > > On 07.06.2023 12:36, Miquel Raynal wrote: >> Hi Arseniy, >> >> avkrasnov@sberdevices.ru wrote on Wed, 7 Jun 2023 12:04:29 +0300: >> >>> On 07.06.2023 12:08, Krzysztof Kozlowski wrote: >>>> On 07/06/2023 10:57, Arseniy Krasnov wrote: >>>>> >>>>> >>>>> On 07.06.2023 11:53, Krzysztof Kozlowski wrote: >>>>>> On 07/06/2023 10:40, Arseniy Krasnov wrote: >>>>>>> Hello Miquel, >>>>>>> >>>>>>> On 07.06.2023 10:58, Miquel Raynal wrote: >>>>>>> >>>>>>>> Hi Arseniy, >>>>>>>> >>>>>>>> AVKrasnov@sberdevices.ru wrote on Tue, 6 Jun 2023 22:35:07 +0300: >>>>>>>> >>>>>>>>> Add description of 'nand-rb' property. Use "Fixes" because this property >>>>>>>>> must be supported since the beginning. For this controller 'nand-rb' is >>>>>>>>> stored in the controller node (not in chip), because it has only single >>>>>>>>> r/b wire for all chips. >>>>>>>> >>>>>>>> Sorry if I mislead you in the first place, but you could definitely >>>>>>>> have two chips and only one with RB wired. It needs to be defined in >>>>>>>> the chips. >>>>>>> >>>>>>> Ok, so to clarify: is it ok, that in bindings this property will be placed in the >>>>>>> chip, but in driver, i'm trying to read it from the controller node (thus in >>>>>>> dts file it will be also in controller node)? >> >> The bindings and your driver internal representation are two different >> things. Anyway, as mentioned above, wiring the RB line to one die and >> not the other would be valid hardware design and would require the rb >> property to be in the chip node. Please perform a per-chip property read >> in the driver as well. > > Done, I resend both patches (bindings + driver update) as a single patchset. Your review comments > for driver code were also fixed. No, please send new version, not the same. New version means with fixed comments and with patch changelog. Best regards, Krzysztof
On 07/06/2023 16:55, Arseniy Krasnov wrote: >>>> The bindings and your driver internal representation are two different >>>> things. Anyway, as mentioned above, wiring the RB line to one die and >>>> not the other would be valid hardware design and would require the rb >>>> property to be in the chip node. Please perform a per-chip property read >>>> in the driver as well. >>> >>> Done, I resend both patches (bindings + driver update) as a single patchset. Your review comments >>> for driver code were also fixed. >> >> No, please send new version, not the same. New version means with fixed >> comments and with patch changelog. > > Sorry, Yes, I mean new version, here it is: > https://lore.kernel.org/linux-mtd/20230607145026.2899547-1-AVKrasnov@sberdevices.ru/ > > There I fixed bindings and tested it. I still see v1 and there is no changelog. So it's the same? Best regards, Krzysztof
On 07.06.2023 18:07, Krzysztof Kozlowski wrote: > On 07/06/2023 16:55, Arseniy Krasnov wrote: >>>>> The bindings and your driver internal representation are two different >>>>> things. Anyway, as mentioned above, wiring the RB line to one die and >>>>> not the other would be valid hardware design and would require the rb >>>>> property to be in the chip node. Please perform a per-chip property read >>>>> in the driver as well. >>>> >>>> Done, I resend both patches (bindings + driver update) as a single patchset. Your review comments >>>> for driver code were also fixed. >>> >>> No, please send new version, not the same. New version means with fixed >>> comments and with patch changelog. >> >> Sorry, Yes, I mean new version, here it is: >> https://lore.kernel.org/linux-mtd/20230607145026.2899547-1-AVKrasnov@sberdevices.ru/ >> >> There I fixed bindings and tested it. > > I still see v1 and there is no changelog. So it's the same? No, v1 is for new patchset from the link above. Both patches (bindings and driver) are updated there. I attached changelog here as reply for cover letter of the patchset: https://lore.kernel.org/linux-mtd/a1e048aa-ec64-bd0b-aa17-e3e9bdf18090@sberdevices.ru/ Thanks, Arseniy > > Best regards, > Krzysztof >
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml index 28fb9a7dd70f..866edf800b81 100644 --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml @@ -37,6 +37,8 @@ properties: - const: core - const: device + nand-rb: true + patternProperties: "^nand@[0-7]$": type: object @@ -81,6 +83,7 @@ examples: pinctrl-0 = <&nand_pins>; pinctrl-names = "default"; + nand-rb = "true"; #address-cells = <1>; #size-cells = <0>;