Copying response on mailing list.

Hi Olivier,

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.

This is a great initiative. Support this completely, although the "Expectation from LTS codebase" section scares me :). Given the size of the community(that i'm aware of), the goals set out are great long term goals so may be it should be renamed as Long term expectations.

I think this looks great.

Thanks guys! The dmbish() is not a huge deal. Just get a little nervous when i see barriers and don't completely understand why it is there. :)

Thanks Paul, Soby.
spm_response_*() currently cannot invoked by any secure partition since the responses[] array is in EL3 space. Is this not the case ? or is it the expectation that the responses array will be mapped to secure EL0 some time in the future? I don't see how a secure partition can invoke spm_response_* other than through an SMC, in which case we are already in EL3 context and dont require the dmbish(), as Paul pointed. I understand your argument for sprt_queue_*, since they are invoked by EL3 and the secure partition.

anything ?

Thanks for taking a look and providing confirmation! :)

Thanks. Missed the lockless reader of the queue. Who is the lockless reader for spm_response_add() and spm_response_get()?