linux-kernel - Re: [PATCH] memory: fsl_ifc: Make FSL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 28 May 2024 12:21:02 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Esben Haabendal <esben@...nix.com>
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

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.


> 
>> 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.


Best regards,
Krzysztof