Regression in TF-A installed/deployed artifacts

Hi,

I believe there's been a regression since commit 7bce36a2c64b 
("arm/trusted-firmware-a: Use firmware.bbclass") where the installed 
name isn't bl31-<platform>.elf anymore, but simply bl31.elf.

This commit removed -${TFA_PLATFORM} from the installed firmware 
filename (and the symlink). The commit log seems to hint that this was 
intended "Drop the redundant ${TFA_PLATFORM} suffixes."... which isn't?

Changing TFA_INSTALL_SUFFIX to the value of TFA_PLATFORM (it currently 
is the empty string) would help with that but then you either have 
bl31.elf or bl31-rk3399.elf (for example). I don't mind about that, but 
still odd to remove a symlink.

meta-rockchip has support for TF-A binary blobs from Rockchip, which we 
do name bl31-rk3399.elf and since this filename needs to be consistent 
between upstream tf-a and blob tf-a (and we cannot modify U-Boot's BL31 
variable from TF-A's recipe due to variable scope), this broke builds of 
meta-rockchip and forced the following (yet incomplete) band-aid patch 
https://git.yoctoproject.org/meta-rockchip/commit/?id=2a13a49da4af4487ee71db6aff19364220da694a. 
I'm now trying to figure out how to properly fix that.

Additionally, the binaries are now forced into a subdirectory named 
after the recipe (see do_deploy in firmware.bbclass) and cannot be 
modified. So I need to patch our TF-A blob recipe to install in the 
identically named directory (that is, trusted-firmware-a/) so that 
U-Boot can find the binary named the same in the same location 
regardless of the kind of TF-A we're building. It does feel kinda wrong 
doing that.

Maybe you can explain the rationale behind those choices? And what's the 
best course of action for meta-rockchip?

Thanks!
Quentin