Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4066171pxu; Mon, 12 Oct 2020 08:38:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymjWvK4rceoEWhhA1jSwJgZR6iX/h3PlRO6mAIFXNC4q9uhn+WHc8UphjaBQgYVuV88jJW X-Received: by 2002:a17:906:7013:: with SMTP id n19mr28216979ejj.388.1602517121250; Mon, 12 Oct 2020 08:38:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602517121; cv=none; d=google.com; s=arc-20160816; b=V9HdJQ1rkZwIMsCL9lgbWCx9awGGA3mxwbGY1pgoMRvsEoegX1stdHnVIN6jYZq4Zw Q/cKW+u1neFVZFfhWRrREgU2eyUJWo0KUe5eqKjouX/kkRjN1WdCsY0hwup9yWB+cDBG 7r5xZ2Xg4x960z5EW7vzNDbjGG1yo47zmb2MsvN+Lf1MNCME6Xw8atQqEw+ypNcOco8o V/m33AXo1nmzYy67X07ro6ORYs2uIn7GAwhNaEOqyz4rW5ZOG/JeSTyfxx987xfSVV3H KLTg6uXTbPF0TtFtoP/UAfJEwH0RZftM9q2OF/t9z6nDoATPjdiKVnh+umpog2mrMc71 d+fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:subject:from; bh=ScLuhrAUIEDRfgTzGYvLaeiDjclan2GOC0CsEPIRCQM=; b=tQfPOfkCg9I72AE5sLiHCNtsmTG07lIGYx6dAnahAzRYgKcK8q6s06ESYxHDuDilnS ELQ+lufrqJWuLFn1t/JCN2tDlXNo6PE8x9/DZV3BdkQ+g9Gz0dr9UJuKZqMA66lj+I+k X+qWKoGUD3UpnVkNDGBKdmaKnf/D1V55QjNa7Ou78bJbFVSWBPGZxhJzHE4niy+Yn3ik mjBvzIF3TTfMG25NhF5BBjMHJLv8NqEvUtI4v7GnAaA53Slb8sWpiQ6+Lzps61zmAd8B d430IXlZ04Rqp4OFnTYChdH5wCncnKv+eFG7CQcHUk9yKDI4gyXxOL/HBhTOyJ8g1ESg /ztw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp17si5075754ejc.524.2020.10.12.08.38.16; Mon, 12 Oct 2020 08:38:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390204AbgJLPgF (ORCPT + 99 others); Mon, 12 Oct 2020 11:36:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389121AbgJLPgF (ORCPT ); Mon, 12 Oct 2020 11:36:05 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F32A0C0613D0 for ; Mon, 12 Oct 2020 08:36:04 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1kRzrl-0000Wq-U5; Mon, 12 Oct 2020 17:36:01 +0200 From: Ahmad Fatoum Subject: Re: [PATCH v3 0/2] nvmem: skip nodes with compatibles other than "nvmem-cell" To: Rob Herring , Srinivas Kandagatla Cc: linux-kernel@vger.kernel.org, kernel@pengutronix.de, ceggers@arri.de, devicetree@vger.kernel.org References: <20200428111829.2215-1-a.fatoum@pengutronix.de> <20200512141834.GA3023@bogus> Message-ID: Date: Mon, 12 Oct 2020 17:36:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20200512141834.GA3023@bogus> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Rob, Hello Srini, On 5/12/20 4:18 PM, Rob Herring wrote: > On Tue, Apr 28, 2020 at 01:18:25PM +0200, Ahmad Fatoum wrote: >> The nvmem cell binding applies to all objects which match "^.*@[0-9a-f]+$", >> without taking a compatible into account. This precludes extension of e.g. >> eeprom nodes by any child nodes other than nvmem. Consider following example: >> >> eeprom@0 { >> reg = <0 64>; >> #address-cells = <1>; >> #size-cells = <1>; >> >> partitions { >> compatible = "fixed-partitions"; >> #address-cells = <1>; >> #size-cells = <1>; >> bits = <64 64 64>; /* to verify it's skipped */ >> >> part@0 { >> reg = <0x00 16>; >> }; >> }; >> >> no-cell@10 { >> compatible = "not-nvmem-cell"; >> reg = <0x10 4>; >> bits = <64 64 64>; /* to verify it's skipped */ >> }; >> >> cell-old@14 { >> reg = <0x14 0x2>; >> }; >> >> cell-new@16 { >> compatible = "nvmem-cell"; >> reg = <0x16 4>; >> }; >> }; >> >> Without this series, the NVMEM driver interprets all direct children of eeprom@0 >> as NVMEM cells and driver probe fails, because the partitions node lacks a reg >> property, e.g.: >> >> nvmem 0-00000: nvmem: invalid reg on /eeprom@0 >> >> Running dtbs_check on the snippet will skip partitions (it doesn't match above >> regex), but will flag no-cell@10 and cell-new@16 as invalid. >> >> With this series applied, the driver will skip partitions and no-cell@10, >> because they have a compatible but it's not "nvmem-cell". > > Because you have to support no compatible (forever), there's no point > adding this compatible. IMO nvmem cells should have had a compatible since the beginning and I figured better late than never. >> Both cell-old@14 and cell-new@16 will be interpreted as cells. >> >> Likewise, running dtbs_check on the snippet will skip partitions (compatible >> doesn't match and regex doesn't either) and no-cell@10, but accept the other two. >> >> This series resolves an existing clash between this nvmem-cell binding and >> the barebox bootloader binding that extends the fixed-partitions MTD >> binding to EEPROMs[1]. It's also a building block for getting nvmem cells and >> partitions in MTD devices to co-exist in the same device tree node[2]. > > This violates having multiple nodes at the same address because you are > independently overlaying partitions and nvmem cells on same address > ranges. It also seems seems pretty fragile if you want to update > partitions. > > I think instead, nvmem cells should be contained within a partition. > The partition should then have a compatible to indicate it contains > nvmem cells. I thought I had understood what needs to be done, but now that I finally have time to do it, I see that this only solves the second issue "extending the NVMEM binding to nodes that already have other child nodes, e.g., MTD and its partitions". The first issue: "future extension of e.g. eeprom nodes by any child nodes other than nvmem cells" isn't solved by having a containing partition. My issue is that the bootloader fixes up a partitions { compatible = "fixed-partitions"; } child node into the kernel device tree. The NVMEM core driver tries to parse all eeprom child nodes as cells and will make the driver probe of the EEPROM fail, because it can't parse that fixed-partitions node as a nvmem cell. To allow for co-existence of NVMEM cells and other subnodes, would following patch be acceptable to you and Srini? ---------------------------------------- 8< -------------------------------------- --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -45,7 +45,15 @@ properties: patternProperties: "^.*@[0-9a-f]+$": type: object - + if: + not: + properties: + compatible: + then: + $ref: "#/definitions/nvmem-cell" + +definitions: + nvmem-cell: properties: reg: maxItems: 1