I think that we shouldn't implement these APIs.

Looking at the core we can see that the builtin implementation of the functions:
psa_key_derivation_input_bytes
psa_key_derivation_output_bytes

In the lower level is using the psa_driver_wrapper calls for the hmac functionality needed. (I don't need to discuss about the input_key and output_key APIs since they are similar).

For example the key derivation for HKDF has the following (simplified) call graph:

psa_key_derivation_input_bytes

-> psa_key_derivation_input_internal
    -> psa_hkdf_input
        -> psa_key_derivation_start_hmac
                     -> psa_driver_wrapper_mac_sign_setup
        -> psa_mac_update
                     -> psa_driver_wrapper_mac_update
        -> psa_mac_sign_finish
                     -> psa_driver_wrapper_mac_sign_finish

psa_key_derivation_output_bytes

->psa_key_derivation_hkdf_read
    -> psa_key_derivation_start_hmac
            -> psa_driver_wrapper_mac_sign_setup
    -> psa_mac_update
            -> psa_driver_wrapper_mac_update

Since CryptoCell does not actually support HKDF in the hardware level I think that it makes sense keep the builtin implementation for this and let the driver_wrapper calls call the hardware eventually. There is an implementation of the hkdf in the CryptoCell stack (in the file cc_hkdf.c) but this implementation uses the same logic as the PSA core, it implements in software the HKDF logic and it calls the accelerated HMAC hardware driver underneath. As such there is no major advantage of calling the functions from the CryptoCell stack instead of the PSA core functions apart from a slightly smaller number of invoked function calls. Adding the driver in CC3XX scope increases the code size and the maintenance time without any major advantage so we should not implement it in my opinion.