From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 032AFECAAA1 for ; Fri, 28 Oct 2022 11:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xvvLBEYJdds2L0p5w6vbzeWobB3DK3janl2332CxSKI=; b=4LsG2vh91Vqc9b PXQG1tJwlp6jjcz+bzXJcqMpMs7nrQ+5eXh4qMx+hrcmsh6F357J6uv8pz4smPZewSF0rr+Kwn4N9 tDhYI2KZT1pvwWhQZKpH4iJI0x6gkcO3teHUdI2fRj/Sc/mwMTy2i5fP44QY0DxAb5OVkPfSS3zv+ D6InHrKl7rNSkmxoNUMSt2A8XKYHN7VS1bRdP/F4CgUz66QDvAMN3KgIyzco6JZHL2Rx4B8ATTC33 Ir5eMRr0lO8cJvnekIpG9JTXg0i1Bbg0GuDxXaxXaje/SKBhxUtjA6ru81KpnMOOkzpsxlBMZPMpg JsMl5cJEd99TFXbXEyhA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ooNae-00GxAw-7U; Fri, 28 Oct 2022 11:31:56 +0000 Received: from mail-qk1-x732.google.com ([2607:f8b0:4864:20::732]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ooNaT-00Gx8g-EK for linux-mtd@lists.infradead.org; Fri, 28 Oct 2022 11:31:47 +0000 Received: by mail-qk1-x732.google.com with SMTP id o28so532020qkl.4 for ; Fri, 28 Oct 2022 04:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hFGNTlzJVbGzTlwRhj/VBfk+5tnAHbXEChzttEBCShs=; b=KMEUfSaF+5qB5N+7CiySj7HfV/xpdPV1X5P+ow/+vpnjM76CwEF6PtndJUOBYg9WmQ pd1rzNjUx/IVQsI9oxWVJoepR7QKcFNdH0Kvk9UJfdvM6GvbciXdpr7SKXL5EiH0LI9g G4fk3cDvb7StnlZAng2V+F27NpopjNG6Y0qOtFFp29eEmL7XzvQUw46PxLbnQgSSywUB BAfzTVUGWDz4/b2W60OeRk8ALhz2nuje8d8n4E6xxatg4DHIAwyuExvW9SKB/X6Iccid R64Vo+9K/CU8Ny7WN3H/GF9Esmf5UC+P5bEd7rOBOGIRuIdXDyEn3hPyOKuom5BaLY+Q lvbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hFGNTlzJVbGzTlwRhj/VBfk+5tnAHbXEChzttEBCShs=; b=LKrHQYWoSdG7WJFwzU+Np9K1Ui0jKabJ7VylbO8XhVrfckz0CVRjwH58VIeuuvpBNx 2SABiRzLjj/kw63XHcFXAhSbsj3MN8Nw7N86LM2PiIvctCmOic0P5V720VB4KzYfhsta CoiYRkYEnwwA83+vskOSgsdnxZqrHCnSzmnLKAgtMkpUYZ2+AaHvgxQsbjeKRgXNFOrV xdsMzE2zqPEB/QguyGHHaUHCtVsoiZMrNdFBABVffowU+eh2RFyxe5wOrlXaOc5WcDw2 b87Rn6Bc4oaC41YlfzsW5n9J7GmSSq17ggS1ju++x1f7j1CQfRl5g5Z1shzCqCVK1ioS lMeg== X-Gm-Message-State: ACrzQf0XUEUZmN2ybiUek0xAx47yyIh3d29GxRx0NO5GAI1GfTAOB3Sd LPqV81Wi7u1Hl4CZZCMKxcTDOA== X-Google-Smtp-Source: AMsMyM4P66qNsfOwoP5BdK92GEQsLgzJXa9UvzrxElfIHKx925179DcUnLkD8QGNgb1uuVE5Fb6KLQ== X-Received: by 2002:a05:620a:17ab:b0:6fa:d45:a749 with SMTP id ay43-20020a05620a17ab00b006fa0d45a749mr600992qkb.194.1666956702331; Fri, 28 Oct 2022 04:31:42 -0700 (PDT) Received: from [192.168.1.11] ([64.57.193.93]) by smtp.gmail.com with ESMTPSA id q21-20020a05620a0d9500b006eec09eed39sm2773393qkl.40.2022.10.28.04.31.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 04:31:41 -0700 (PDT) Message-ID: Date: Fri, 28 Oct 2022 07:31:39 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v5 1/2] dt-bindings: mtd: marvell-nand: Convert to YAML DT scheme Content-Language: en-US To: Miquel Raynal Cc: Vadym Kochan , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Elad Nachman , Chris Packham References: <20221026134545.7146-1-vadym.kochan@plvision.eu> <20221026134545.7146-2-vadym.kochan@plvision.eu> <33f04b06-dc00-b7ce-6a24-2282608b40dc@linaro.org> <10581088-e4ff-76db-3c9b-42a7a9c118ee@linaro.org> <20221027151825.166a9255@xps-13> <20221027155025.7c04774a@xps-13> <683dffbc-744f-80cd-2262-b6deb4200ccc@linaro.org> <20221028094740.3c11f52b@xps-13> From: Krzysztof Kozlowski In-Reply-To: <20221028094740.3c11f52b@xps-13> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221028_043145_522341_9716CC24 X-CRM114-Status: GOOD ( 31.86 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On 28/10/2022 03:47, Miquel Raynal wrote: > Hi Krzysztof, > > krzysztof.kozlowski@linaro.org wrote on Thu, 27 Oct 2022 10:51:29 -0400: > >> On 27/10/2022 09:50, Miquel Raynal wrote: >>> Hi Krzysztof, >>> >>> krzysztof.kozlowski@linaro.org wrote on Thu, 27 Oct 2022 09:24:24 -0400: >>> >>>> On 27/10/2022 09:18, Miquel Raynal wrote: >>>>> Hi Vadym, >>>>> >>>>>>>>> +patternProperties: >>>>>>>>> + "^nand@[0-3]$": >>>>>>>>> + type: object >>>>>>>>> + properties: >>>>>>>>> + reg: >>>>>>>>> + minimum: 0 >>>>>>>>> + maximum: 3 >>>>>>>>> + >>>>>>>>> + nand-rb: >>>>>>>>> + minimum: 0 >>>>>>>>> + maximum: 1 >>>>>>>>> + >>>>>>>>> + nand-ecc-strength: >>>>>>>>> + enum: [1, 4, 8] >>>>>>>>> + >>>>>>>>> + nand-on-flash-bbt: true >>>>>>>>> + >>>>>>>>> + nand-ecc-mode: true >>>>>>>>> + >>>>>>>>> + nand-ecc-algo: >>>>>>>>> + description: | >>>>>>>>> + This property is essentially useful when not using hardware ECC. >>>>>>>>> + Howerver, it may be added when using hardware ECC for clarification >>>>>>>>> + but will be ignored by the driver because ECC mode is chosen depending >>>>>>>>> + on the page size and the strength required by the NAND chip. >>>>>>>>> + This value may be overwritten with nand-ecc-strength property. >>>>>>>>> + >>>>>>>>> + nand-ecc-step-size: >>>>>>>>> + description: | >>>>>>>>> + Marvell's NAND flash controller does use fixed strength >>>>>>>>> + (1-bit for Hamming, 16-bit for BCH), so the actual step size >>>>>>>>> + will shrink or grow in order to fit the required strength. >>>>>>>>> + Step sizes are not completely random for all and follow certain >>>>>>>>> + patterns described in AN-379, "Marvell SoC NFC ECC". >>>>>>>>> + >>>>>>>>> + label: >>>>>>>>> + $ref: /schemas/types.yaml#/definitions/string >>>>>>>>> + >>>>>>>>> + partitions: >>>>>>>>> + type: object >>>>>>>> >>>>>>>> That's not what I asked for. Like four times I asked you to add here >>>>>>>> unevaluatedProperties: false and I never said that ref to partition.yaml >>>>>>>> should be removed and you... instead remove that ref. >>>>>>>> >>>>>>>> You need to define here children and specify their ref. >>>>>>>> >>>>>>>> You must use unevaluatedProperties: false here. So this is fifth time I >>>>>>>> am writing this feedback. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> It is a bit confusing that it is needed to define "partitions" and "label" rules particulary >>>>>>> in this nand controller instead of some common place like nand-chip.yaml, these properties >>>>>>> are common also for the other nand controllers. >>>>>> >>>>>> No one speaks about label, I never commented about label, I think... >>>>>> >>>>>> If you think the property is really generic and every NAND controller >>>>>> bindings implement it, then feel free to include them there, in a >>>>>> separate patch. It sounds sensible, but I did not check other bindings. >>>>> >>>>> FYI, label is already defined in mtd/mtd.yaml. >>>> >>>> Which is not included here and in nand-controller.yaml >>> >>> Maybe nand-chip.yaml should? >> >> mtd.yaml looks a bit more than that - also allows nvmem nodes. Maybe >> let's just add label to nand-chip? > > I don't get the reason behind this proposal, mtd.yaml really is > kind of a definition of generic properties any mtd device might > have, so duplicating label (or whatever else inside) does not seem > legitimate to me. The jedec,spi-nor.yaml file already references it for > instance. spi-nor is not a NAND chip... By including mtd.yaml in nand-chip you also allow the NVMEM properties which are not applicable. > >>>>> Partitions do not need to be defined in your binding, just don't put >>>>> any in your example and you'll be fine. These partitions are either >>>>> static and may be described in the DT (see >>>>> mtd/partition/partition.yaml) or there is some dynamic discovery >>>>> involved and a proper parser shall be referenced (parsers have their >>>>> own binding). >>>> >>>> I don't think this is correct. Basically you allow any node to be under >>>> partitions as there is no schema validating them (without compatibles). >>> >>> Sorry if that was unclear, what I meant is: partitions should not be >>> defined in the bindings for Marvell NAND controller because they should >>> be defined somewhere else already. >> >> Ah, right. Then it seems reasonable. >> >>> >>> NAND controller subnodes should define the storage devices (the >>> flashes themselves) connected to the controller. "nand-chip.yaml" >>> describes generic properties for these. Additional subnodes are allowed >>> and expected to be partitions (this is not enforced anywhere I think), >>> they should use one of the existing compatibles to define the parser. >>> The most common parser is named fixed-partitions and has its own >>> compatible. Every parser references partitions.yaml. >>> >>> There are a few controller bindings however which reference >>> partition.yaml anyway, probably to make the examples validation work, >>> I'm not sure it should be done like that though: >>> https://elixir.bootlin.com/linux/v6.0/source/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml >>> https://elixir.bootlin.com/linux/v6.0/source/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml >> >> >> Yes, so the nand-chip implementation (like Marvell NAND) could reference >> the parser and we would be done. If it doesn't, then we must have >> generic partitions in the nand-chip. > > In this case, I am not aware of any parser that would be relevant. > > In the generic case, should we really reference a parser in particular? > If yes then maybe we should make a yaml file that just gathers all the > parsers and include it within mtd.yaml (and have it referenced in > nand-chip.yaml). What do you think? > Not all MTD devices have partitions so putting this into mtd.yaml does not look correct. Adding it into nand-chip seems fine. Best regards, Krzysztof ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/