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

[Andre Przywara]

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.