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.
