Received: by 10.192.165.156 with SMTP id m28csp17915imm; Tue, 17 Apr 2018 05:56:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/ODJ7xdWmBoeIEuKskelGJGiXzmbGAxYV8wnAvlxUtYuQqZW6OnvLFFR+JELrrjO8EVBAR X-Received: by 10.101.85.143 with SMTP id j15mr1714755pgs.286.1523969763693; Tue, 17 Apr 2018 05:56:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523969763; cv=none; d=google.com; s=arc-20160816; b=WyP8mmPXqSV7+9oPFKFnpfcvYAG2wTQJae3ySHt5vGGRnsCqvi/8HcHTQjIhVR3s+B lEa1zviuuOwjaEQ9Ghibhl3uZCq1JZGjwM2m5+JdafxCB/wuLdSR/CQup/xlMcpgny3h CF1vXViqzRZWd7ohEcqKJqFQAt2MIFRX6CPCSbPPTE8GxXz1a/N76Hba37PNisnobhOi Yzo0vOONomo3WNCNQejYF7S9EnJq2B3dFCLUBhoz3ndxbl728Yzcly8G6CaQJFjwpyym pS861j3/Q9wuZMQHfHhRz7hoIBHPQAC16qpVntPLRfzi6iZsWKoia5bqg5vK1xYdQkCD RESA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=vqb+xt4wa4zAq33YkUw9p56IDzWNhU0p1wEmHuFWU8M=; b=Gky0C64GM4b0oOmljWnzxifkzoC7u4gnKXM7l4Ek5s9HaFDCrzZcApTTOGYxL5ixP7 YBvcOe1Qu4BZUgQPqzIdcb/ajN+FPnHZstGp8PwkEJmDPM/+lxz3LuW+LIxmlNEiFA0r VcxoyIoJB+xOqtQi2KoJvBSaKQLr6H3uIeePwm3+IdIMJM874uMz5YxEgXvftQDJUGvM FDBQKhIZlE/c2yCW/g+mJhWkM2GFkieLgEDg5VjfTr6B0gDEjz5HlPhqDdyuDISuR2Vy +gTBuaWCVcqEjzpnSoFs9ViL1GruovGqoz9y/xlvyfIsznKDpUh91kdqGiUUlIEfxJRj fuzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VnnmQPPi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n76si13039767pfi.122.2018.04.17.05.55.49; Tue, 17 Apr 2018 05:56:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VnnmQPPi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753499AbeDQMyM (ORCPT + 99 others); Tue, 17 Apr 2018 08:54:12 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:41172 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753097AbeDQMyK (ORCPT ); Tue, 17 Apr 2018 08:54:10 -0400 Received: by mail-wr0-f194.google.com with SMTP id v24so18169093wra.8 for ; Tue, 17 Apr 2018 05:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vqb+xt4wa4zAq33YkUw9p56IDzWNhU0p1wEmHuFWU8M=; b=VnnmQPPi50aDBwaw9T/ZfZk3uZwZPWPoRaVCtnaTAtiwyMEmKylAgBg2WmAgsCoyS4 bG34DPUMaaA3j8dYoFM4QhbNTSJ1BCbVwqZXO2oWJ7+NT/y0sH3vTQ6zBtl32HtuBFxJ aT/pkPC+wTPw1JmGigO3lCvOoq8WpYwCy/g8s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vqb+xt4wa4zAq33YkUw9p56IDzWNhU0p1wEmHuFWU8M=; b=GCF45rUJ7xx8EWyF/ubVqwsoKN0Ez3HzLiGtZy41vaNKCwk++ASc6gcMe4+W2UaORF dzRy3T8FeYAjT/7NdhgHWvEQXd+1+Zhbhjue5cwuPXA4UmKxw0lzd+sYPxHSSijEqBUl fJ9J6xxCAC0TLCLVspnCF54D4ozgE1U8WWGmF58Jn4hw/8YpvaLb5xr553aPQ2xPNPEZ d5ulKN8zKjABBB0Emqogr6s+KCQntQHcNF9dvWlUetXnLRQnQN+Q+DpFMY+zwo/brYDo CN26EFPrBrMIsQjnM/2tlP7isIJ6E5IVBdMNaMtF+PLgQx1X/Wg6y+8ZqqBh6yOnO/3C zsog== X-Gm-Message-State: ALQs6tC2srnUZvTBsu7vIZ4F/TFBSEcGeaxpp0zBQKD76RZZpfTWXYeI kcHjaWrDngnYxaeNw7IXVvLrKw== X-Received: by 10.223.172.170 with SMTP id o39mr1618202wrc.38.1523969649363; Tue, 17 Apr 2018 05:54:09 -0700 (PDT) Received: from [192.168.0.20] (cpc90716-aztw32-2-0-cust92.18-1.cable.virginm.net. [86.26.100.93]) by smtp.googlemail.com with ESMTPSA id d9sm14606343wmh.38.2018.04.17.05.54.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 05:54:08 -0700 (PDT) Subject: Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list To: Alban Bedel , linux-kernel@vger.kernel.org Cc: Rob Herring , Mark Rutland , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , devicetree@vger.kernel.org, linux-mtd@lists.infradead.org References: <1521933899-362-1-git-send-email-albeu@free.fr> <1521933899-362-2-git-send-email-albeu@free.fr> From: Srinivas Kandagatla Message-ID: <344e0087-7410-aebb-8a66-c6976064df10@linaro.org> Date: Tue, 17 Apr 2018 13:54:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1521933899-362-2-git-send-email-albeu@free.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/03/18 23:24, Alban Bedel wrote: > Having the cells as subnodes of the provider device without any > compatible property might clash with other bindings. To avoid this > problem update the binding to have all the cells in a 'nvmem-cells' > subnode with a 'nvmem-cells' compatible string. This new binding > guarantee that we can turn any kind of device in a nvmem provider. > > While discouraged for new uses the old scheme is still supported for > backward compatibility. Am not sure if this a really good idea to change nvmem bindings based on provider requirements. This can be a beginning of other problems!! Did you know that we can pass nvmem cells info via nvmem config ? Why can't mtd-nvmem provider populate the nvmem_config->cells from its dt "nvmem-cells" subnode before it registers the provider? Doing this way will make the binding very much specific to the provider rather than changing nvmem core bindings. thanks, srini