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.j...@nxp.com/
-michael
