- 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.
- 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.