Change for this is available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1562

Hi, PSA header files in mbedCrypto and TFM have the same names but a different content.
Guess, if they have the same names and the same path, they should to have the same content or to have a different prefix.

Hi @AndreyButokNXP ,

the only common difference in the headers is the different license used by the headers distributed by TF-M and the ones distributed by Mbed Crypto.

There are differences in headers which are allowed to be platform or implementation specific by the PSA Crypto API specification (i.e. crypto_struct.h, crypto_extra.h, crypto_platform.h, for example), but this is expected as these headers are implementation specific, and moreover they are private (the only public header that has to be included from applications is psa/crypto.h). This is all explained in the headers themselves for more details.

It's probably OK when to compile in multiple libraries. The problem happens when to compile sources of MbedCrypto and TFM in one project.
So, as workaround, we have to add psa_ prefix to TFM PSA headers (as it was done in previous version of TFM).

The expected use case is that an application will have to use a single implementation of the PSA Crypto interface at a time, so there won't be any conflict. In this case the module of the application will just "#include psa/crypto.h" as main header.

Symbol prefixing/renaming will always be needed to avoid clashing at link time if more than one implementation is available/visible for the same application. For this reason, a use case to support including PSA Crypto headers from different implementations in the same application is not planned.

It means that you have decided to add the limitation which is possible to avoid.
It is possible to have and compile TFM, MbedCrypto and PSA test suite without splitting to separate libraries/projects.

Not sure what is your use case, but I don't see how it's possible to compile Mbed Crypto and TF-M Crypto as part of the same application without doing symbol renaming of one of the two, given that they export the same symbol names. So I assume you have some way of renaming the symbols of either of the two before compilation, or excluding one of the two at link time.

In this case, anyway, the natural thing to do would be to keep the headers of each implementation under a separate include tree, and you application can make sure it includes *explicitly* the headers of the implementation it wants, i.e. "#include "tfm/psa/crypto.h"" or "#include "mbedcrypto/psa/crypto.h". Maybe your problem raises from the fact that you have placed all the headers that you need to include at any time under the same folder without separation, but this is not good programming practise to mix and match headers of different implementations in the same location.

Symbol renaming is OK.
But I have talked about file names, to avoid conflict when TFM and MbedCrypto referencing to "psa/<same_name.h>".
Guess, using a different include directory e.g. "psa_tfm/<same_name.h>" may solve the issue.
P.S. Different headers files should have different names and path - good practice for any use case.

There is no conflict anywhere in the header names of the TF-M project. Your use case is to have both Mbed Crypto and TF-M as part of the same IDE project, at that point is up to you to provide a clear separation of the different include trees of Mbed Crypto and TF-M, and not rely on the fact that having the same names they will have same contents, as they are two different implementations of the same interface, coming from two different projects and not distributed together (i.e. they have different paths by design).

It looks like there is no conflict, but it is ;)
TFM and MbedCrypto referencing to "psa/<same_name.h>" which are placed in different directories.
But if both sources belong to the same project, the project must contain both include paths .
It is a luck what path is taken the first one in the search path list.
If no luck, you will get compilation errors as some structure types have an unexpected content.

On this moment, the issue has been solved by adding prefix (on our side).
This issue is not yours as you are using the different approach, so up to you if you have a will to solve it on your side.

As explained above, this is not an issue as if a user project needs to include for some reason more than one implementation of the same PSA crypto interface, it's up to the user to provide a separation of the include trees.

The separation of trees does not help without changes in original code.
#include "psa/<same_name.h>" will reference to different versions of file (in case two library sources are in one project) .
The only way to solve it, is to change #include "differen_name_or_path" (our solution), or compile and use MbedCrypto as a separate library (your solution).
Adding a file prefix or changing of the "psa" sub-folder name to something different, will solve the file name conflict.