saves ~2KB of code size and can be disabled at build time.

RFC7539 tests for verification as part of the TF-M regression test suite: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/14551

Poly1305 multipart support in the low level driver: https://review.trustedfirmware.org/q/topic:%22poly1305_multipart%22+(status:open%20OR%20status:merged)

Hi Yuezhiran,
We are following this up internally. Could you please let us know what revision of Helios you have and whether you run linux? (Linux doesn't work around any Helios errata currently)

As I understand it from the white paper (v1.6) from developer.arm.com there is research ongoing for the mitigation sequence for the Cortex- A65. Once known I believe TF-A reference mitigation patches will be developed.

I notice that relevant patches have been merged into the mainline branch except A65. will it be uploaded recently ?

Reference implementations of mitigations in TF-A for vulnerabilities in various CPU's were initially made available for public review in Gerrit. These have now after the opportunity for feedback been merged into the mainline branch.

I disabled user ericjonz and deleted his malicious comment. Thanks for bringing to our attention David
don

DO NOT click the link posted by ericjonze.
It is a malicious link.

Working in progress on this. Current low level APIs are not very well versed to be adapted efficiently for multipart cases. I am studying the algorithms first before defining a strategy to implement the multipart APIs and eventually (maybe) rework the low level driver API as well

Hi Ross, following changes were merged which help building on Arm and integrating to Yocto. Let us know how it goes. Thanks.

Hi @yuezhiran, I believe it's valid for this function to return 0. The bl1_plat_handle_post_image_load function is overridable by the platform, but we do not provide a mechanism for the platform to communicate the "acceptable" image IDs to the caller. We cannot therefore return an error if we receive an image ID that has no post-load process, because it may be called for any image (the FWU process does this here).

Ok, thanks a lot.

Have you tried a more recent release? v2.6 is our latest tagged release or try tip of tree?

I am using Avenger96 and Buildroot and ran into similar issue.

Hi
As you mentioned, req_states will be NULL only if pwrlvl is not valid. However, in my opinion, many checks have been done earlier to the invocation of the function to make sure pwrlvl is valid. See lines 246 and 428 in lib/psci/psci_common.c file. Can you tell if you have noticed any issue in your platform with PSCI library?