Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2753802ybk; Tue, 12 May 2020 07:22:20 -0700 (PDT) X-Google-Smtp-Source: APiQypIcF0myqheR6YddMLGiOXciplkC9SGWPBbQW2HG7X5UQjyzAOXfD78r+MnSdSDuXs3/i193 X-Received: by 2002:a05:6402:286:: with SMTP id l6mr11684194edv.253.1589293339982; Tue, 12 May 2020 07:22:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589293339; cv=none; d=google.com; s=arc-20160816; b=Fd2Eb4DQeaAC0m/xhEsfsoUGQk6mhFPLX3mPyQqZM1BwewT1miJ+wOqR4DENpPDKHj W0pKbFSjpE5kag9FRxm1PcB0tw1jYFHFPWk/9IxRYI368bjZzSaE4rxRQDg1t1L7v95E 54Pgt472dlIrR3ikIJ8RYgWhgwFFXP5KY0PdKntsu1Oh/z5Kd8Wut6mNsGz8qBG1wCpD /I9hidP1HRydyy2i7V2serFFQSfhPhhaGa8FjrdxCs44/Cd1wZeFPaR4UXZftWRQurGs bBgVar9QEEOLUFffOUFXszFu9q6CD6yWpf0SFbIfA3/rHXalWf1Hb5IYQxLQrsLOkHB/ uBRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zfs2hAY/NiesXQzcF+Dz6T3qLZIhaZ4TvR72I/v5n/4=; b=0zcfr13sIwpQeTotUyvQKxhfZYtb1Y1hTjwTfhIwRPChhm9QrHAOBkZsjVm11I6TSx JBAUf282pAjwuP9wZ9kFlWGo8PwSDalxRyn0jMTvOkWWJ4tq5/nTLMmwDbHIsTVMEtJa bCH1x7vrV28QINU/Xvr/mxZbUbgtWt37qBLgI5J+YM7XlpX/gdcCFtQqiCuvv8cZATa4 oVmE1SabK2oF0DUyy/ERSqoyLE+bq3B9udSptHWy+w7SmdiKNSghRAT3JVxBiCHab48j giJEsOlBJrIeWcXWZlpoYz/eoxl0c18eySt0uyS9jU7hXD2yRnCny5aESnW4Ballx5nS yxcA== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp18si9828987ejc.498.2020.05.12.07.21.57; Tue, 12 May 2020 07:22:19 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730142AbgELOSh (ORCPT + 99 others); Tue, 12 May 2020 10:18:37 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:41804 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729583AbgELOSg (ORCPT ); Tue, 12 May 2020 10:18:36 -0400 Received: by mail-ot1-f66.google.com with SMTP id 63so3217307oto.8; Tue, 12 May 2020 07:18:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zfs2hAY/NiesXQzcF+Dz6T3qLZIhaZ4TvR72I/v5n/4=; b=h4I/ZMjOPHZt6LML5siOmRpUkWdNabnSPAaDTdnaPzDH93/vzLEx+q063UvNQLXiz5 UdZK9l0yKantT3PpIQF9EqrrGtyevLJIC1XONWQVSUsySH0s7fYwLMj6NiV39qBZHBIM kz91C/WykGPGz0uKojJMImQul+77jvsMuKDMCZUdf3KKJqe577BqrlusnPownpp2SCV/ IEqcJYEDAc9RJDNPdA/lBsY/UnK0kk+rpxK4FjSZXLObsTy+STFzSsZMb369KDDDZdPv XbUOf1jr0v8iBTzPv1zecj0n4FkHTa1dphbygqTkOnIwBBPIegqxGjDJvliPqGWFWWRr BVqw== X-Gm-Message-State: AGi0PuaJWanz9roT3/TG5SwHBIdz14EMNM7y11U8NdNEtnpswheCR02B Mj5qu/6aDqZcsFvrWv2b+CEloBSU9g== X-Received: by 2002:a9d:51c4:: with SMTP id d4mr15829366oth.249.1589293115368; Tue, 12 May 2020 07:18:35 -0700 (PDT) Received: from rob-hp-laptop (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id d10sm592500ote.10.2020.05.12.07.18.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 07:18:34 -0700 (PDT) Received: (nullmailer pid 9519 invoked by uid 1000); Tue, 12 May 2020 14:18:34 -0000 Date: Tue, 12 May 2020 09:18:34 -0500 From: Rob Herring To: Ahmad Fatoum Cc: linux-kernel@vger.kernel.org, kernel@pengutronix.de, ceggers@arri.de, devicetree@vger.kernel.org Subject: Re: [PATCH v3 0/2] nvmem: skip nodes with compatibles other than "nvmem-cell" Message-ID: <20200512141834.GA3023@bogus> References: <20200428111829.2215-1-a.fatoum@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200428111829.2215-1-a.fatoum@pengutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. Rob