[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Dec 2022 20:57:49 +0300
From: Maxim Kochetkov <fido_max@...ox.ru>
To: Miquel Raynal <miquel.raynal@...tlin.com>,
Maxim Kiselev <bigunclemax@...il.com>
Cc: Thorsten Leemhuis <regressions@...mhuis.info>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
Vignesh Raghavendra <vigneshr@...com>,
Richard Weinberger <richard@....at>,
Rafał Miłecki <rafal@...ecki.pl>,
"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Saravana Kannan <saravanak@...gle.com>
Subject: Re: nvmem-cells regression after adding 'call of_platform_populate()
for MTD partitions'
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.
Powered by blists - more mailing lists