drivers: eeprom: add support for Microchip ATECC608

[maass-hamburg]

This adds support for the Microchip ATECC608 (and ATECC508) to be used as a eeprom. It also provides a driver to use it as a entropy source.

The code is mainly adapted from the Microchip cryptoauthlib

In the future it might also be extended to be used with the Crypto API.

[maass-hamburg]

ping

[henrikbrixandersen]

The code is mainly adapted from the Microchip cryptoauthlib

Please clarify this statement. The library code referred to is not under the Apache-2.0 license, however the code submitted is.

Was any code copied from the Microchip cryptoauthlib to form this solution?

Would it be possible to instead use the library and create shim drivers in Zephyr?

[carlescufi]

@maass-hamburg from the license in the repo:

Subject to your compliance with these terms, you may use the Microchip Software
and any derivatives exclusively with Microchip products. It is your
responsibility to comply with third party license terms applicable to your
use of third party software (including open source software) that may
accompany Microchip Software.

This license is not OSI-approved, and will never be because it restricts which hardware platforms the code can run on. If you took code that was licensed under this particular license then this is a no-go.

[maass-hamburg]

@henrikbrixandersen @carlescufi ping

[decsny]

default values need justification in the description

[maass-hamburg]

now added

[decsny]

better to say "default value is the minimum according to the datasheet"

[henrikbrixandersen]

Given this some more thought - Have you considered if support for this fits better under drivers/crypto? Similar to drivers/crypto/crypto_ataes132a.c?

The currently proposed driver exposes a lot of custom functionality in its header...

[maass-hamburg]

Given this some more thought - Have you considered if support for this fits better under drivers/crypto? Similar to drivers/crypto/crypto_ataes132a.c?

At the moment my driver only supports the eeprom part and the entropy part, but not the crypto part. I could move it over there, but ATM but it would have any functions of the crypto_driver_api

The currently proposed driver exposes a lot of custom functionality in its header...

Yes, but unfortunately there are currently no general aps for these in zephyr. Like for the One-Time-Programmable Part

x

[maass-hamburg]

@henrikbrixandersen putting it under crypto would result in a dependency loop with the entropy driver.
How about putting it in drivers/mfd? That would be the right place for devices with multiply functions.

[henrikbrixandersen]

@henrikbrixandersen putting it under crypto would result in a dependency loop with the entropy driver. How about putting it in drivers/mfd? That would be the right place for devices with multiply functions.

An MFD driver with an EEPROM driver "child" would be a much better approach, yes.

[maass-hamburg]

@henrikbrixandersen putting it under crypto would result in a dependency loop with the entropy driver. How about putting it in drivers/mfd? That would be the right place for devices with multiply functions.

An MFD driver with an EEPROM driver "child" would be a much better approach, yes.

that is what i have done. Please take a look

[henrikbrixandersen]

These custom API additions are still way too much IMO. The whole idea of a driver subsystem like the one provided by the Zephyr EEPROM API is to be able to abstract the lower-level functionality into a common, portable API. This does the opposite just to make the device fit into the few API functions, it actually supports.