Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <b75a8769-0cc8-beb3-931a-6755aede3af0@inbox.ru>
Date:   Mon, 12 Dec 2022 20:57:49 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: nvmem-cells regression after adding 'call of_platform_populate()
 for MTD partitions'
To:     Miquel Raynal <miquel.raynal@bootlin.com>,
        Maxim Kiselev <bigunclemax@gmail.com>
Cc:     Thorsten Leemhuis <regressions@leemhuis.info>,
        linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Richard Weinberger <richard@nod.at>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <rafal@milecki.pl>,
        "regressions@lists.linux.dev" <regressions@lists.linux.dev>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Saravana Kannan <saravanak@google.com>
References: <CALHCpMgSZOZdOGpLwTYf0sFD5EMNL7CuqHuFJV_6w5VPSWZnUw@mail.gmail.com>
 <CALHCpMgEZjnR39upkR6iozSk-b5A_GHRo9rcDSPXzzQi6x_qCw@mail.gmail.com>
 <b1b7935d-0785-2e57-bad9-ab2476f0acf2@leemhuis.info>
 <CALHCpMhsM2j=bSXEDC9BWYpOAyvCccgJpJmqXfiRTHvp6=y3tA@mail.gmail.com>
 <20221212101449.4e465181@xps-13>
 <CALHCpMimCqZB0bnHaOdCzucey+92NcRRZXCHXYYH5c9vj0nZaQ@mail.gmail.com>
 <20221212173730.64224599@xps-13>
Content-Language: en-US
From:   Maxim Kochetkov <fido_max@inbox.ru>
In-Reply-To: <20221212173730.64224599@xps-13>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi, Miquel!

On 12.12.2022 19:37, Miquel Raynal wrote:

> Let me try to recap the situation for all the people I just involved:
> 
> * An Ethernet driver gets its mac address from an nvmem cell. The
>    Ethernet controller DT node then has an "nvmem-cells" property
>    pointing towards an nvmem cell.
> * The nvmem cell comes from an mtd partition.
> * The mtd partition is flagged with a particular compatible
>    (which is also named "nvmem-cells") to tell the kernel that the node
>    produces nvmem cells.
> * The mtd partition itself has no driver, but is the child node of a
>    "partitions" container which has one (in this case,
>    "fixed-partitions", see the snippet below).
> 
> Because the "nvmem-cells" property of the Ethernet node points at the
> nvmem-cell node, the core create a device link between the Ethernet
> controller (consumer) and the mtd partition (producer).
> 
> The device link in this case will never be satisfied because no driver
> matches the "nvmem-cells" compatible of the partition node.
> 
> Reverting commit bcdf0315a61a ("mtd: call of_platform_populate() for MTD
> partitions") would IMHO not make much sense, the problem comes from the
> device link side and even there, there is nothing really "wrong",
> because I really expect the mtd device to be ready before the
> Ethernet controller probe, the device link is legitimate.
> 
> So I would like to explore other alternatives. Here are a bunch of
> ideas, but I'm open:

How about to create simple driver with compatible="nvmem-cell" and to 
move all the suff from main mtd driver which serves nvmem-cell to the 
probe function?

Thanks, Maxim.