Date: Tue, 28 May 2024 13:01:17 +0200
From: Esben Haabendal <esben@...nix.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>,  Pratyush Yadav
 <pratyush@...nel.org>,  Michael Walle <mwalle@...nel.org>,
  linux-kernel@...r.kernel.org,  linux-mtd@...ts.infradead.org
Subject: Re: [PATCH] memory: fsl_ifc: Make FSL_IFC config visible and
 selectable

Krzysztof Kozlowski <krzk@...nel.org> writes:

> On 28/05/2024 12:03, Esben Haabendal wrote:
>> Krzysztof Kozlowski <krzk@...nel.org> writes:
>> 
>>> On 27/05/2024 09:47, Esben Haabendal wrote:
>>>>
>>>> Ok, I seem to still be confused as to what you want from me. If you are
>>>> saying that the kernel is not supposed to care about out-of-tree DTS
>>>> (and thereby any bootloader provided DTB), I would like to bring your
>>>> attention to arch/arm/boot/dts/nxp/ls/ls1021a-twr.dts in upstream:
>>>>
>>>> &ifc {
>>>>         #address-cells = <2>;
>>>>         #size-cells = <1>;
>>>>         /* NOR Flash on board */
>>>>         ranges = <0x0 0x0 0x0 0x60000000 0x08000000>;
>>>>         status = "okay";
>>>>
>>>>         nor@0,0 {
>>>>                 #address-cells = <1>;
>>>>                 #size-cells = <1>;
>>>>                 compatible = "cfi-flash";
>>>>                 reg = <0x0 0x0 0x8000000>;
>>>>                 big-endian;
>>>>                 bank-width = <2>;
>>>>                 device-width = <1>;
>>>>         };
>>>> };
>>>>
>>>
>>> I don't understand why it took so many emails to answer that (my first)
>>> question...
>> 
>> Because I did not understand the question. Primarely because I was (and
>> is) surprised that out-of-tree DTS is not supported. I was convinced
>> that out-of-tree DTS was the right way for hardware which is not
>> commonly available.
>
> Even some non-GA hardware could, and IMHO should, be upstreamed, at
> least some parts of it. This gives the user/upstreamer reason to do
> changes. Otherwise you might get questions for contributions: why you
> are doing and why this is worth?
>
> Downstream or any fork is not really answer to such questions, because
> they are allowed to make whatever stupid choices they want (not saying
> it was done here, but in general), which should not be a reason to do
> anything upstream. If downstream creates wrong DTS files, shall we
> create wrong device drivers or bindings for them? No.

Of-course not. But to be fair, in this case, there has not been any new
bindings created, and no creative usage of existing bindings. Only
straight forward usage of existing drivers (IFC and physmap MTD driver),
which I am surprised no one else had seen the need to fix in upstream.

But do you/we really want to open the flood gates for DTS maintenance of
a gazillion embedded boards that only a few in the world have an
interest in? I suspect it would create quite a lot of patches to flow
through maintainers, with very litle benefit to most people. But for me
(as in the companies doing such these kind of embedded hardware), it is
a clear benefit to put upstream DTS files.

But what about boards where device-tree is created/modified dynamically
by bootloader? Is that also not really supported?

>>> Sounds good, however you did not update the existing select.
>>> Drivers are not supposed to select user-visible symbols (leads to
>>> issues), so you need to change it to depends and update defconfigs.
>> 
>> Do you wan this split into multiple commits, or a single commit changing
>> the Kconfig to make FSL_IFC user-visible, and changing select of it to
>> DEPENDS, and updating the related defconfig(s)?
>
> One commit for Kconfigs (nand and memory), additional commits for
> defconfigs, one per each arch, because defconfigs might go via arch tree.

Sounds good. I will send a v2 with that.

/Esben

Powered by blists - more mailing lists