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 B8F65C77B7C for ; Thu, 11 May 2023 09:22:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237120AbjEKJWX (ORCPT ); Thu, 11 May 2023 05:22:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232984AbjEKJWQ (ORCPT ); Thu, 11 May 2023 05:22:16 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC37835A5 for ; Thu, 11 May 2023 02:22:14 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id DE3145FD42; Thu, 11 May 2023 12:22:12 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1683796932; bh=S3C/qd36a5XSWTl3tC3h99nhsCKhX8Zq+qQB/zjZvlc=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; b=ZB4QzxQRBTsoJVA/f5PB1ldAygQmuHcwnHOETvUTSAeBg0e6DZVDkxZdYxFMStzqa re/PdjM4VZtVFsrGTdMPTCugwiX0zOGazaOpligQJImJ05p9Gy91BUvq6sedcZspFo hMwMRNdTGsELKxlludhffXL7tr1dfqIblip5OVD2cHNWGOmvLrF8vlfitlc+ekMajR TVMQgKZ95YUk4U730bOHTTJO4NWs+Bb2UWPS56/6FgY6q5O3XfdoDl1my2I/BAoz58 IbcEWqs0wX8g1NxBhCBCvRHVv/OD+z37PNVhH0OtDHMKX4Bdk8HOdA5piGZlY/484O GeSfp4uycrxHg== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Thu, 11 May 2023 12:22:11 +0300 (MSK) Message-ID: Date: Thu, 11 May 2023 12:17:31 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v3 6/6] mtd: rawnand: meson: rename node for chip select Content-Language: en-US To: Miquel Raynal CC: Martin Blumenstingl , Liang Yang , Richard Weinberger , Vignesh Raghavendra , Neil Armstrong , Kevin Hilman , Jerome Brunet , Jianxin Pan , Yixun Lan , , , , , , References: <20230510110835.26115-1-AVKrasnov@sberdevices.ru> <20230510110835.26115-7-AVKrasnov@sberdevices.ru> <20230510225359.061c2df6@xps-13> <6918ed54-3929-4832-1e93-6eb55b75c82b@sberdevices.ru> <20230511111204.0b0b3d70@xps-13> From: Arseniy Krasnov In-Reply-To: <20230511111204.0b0b3d70@xps-13> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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/05/11 05:14:00 #21258391 X-KSMG-AntiVirus-Status: Clean, skipped Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11.05.2023 12:12, Miquel Raynal wrote: > Hi Arseniy, > > avkrasnov@sberdevices.ru wrote on Thu, 11 May 2023 11:59:07 +0300: > >> On 10.05.2023 23:53, Miquel Raynal wrote: >> >> Hello Martin, Miquel >> >>> Hi Martin & Arseniy, >>> >>> martin.blumenstingl@googlemail.com wrote on Wed, 10 May 2023 22:40:37 >>> +0200: >>> >>>> Hello Arseniy, >>>> >>>> On Wed, May 10, 2023 at 1:13 PM Arseniy Krasnov >>>> wrote: >>>>> >>>>> This renames node with values for chip select from "reg" to "cs". It is >>>>> needed because when OTP access is enabled on the attached storage, MTD >>>>> subsystem registers this storage in the NVMEM subsystem. NVMEM in turn >>>>> tries to use "reg" node in its own manner, supposes that it has another >>>>> layout. All of this leads to device initialization failure. >>>> In general: if we change the device-tree interface (in this case: >>>> replacing a "reg" with a "cs" property) the dt-bindings have to be >>>> updated as well. >>> >>> True, and I would add, bindings should not be broken. >> >> I see, that's true. That is bad way to change bindings. >> >>> >>>> Documentation/devicetree/bindings/mtd/nand-controller.yaml and >>>> Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml show >>>> that the chip select of a NAND chip is specified with a "reg" >>>> property. >>> >>> All NAND controller binding expect the chip-select to be in the >>> 'reg' property, very much like a spi device would use reg to store the >>> cs as well: the reg property tells you how you address the device. >>> >>> I also fully agree with Martin's comments below. Changing reg is likely >>> a wrong approach :) >>> >>>> Also the code has to be backwards compatible with old .dtbs. >>>> >>>>> Example: >>>>> >>>>> [...] nvmem mtd0-user-otp: nvmem: invalid reg on /soc/bus@ffe00000/... >>>>> [...] mtd mtd0: Failed to register OTP NVMEM device >>>>> [...] meson-nand ffe07800.nfc: failed to register MTD device: -22 >>>>> [...] meson-nand ffe07800.nfc: failed to init NAND chips >>>>> [...] meson-nand: probe of ffe07800.nfc failed with error -22 >>>> This is odd - can you please share your definition of the &nfc node? >> >> Sure, here it is: >> >> mtd_nand: nfc@7800 { >> compatible = "amlogic,meson-axg-nfc"; >> ... >> nand@0 { >> reg = <0>; >> }; >> } >> >> I checked, that 'nand_set_flash_node()' is called with 'nand@0' and i suppose >> that it is correct (as You mentioned below). But, 'nvmem_add_cells_from_of()' is called >> with parent: 'nfc@7800', then it iterates over its childs, e.g. 'nand@0' and thus i get such >> situation. I guess, that 'nvmem_add_cells_from_of()' must be called with 'nand@0' ? > > We recently had issues with nvmem parsing, but I believe a mainline > kernel should now be perfectly working on this regard. What version of > the Linux kernel are you using? My current version is: VERSION = 6 PATCHLEVEL = 2 SUBLEVEL = 0 EXTRAVERSION = -rc8 Fix was in drivers/nvmem/* ? Thanks, Arseniy > > Thanks, > Miquèl