> 1. Having a range for TF-A specific SMC's :  Currently we are having internal discussion whether we need a range for this and where exactly it should be (probably a sub-range in std services). Personally i think it's a genuine request, in fact there are few existing functionalities which qualify to be part of this range (PMF/DebugFS) but they are kept as part of Arm SiP.

Yes, a sub-range of "standard" would also work. My main concern is
that it should be easy and low-friction for developers (especially
non-Arm contributors like us who aren't that well-networked to the
teams owning the specs) to add new FIDs there -- e.g. it should just
take a Gerrit CL or Github PR that can be reviewed in a week or two,
not a new revision of the whole SMCCC spec that needs to go through a
dozen committees or however that works.

> 2. SMC to get CBMEM console address: As you mentioned that it is required only once and not-necessarily a runtime use case. Is it possible to implement this using Firmware Handoff mechanism? Considering the specification is almost at final stage and TF-A implementation is likely to happen in not-so-distant future.

Yes, true, it's possible an SMC wasn't the right solution for this in
the first place. Let's continue to discuss that on Gerrit. But even if
we don't end up needing an SMC for this one there's still a general
need to define generic SMCs like that every once in a while for other
things.
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org