Rebased on the common mbedtls config file, still need those fragments especially for MBEDTLS_ECP_NIST_OPTIM but even if that is enabled in the common config file, it's still a good idea for the required board-config to be known (also in the future, need to add options to enable ALT functions).

Rebased on the common mbedtls config file, still need those fragments especially for MBEDTLS_ECP_NIST_OPTIM but even if that is enabled in the common config file, it's still a good idea for the required board-config to be known

I'm not sure about this, about having the options repeated in the board config fragment. The idea of the common mbedtls config file is that all ports and boards behave as similar as possible. This follows the general trend of trying to unify the behaviour of all ports/boards, so users aren't confused why one board works with some feature while another doesn't. Adding custom mbedtls config per board goes against that goal.

We are careful about backwards incompatible changes, so these common mbedtls options will not be easily disabled. If you are concerned about it, maybe it's better to add a test (in tests/net_inet/) which accesses the websites that need to have these mbedtls options enabled? That would be a more robust way of ensuring that the required features exist (eg if one day the TLS library changes to something else).

about having the options repeated in the board config fragment
Adding custom mbedtls config per board goes against that goal.

I can remove the repeated config options (although I think they double as documentation for the board, I can comment them out maybe ?), however there's nothing I can do about the custom mebdtls config options, they need to be turned on/off somehow per-board. I don't think MBEDTLS_ECP_NIST_OPTIM should be enabled unconditionally in the stm32 port, and some of the options can't even be enabled on port level unconditionally, for example if you enable some ALT function you must provide the alternate implementation. So there will always be a need to conditionally enable/disable mbedtls options somehow, including a board config just seemed to fit in with mpconfigboard.h approach.

although I think they double as documentation for the board, I can comment them out maybe

What you really want to document is not these options, but the fact that the board should be able to connect via SSL to a given website. That website may change its security protocol and hence you may need to update the mbedtls options to continue to connect to it. As I said, I think a test is the best way to document this requirement. And a comment in the board config file about needing to connect to a given site would also be fine.

however there's nothing I can do about the custom mebdtls config options

Yes, I agree. So for that I think CFLAGS_BOARD is the way forward, with a custom mbedtls_config.h file for the board that includes the existing mbedtls_config.h file and enables additional things.

Yes, I agree. So for that I think CFLAGS_BOARD is the way forward, with a custom mbedtls_config.h file for the board that includes the existing mbedtls_config.h file and enables additional things.

This is implemented now, but not with CFLAGS_BOARD can you take a look ? I don't think it needs to be any complex than this.

Rebased and merged in efe7dac through ecd4d54 (and I renamed mbedtls_boardconfig.h to mbedtls_config_board.h, to match other names like mpconfigboard.h).