[PATCH 1/2] fsl-layerscape: add dtb overlay feature

[Michael Walle]

Hi Sahil,

Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS):
> Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS):
>>> Could you please add some description what this is doing and for what
>>> this is intended? To have a "DTB overlay feature", it is enough to
>>> just enable CONFIG_OF_LIBFDT_OVERLAY.
>> I will add some description, and yes for DTB overlay feature, it is
>> enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step
>> before booting the kernel that's why also have to enable
>> CONFIG_OF_SYSTEM_SETUP.
> 
>> Ok. What will the overlay do? Could you give an example?
> This overlay will be disabling the crypto nodes which will be used by
> optee in secure world, so that linux should not use it.
> 
> 
>>> Apparently you're adding an overlay passed by optee. Doesn't this
>>> have to be applied to u-boot's control dtb too?
>> Yes, we will be applying the overlay passed by optee, yes it will be
>> applied to dtb which will be passed to uboot for kernel booting.
> 
>> If I read this patch correctly, you're modifying the DT before you 
>> jump to linux. But I was asking whether you also have to modify the DT 
>> which is used by u-boot. Eg. if you disable some kind of crypto nodes 
>> (because optee will use them in secure world), this also have to 
>> communicated to u-boot, not only linux, no?
> Yes, I got your point now, and is very valid, but as of now for u-boot
> we are just using the first available node for communicating with CAAM
> leaving other job rings as it is.
> So we need not to apply overlay to DTB used by uboot.

But we should do the correct thing, so that u-boot and linux
doesn't see a different version of the device tree.

Also what do you mean with "the first available node"?
There is already a new CAAM driver for u-boot pending,
see
https://lore.kernel.org/u-boot/20211115070014.17586-1-gaurav.jain@nxp.com/

-michael