public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Esben Haabendal <esben@geanix.com>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <mwalle@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH] memory: fsl_ifc: Make FSL_IFC config visible and selectable
Date: Tue, 28 May 2024 12:21:02 +0200	[thread overview]
Message-ID: <ccdacf52-1b31-43a1-a8fd-33a252e24d51@kernel.org> (raw)
In-Reply-To: <87y17ul0cb.fsf@geanix.com>

On 28/05/2024 12:03, Esben Haabendal wrote:
> Krzysztof Kozlowski <krzk@kernel.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


  reply	other threads:[~2024-05-28 10:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 13:58 [PATCH] memory: fsl_ifc: Make FSL_IFC config visible and selectable Esben Haabendal
2024-05-23 14:01 ` Krzysztof Kozlowski
2024-05-23 14:32   ` Esben Haabendal
2024-05-23 14:36     ` Krzysztof Kozlowski
2024-05-24  8:47       ` Esben Haabendal
2024-05-25 16:41         ` Krzysztof Kozlowski
2024-05-27  6:55           ` Esben Haabendal
2024-05-27  7:19             ` Krzysztof Kozlowski
2024-05-27  7:35               ` Esben Haabendal
2024-05-27  7:47                 ` Esben Haabendal
2024-05-28  6:53                   ` Krzysztof Kozlowski
2024-05-28 10:03                     ` Esben Haabendal
2024-05-28 10:21                       ` Krzysztof Kozlowski [this message]
2024-05-28 11:01                         ` Esben Haabendal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ccdacf52-1b31-43a1-a8fd-33a252e24d51@kernel.org \
    --to=krzk@kernel.org \
    --cc=esben@geanix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=tudor.ambarus@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox