Hmm, I not sure for the reason for __ASSEMBLY__ instead of __ASSEMBLER__. I don’t see any reason why we shouldn't migrate to the standard macro. This can be done later.
Sounds good, will do that (some time next week).
Yes, that sounds good. I would maybe suggest using "plat" instead of "vendor"
to mirror the way the toplevel directories are structured better, so <share/bl_aux_params/plat/rockchip/plat_params.h> or maybe just <share/plat/rockchip/plat_params.h> instead. But I'm happy to follow
whatever
naming you prefer.
The most difficult part is finding suitable names 😊. How about `include/bl_handoff/plat` and `include/bl_handoff/bl_aux_params/plat` as the folders ?
I think it may be better to branch out the platforms right at the top level of the new namespace this is creating (e.g. include/<...>/plat/bl_aux_params, rather than include/<...>/bl_aux_params/plat), since that mirrors what the repository as a whole does more closely. Also, even if the current use case has both common and platform-specific headers, this may be useful for future use cases that are completely platform-specific, and for those having platform-specific top-level directories would work better.
I also think something generic (e.g. like you earlier suggested 'share') rather than something specific to this use case like 'bl_handoff' would be better, because it's more flexible for future use cases that may also want to do something similar. For example, imagine a platform that writes a data structure to memory or flash which is later parsed by a user space utility, and you want the user space utility to include TF's struct definitions for that rather than duplicate them... this has nothing to do with "bl_handoff", but it would still benefit from shareable headers like this.
That's why I suggested to structure it as 'include/share/plat/rockchip/...' and 'include/share/bl_aux_params/...'. Still, happy to use your scheme if you prefer.