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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A54EAECAAA1 for ; Thu, 27 Oct 2022 13:18:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236090AbiJ0NSs (ORCPT ); Thu, 27 Oct 2022 09:18:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236069AbiJ0NSi (ORCPT ); Thu, 27 Oct 2022 09:18:38 -0400 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::226]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D7188E9B7; Thu, 27 Oct 2022 06:18:32 -0700 (PDT) Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 5619FC000C; Thu, 27 Oct 2022 13:18:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1666876710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uqF5CDn38yx/3Kjsiob6zhNia5VejsygoU+CPgjinFI=; b=cJB3cGS02+Hu+GcXYQ4LKwvNNiuEon/LwyvVz7WhKFkBGOV2vkQIRi5IEw9Yjl2HlhvI0Z dyXW3IkwQezIw9bkXBbrS8dPwC/9zW8G7dNAeFHf8a0PG4dhvqXw9yB1ihVQ3/szoKtwxG 48tWs+QUk0I2FeySavoqxJC0PX8oGc/PgjADbgbXijYVoB4cA3yEmGWyMvmOsXFSn8MA5n Mg5IZvqIp5ab4RapF0UsQ4VImW/Hm6ppjLqtFKKBtrcUYlrM+ochPl9cAXyHiWdaNsxKiA SazdG7BORiSbCUavr5D/i+dKHCKLtnR8JJj/e3Hir2ZEZ+bmXNFkfm2KtYn8fQ== Date: Thu, 27 Oct 2022 15:18:25 +0200 From: Miquel Raynal To: Krzysztof Kozlowski 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 Subject: Re: [PATCH v5 1/2] dt-bindings: mtd: marvell-nand: Convert to YAML DT scheme Message-ID: <20221027151825.166a9255@xps-13> In-Reply-To: <10581088-e4ff-76db-3c9b-42a7a9c118ee@linaro.org> 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> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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 hardwar= e ECC. > >>> + Howerver, it may be added when using hardware ECC for clar= ification > >>> + but will be ignored by the driver because ECC mode is chos= en depending > >>> + on the page size and the strength required by the NAND chi= p. > >>> + This value may be overwritten with nand-ecc-strength prope= rty. > >>> + > >>> + 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 si= ze > >>> + will shrink or grow in order to fit the required strength. > >>> + Step sizes are not completely random for all and follow ce= rtain > >>> + patterns described in AN-379, "Marvell SoC NFC ECC". > >>> + > >>> + label: > >>> + $ref: /schemas/types.yaml#/definitions/string > >>> + > >>> + partitions: > >>> + type: object =20 > >> > >> 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.ya= ml > >> 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. > >> > >> =20 > >=20 > > It is a bit confusing that it is needed to define "partitions" and "lab= el" rules particulary > > in this nand controller instead of some common place like nand-chip.yam= l, these properties > > are common also for the other nand controllers. =20 >=20 > No one speaks about label, I never commented about label, I think... >=20 > 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. 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). Cheers, Miqu=C3=A8l