Received: by 10.192.165.156 with SMTP id m28csp1197801imm; Wed, 18 Apr 2018 05:56:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx48M0WBktKRIX+vMYvmzFArb3tD6b/yFhwwD877cZLM2t4N9wPqD9y0/s5q+t/nv6QSbV/V5 X-Received: by 2002:a17:902:8c91:: with SMTP id t17-v6mr2047875plo.182.1524056194001; Wed, 18 Apr 2018 05:56:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524056193; cv=none; d=google.com; s=arc-20160816; b=xSKydBcqzt/pTsnnrU7TFiQaHGvZuoQ4qSRbFYhWan0Z2HHZfOwp16MNi/HRvW6COy KsqTVNCTJfOVe+7mgdQjPp7tvXQYsyvTiZ0dR+d6PUiJ1HhRfqdA965ALVyDhXrguG8S IKd1v8YfxiXahrtZ3WY0JZD2GydLUSxcV9DJrT0VTKxKsN+O4wbNxRzqLZbljGAGXqW9 i54CDP87UBy8SSEWBdwiwK9S0Fl83cZnN0nIx4PsII+bjGOEe9xvYMbO+5SzuSEO6KLQ HCrB+CWNCQ1n5SUzpq+u6A4gHOfN2OGmMEWP2j3CUYNFPQUSgLrSP96G6a6QK4NHv5Ty c9xg== 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=NtX9BH3Pv2FM1d27BuyczKsM755TTJY2HfW3ouLKXlU=; b=ApIsmEkR6gzVgt8A1sxQQPwo2dopCz3UeDWqY5YKwuJsbaS5x5qbaPcnA1/xDEvCLq 4y8kvUwvw4OlNC6eCBKYagZkal+0h0nGfv/w7WRvr/GTv/cY+QrFS7VjCWvrGoRUh0gz a3hOunxIM4aOTWcoZM87jChjO4sHbudBzPS3VYDRBzol5/51v53wKjKpq3Fe+B6Lokam XuBnF/El6gbufP5ofAsW9XQlPDTZkDTXOpace+1qffO2fJ7sqaQTManW4SIB5BiNlyjy cABi87lXhVdunZceSIRPGDqjStYfnvUXcmjtm7wotcA7+X9uY1R2t3WSKsbx8byXGz5l CYqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=iW6umdST; 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 b61-v6si1192661plc.500.2018.04.18.05.56.19; Wed, 18 Apr 2018 05:56:33 -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=iW6umdST; 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 S1754027AbeDRMyA (ORCPT + 99 others); Wed, 18 Apr 2018 08:54:00 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:44842 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753442AbeDRMx7 (ORCPT ); Wed, 18 Apr 2018 08:53:59 -0400 Received: by mail-wr0-f193.google.com with SMTP id o15-v6so4532233wro.11 for ; Wed, 18 Apr 2018 05:53:58 -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=NtX9BH3Pv2FM1d27BuyczKsM755TTJY2HfW3ouLKXlU=; b=iW6umdSTwTY5CWB2nuGooCVand5KW4/5Rb6YhW55Dm8hb/c2klw42/z25Ld+hL7FmT Bd7G3c+zF1SbzbJuGsHQOGdWOjVSjoNkOJ9myTknwdFd2+5xuCxI51MwoVWbqgc25JbH p4YhuKRfYo3hup+qTb1cVMA1TjGGdpht3wAiA= 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=NtX9BH3Pv2FM1d27BuyczKsM755TTJY2HfW3ouLKXlU=; b=OZiswbgPtYdf6Vtzf+uAPeWaBUAPCySDsnEWifi5Mxt5bzrMbkBrkIU3AGA9R9MOyk UnL+rpW/iDiO7h0GOJnKz+FxO02QnTDrUeaol7QbqfZkKvW9VkviWXY2QFHDj8a1DOpp pHruT6f88nVxn34Tli1hbLpUoZGJIa+DfbUiuNBj/0MyaqgiUqcDMFj7nccO5Dc0UCaz /fK3SXhTXyTGCFlLJzuNhjVHQKk7Qo+ek/YE9liDimERKZ2hL5Vc80rbeVOQypr+3tv1 TVHASI2KiiFWx7/21tfmklxZp3E+GBEZ3/LKwN76j6mKLIeO7JT3zgG4Gdleqz32wCkK mxIQ== X-Gm-Message-State: ALQs6tAJ5cITpeSmnbvGx49j1lQGEtiIyYYMLoNmENfYlngySGSMhn/P WgcllBzOA1pCHmIVtw1qPaQufA== X-Received: by 10.28.146.200 with SMTP id u191mr1759368wmd.115.1524056037810; Wed, 18 Apr 2018 05:53:57 -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 d18-v6sm1114997wre.5.2018.04.18.05.53.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Apr 2018 05:53:57 -0700 (PDT) Subject: Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list To: Alban Cc: linux-kernel@vger.kernel.org, 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> <344e0087-7410-aebb-8a66-c6976064df10@linaro.org> <20180417165420.423a691b@avionic-0020> <8c4b48ad-e99e-030a-a4ee-b6df0fa59c79@linaro.org> <20180417180040.04f53495@avionic-0020> <20180418134119.2e587621@avionic-0020> <9f7d2987-b33e-79b5-ae58-2985fd7334e4@linaro.org> <20180418143243.3c23493c@avionic-0020> From: Srinivas Kandagatla Message-ID: Date: Wed, 18 Apr 2018 13:53:56 +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: <20180418143243.3c23493c@avionic-0020> Content-Type: text/plain; charset=windows-1252; 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 18/04/18 13:32, Alban wrote: >> I was also suggesting you to use nvmem-cell subnode, but make it a >> proper nvmem provider device, rather than reusing its parent device. >> >> You would end up some thing like this in dt. >> >> flash@0 { >> #address-cells = <1>; >> #size-cells = <1>; >> compatible = "s25sl064a"; >> reg = <0>; >> >> nvmem-cells { >> compatible = "mtd-nvmem"; >> #address-cells = <1>; >> #size-cells = <1>; >> >> calibration: calib@404 { >> reg = <0x404 0x10>; >> }; >> }; >> }; > But the root cause is in the nvmem binding, this conflict could exists No, the root cause is because of passing wrong device instance to nvmem core. And trying to workaround is the actual issue. > with any device type, not just MTD. I don't understand why we would want > such workarounds instead of just fixing the problem once and for all. AFAIU, This is not a workaround, this is how nvmem provider bindings are and all providers should try to follow it. I still do not understand what is the issue in making nvmem-cells node a proper nvmem provider device? --srini