Re: [PATCH] crypto: atmel-i2c - find the bus speed behind an I2C mux

["Marek Behún" <kabel@kernel.org>]

On Mon, Nov 02, 2026 at 06:01:41PM +0100, Josef Schlehofer wrote:
> Hi Marek,
> 
> thanks for the ack and the warning.
> 
> The hwrng core starts a fill thread for the current RNG, whatever its
> quality. It reads 32 bytes every 60 seconds, even when idle.
> atmel_i2c_send_receive() puts the ATSHA204A to sleep after each
> command. That means about 1440 seed updates per day, and 100k cycles
> in about 70 days.
> 
> The ATSHA204A becomes the current RNG when the MCU firmware has no
> TRNG. It also stays current when it registers first, because both RNGs
> have quality 1024. Today the probe fails on the Omnia, so it is safe.
> This patch could wear out its EEPROM within months. It is also marked
> for stable.
> 
> The patch also lets the ATSHA204 on the Turris 1.x probe, as its I2C
> controller has no clock-frequency either. There the talitos hwrng wins,
> because the ATSHA204 has quality 1. Without talitos, the ATSHA204 would
> wear out the same way.
> 
> Should we fix the wear before this patch goes in? Does "proper power
> management" mean the idle command instead of sleep? I can look into
> it.

Yes, basically.

Note that there are two time constants after which the device goes to
sleep mode:
  t_TIMEOUT  (45 to 85 ms) - if I2C bus is inactive the device goes to sleep
  t_WATCHDOG (0.7 to 1.7s) - the device goes to sleep automatically at most
                             t_WATCHDOG time after wakeup, unless put into
			     IDLE mode

If the RANDOM command was the only command the driver is issuing, I would
simply make it so that the device is put to IDLE mode after each command.

But if there are other commands executed, maybe the implementation needs
to be smarter. Depends on the commands.