[PATCH 1/2] imx6dl-sielaff: Convert to OF_UPSTREAM

Frieder Schrempf frieder.schrempf at kontron.de
Tue Jul 22 11:14:55 CEST 2025


Am 21.07.25 um 15:27 schrieb Quentin Schulz:
> Hi Frieder,
> 
> On 7/21/25 3:08 PM, Frieder Schrempf wrote:
>> Hi Quentin,
>>
>> Am 21.07.25 um 15:01 schrieb Quentin Schulz:
>>> Hi Frieder,
>>>
>>> On 7/21/25 2:51 PM, Frieder Schrempf wrote:
> [...]
>>>> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/
>>>> Kconfig
>>>> index 465e258f8e4..0798eac68f5 100644
>>>> --- a/arch/arm/mach-imx/mx6/Kconfig
>>>> +++ b/arch/arm/mach-imx/mx6/Kconfig
>>>> @@ -366,6 +366,7 @@ config TARGET_MX6S_SIELAFF
>>>>           select DM_THERMAL
>>>>           select SUPPORT_SPL
>>>>           imply CMD_DM
>>>> +       imply OF_UPSTREAM
>>>
>>> Why "imply" only here? It won't build without OF_UPSTREAM anymore no?
>>> Shouldn't it be "select" instead?
>>
>> Good question. I wasn't sure about this, either. But "imply OF_UPSTREAM"
>> is used basically everywhere in the tree whereas "select OF_UPSTREAM" is
>> only used twice. That's why I assumed there must be some good reason to
>> use imply. Maybe that assumption was wrong, but I still wonder why
>> everyone uses this. If someone can explain, that would be appreciated.
>>
> 
> I can explain for the Rockchip architecture :)
> 
> We have "imply OF_UPSTREAM" at the *SoC* level so that if someone
> somehow wants to be able to have their board to NOT use an FDT from dts/
> upstream, it is possible (though we wouldn't accept such a patch, so
> this is likely only to be nice with forks or also inherited from partial
> migration of U-Boot FDTs to upstream's (e.g. there is px30-firefly which
> doesn't have an upstream Device Tree, so we cannot move CONFIG_PX30 to
> select OF_UPSTREAM as there are still boards which aren't supported)).
> Finally, we actually make use of this ability to not use upstream DT for
> generic Rockchip platforms. While I don't use this, it seems like it is
> appreciated? We cannot upstream those as they do not represent any real
> HW but it works good enough for boards following closely the reference
> design from Rockchip (which is most boards for typical things used by U-
> Boot to boot Linux like eMMC/SD/SPI).
> 
> For Kconfig symbols only tackling a finite number of boards which are
> all supported by OF_UPSTREAM, it would make more sense to have "select"
> there? We also have "generic" Device Trees for Rockchip boards that we
> cannot upstream to the Linux kernel (as they don't match any actual HW)
> so we need

Thanks for elaborating!

That makes a lot of sense. And for this case where we have a single
board and nothing that will ever be derived from this, "select
OF_UPSTREAM" or moving it to the defconfig is probably more suitable.

> 
> And now to come to think of it, I believe most/all the options in
> TARGET_MX6S_SIELAFF should be in the defconfig instead of under the
> Kconfig symbol? Not sure if there's a tree-wide consensus on what to do
> here, or if it's up to the architecture's maintainer or board maintainer
> to decide. I know the additions I made to the Kconfig in board/
> theobroma-systems/ weren't much liked at the time (but ultimately still
> merged), and this seems similar, so not sure?.

I'm not sure, either. But as this affects the i.MX boards in general I
would rather like to leave that decision to a maintainer and do cleanups
later once there is a consensus.

I think I will send a v2 with CONFIG_OF_UPSTREAM in the defconfig and
leave the KConfig untouched for now.



More information about the U-Boot mailing list