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

[Mark Rutland]

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.

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

Mark.