The TF-A project uses the OpenCI project https://www.trustedfirmware.org/projects/open-ci/ to provide "Daily" and "Gerrit patch review" testing through a Jenkins infrastructure system with jobs visible here https://ci.trustedfirmware.org and these make use of tests defined in the TF-A Tests repository and from other reposititories. Please refer to the OpenCI documentation for more information https://tf-ci-users-guide.readthedocs.io/en/latest/

Given that there's no activity to get the submission rule issues in 9990 resolved, I followed CJKay's and jwerner's instructions and made https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10415, hopefully more ready for inclusion.

FYI I removed the previous SPAM comment.

Thanks, I submitted the following based on CJKay's patch above:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9990

The problem has been solved.

Yes, the __sramdata in the declaration is a mistake, the correct target section for that global needs to be .pmusram.data. This used to be in .sram.data once upon a time but then the suspend.c stuff got added and required it to be moved to PMUSRAM. I guess they forgot to update that part in the declaration and since the old GCC seemed to silently prefer the attribute in the definition, nobody noticed. Please apply CJKay's first patch to fix the warning.

I can only assume GCC <11 simply didn't have this warning, but it looks legitimate.

Ok thanks.

It's native aarch64, the command line I'm using is:
make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" PLAT=rk3399 bl31

Is this building natively on arm64 host?

I'm using Fedora 34/35 with the distribution toolchain (gcc 11.1 GA)

Can you please provide the link to the gcc11 toolchain you use?
AFAIK latest public Arm release of the cross compiler toolchains is 10.2 (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads)

Hi all, I suggest we move this discussion back to the mailing list so we can track the progression a bit more easily.

Vote: Jens Wiklander (qemu and OP-TEE Dispatcher): disapprove
I too have concerns with adding more tags to the the subject of the commit message.

We have had some contact with some other TF.org projects but was not aware of the Mbed TLS project had its own solution already. Its already acknowledged we should to look for a common solution across projects. This discussion is part of that engaging. We do need to make a decision at some point.

Hi, I agree with @danh-arm. We should try to come up with a unified guidance, if possible. I think we will have a better idea of the path forward, once most of the maintainers respond. Personally, I would be open to merging both approaches to get the best of both worlds.

I think tags in the subject of the commit message are problematic in general. Since commits are expected to capture "logical unit of change", the granularity of tags and commit scope often mismatches. While not mandated in the "Contributors Guide" sections, some commits indeed use tags already (i.e. libc, spmd, docs, etc..). What if a "logical unit of change" affects multiple components (i.e. a fix affects both libc and spmd)?

Hi, I just want to make you aware that the Mbed TLS project has a different, home-rolled solution to this problem:
https://github.com/ARMmbed/mbedtls/blob/development/ChangeLog.d/00README.md

Yes, I have found that 50 chars is not enough to describe commits many times. Adding a tag would mean sacrificing space. But I am open to adding this tag to the commit message instead of the header. We already plan to add tags to the message anyways?

I think this is generally a good move. The transition period will be ugly and unavoidable but we should reap the benefits of it long term. I do agree with Varun's concern about using tags in the headers but it is a trade-off we will have to make for the benefits standard commits offers.
Varun, is the format <conventional commit tag>:<plat> or <submodule>:<short message> not sufficient? I dont think we want to pack too much into the header any way in terms of what the commit is doing.

Vote: <Varun Wadekar> (<Tegra>): <disapprove>

Hi,
A developer submitted a patch which closely relates to this issue. Please give your feedback here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7314

Hi,
Please use personal email and git configs/identity to push the patch to trustedfirmware.org. Few developers from the tf-a community have done this. Here is a link to contribution guidelines:

Thanks for your reply. It is difficult to submit code to community or Gerrit using company's account and system. So, I wonder whether it's permitted to upload by providing modifications or “git send-email” with patches.

Hi,
Yeah, looks like such a large system with numerous clusters will run into an issue with the current limitation of "lock_index" being "unsigned char". Please go ahead and submit a patch for review:

Yes, The power domain topology of the system can be described as 8 sockets, each socket with 10 clusters and each cluster with 8 cores. We just consider a system like this might face the constraint mentioned above, and we must modify the declaration of lock_index to solve this problem. Feature, more and more interconnected system, with numerous cpus, might face the same problem.

Hi,
The struct "non_cpu_pwr_domain_node" represents a non-leaf power domain in an SoC such as a logical cluster. As you mentioned, the lock_index declaration with "unsigned char" limits such non-cpu power domains to 64. I believe it doesn't restrict the number of CPUs in a system to be <= 64. Do you currently face an issue with PSCI implementation due to the above constraint? Can you advise what is the power domain topology of your system? I think the lock_index can be expanded using "unsigned int" if needed.