[PATCH 00/12] crypto: atmel - refactor common i2c support and add SHA256 ahash support

[Lothar Rubusch]

Hi Thorsten & ML,

On Thu, May 14, 2026 at 9:51 PM Thorsten Blum <thorsten.blum at linux.dev> wrote:
>
> Hi Lothar,
>
> On Tue, May 12, 2026 at 10:43:37PM +0000, Lothar Rubusch wrote:
> > This series restructures the Atmel secure element drivers around a
> > shared atmel-i2c core and adds SHA256 ahash support for ATSHA204A and
> > ECC based devices.
> >
> > The existing drivers duplicated substantial parts of the transport,
> > RNG, EEPROM and device management logic. This series consolidates the
> > common functionality into the shared i2c core and converts the client
> > drivers to capability based allocation.
> >
> > The series also introduces per-device timing configuration through
> > match data, moves sanity checks and RNG handling into the core driver,
> > updates workqueue handling and cleans up internal constants and helper
> > definitions.
> >
> > The final patch adds SHA256 ahash support using the hardware SHA engine
> > provided by the devices.
> >
> > ATSHA204A devices require software-side SHA256 padding according to
> > FIPS 180-4, while newer ECC devices provide a dedicated SHA final
> > command and perform padding internally in hardware.
> >
> > Supporting the SHA engine also requires changes to the command
> > transport path. SHA operations must execute as a strict uninterrupted
> > sequence consisting of SHA INIT, one or more SHA COMPUTE commands and,
> > for ECC devices, a terminating SHA FINAL command. The device loses its
> > internal SHA state if it enters sleep mode or if unrelated commands
> > are interleaved during the transaction.
> >
> > To satisfy these hardware requirements, the send/receive path is split
> > into a low-level transfer helper and a higher-level wrapper managing
> > wakeup, sleep and locking. SHA operations keep the device awake and
> > hold the i2c lock for the full duration of the hashing transaction.
> >
> > The series has been tested on ATSHA204A and ATECC508A devices.
> > Tests are ongoing/pending on ATECC608A and ATECC608B.
> > ---
> > Lothar Rubusch (12):
> >   crypto: atmel - introduce shared I2C client management
> >   crypto: atmel - move capability-based client allocation into i2c core
> >   crypto: atmel - remove obsolete CONFIG_OF guard
> >   crypto: atmel - add per-device timing and match-data driven
> >     configuration
> >   crypto: atmel - move RNG support into common i2c core
> >   crypto: atmel - move EEPROM access support into common i2c core
> >   crypto: atmel - expose CONFIG zone through sysfs
> >   crypto: atmel - move device sanity check to core driver
> >   crypto: atmel - check client data in remove callbacks
> >   crypto: atmel - update workqueue flags and add flush on exit
> >   crypto: atmel - refactor and localize driver constants
> >   crypto: atmel - add SHA256 ahash support
> >
> >  drivers/crypto/atmel-ecc.c     | 252 +++++++-----
> >  drivers/crypto/atmel-i2c.c     | 679 +++++++++++++++++++++++++++++----
> >  drivers/crypto/atmel-i2c.h     | 180 +++++----
> >  drivers/crypto/atmel-sha204a.c | 284 +++++++-------
> >  4 files changed, 1010 insertions(+), 385 deletions(-)
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch at gmail.com>
>
> Thanks, but I'm not sure reviewing such a large series is sustainable.
> I've only skimmed it, but it also mixes several different things that
> should probably be submitted separately (e.g., refactorings and new
> features).
>

No problem at all. Pls, understand my series as a proposal.

Usually I'm testing the features and use checkers. So, the series is
supposed to be functional. Anyway, there are quite some changes, which
individually need to be analyzed and well understood to get this into
"maintainable" quality, which is definitely not the case yet. I agree.

Having said that, I'd propose to separate out the first, say, 3 patches.
(AFAIK patch #3 is +/- something, you already presented, too, so I assume
it disappears by rebasing soon). I'll split up these initial patches,
do smaller steps, and come up with this series the next days.

Pls, let me know what you think. Would this be better for a review?


> Sashiko [1] also reviewed the series and found potential regressions
> that might be helpful to consider.
>
> Thanks,
> Thorsten
>
> [1] https://sashiko.dev/#/patchset/20260512224349.64621-1-l.rubusch%40gmail.com

Fascinating! Thank you so much for pointing this out!
I'll try to take sashiko comments into account. Sashiko was new to me.
I'll definitely
have a look into it, either reviews or if there is a chance to set it
up locally.

Best,
L