Re: [PATCH v3 2/8] firmware: smccc: Add support for Live Firmware Activation (LFA)

[Andre Przywara <andre.przywara@arm.com>]

Hi Mark,

On 9/18/26 16:28, Mark Rutland wrote:
> On Fri, Sep 18, 2026 at 11:13:19AM +0200, Andre Przywara wrote:
>> On 7/17/26 11:03, Sudeep Holla wrote:
>>> On Mon, Jul 06, 2026 at 03:44:42PM +0200, Andre Przywara wrote:
> 
>>>> +/* A list of known GUIDs, to be shown in the "name" sysfs file. */
>>>> +static const struct fw_image_uuid {
>>>> +	const char *name;
>>>> +	const char *uuid;
>>>> +} fw_images_uuids[] = {
>>>> +	{
>>>> +		.name = "TF-A BL31 runtime",
>>>
>>> This doesn't make any sense to me. Why do you want kernel to assign
>>> some random name base on UUID. Userspace is well place to deal with
>>> UUID and give it any fancy name it wants.
>>
>> Well, the whole interface is quite usable without any accompanying user
>> space tools, so just from the shell, but then identifying  firmware
>> components by their GUID becomes a major pain and leaves users completely
>> clueless.
>> And while we indeed will never be able to fully catch up with all the
>> firmwares out there, especially not with vendor specific ones, there are
>> some standard firmware components that I think warrant some name.
>> TF-A BL31 above (and TF-RMM) are good examples: these GUID is already in the
>> mainline repository, and since BL31 is also an LFA agent, it's quite likely
>> we encounter this component. Even when vendors typically use downstream TF-A
>> ports, those GUIDs would stay the same.
>> So yes, it's more opportunistic than complete, but I think it would help to
>> identify at least those well-known firmwares. Anything not named then would
>> use the GUID, and can indeed be resolved by (a yet-to-be-written) userspace
>> component.
> 
> Sudeep is right; this is not a good idea.
> 
> Remove the table and just expose the UUID of the image. Users can map
> that to a string in userspace if they need/want, and that'll work
> regardless of the vintage of kernel they're using.
> 
> I appreciate it might seem helpful to expose a name where we know it,
> but overall it creates more problems, including (but not limited to)
> compatibility issues, needless busywork to add entries (and arguments
> about what is approriate to add), political issues when some project
> naming changes, etc.

Fair enough, and honestly I was expecting something like this. I just 
wanted to offer some compensation for the spec forcing me to put GUIDs 
on you.
By now I can remember that the TF-RMM GUID starts with "6c", I guess 
that needs to suffice now ;-)

Cheers,
Andre

> I am not going to Ack this with the name present, and I suspect neither
> will Sudeep.
> 
> Mark.