[PATCH] crypto: atmel-sha204a - Fix error codes in OTP reads

[Thorsten Blum]

On 22. Feb 2026, at 18:03, Lothar Rubusch wrote:
> On Sun, Feb 15, 2026 at 9:52 PM Thorsten Blum wrote:
>> Return -EINVAL from atmel_i2c_init_read_otp_cmd() on invalid addresses
>> instead of -1. Since the OTP zone is accessed in 4-byte blocks, valid
>> addresses range from 0 to OTP_ZONE_SIZE / 4 - 1. Fix the bounds check
>> accordingly.
>> 
>> In atmel_sha204a_otp_read(), propagate the actual error code from
>> atmel_i2c_init_read_otp_cmd() instead of -1. Also, return -EIO instead
>> of -EINVAL when the device is not ready.
>> 
>> Cc: stable at vger.kernel.org
>> Fixes: e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp zone")
>> Signed-off-by: Thorsten Blum <thorsten.blum at linux.dev>
>> ---
>> [...]
>> 
>> @@ -106,7 +107,7 @@ static int atmel_sha204a_otp_read(struct i2c_client *client, u16 addr, u8 *otp)
>> 
>>    if (cmd.data[0] == 0xff) {
>>            dev_err(&client->dev, "failed, device not ready\n");
>> -               return -EINVAL;
>> +               return -EIO;
> The cmd.data holding 0xff here is not a bus error. AFAIR it can have
> to do with the locking state, pre-initialization,
> typically the atmel watchdog kicked in / timeout, etc - so the
> response is invalid, although hardware connection (I2C) is
> supposed to work. Currently the caller of this function does not
> distinguish anyway.
> 
> But why is EIO preferable here, over EINVAL?

AFAIK, -EINVAL is used for invalid arguments or bad input passed by the
caller, which is why the address range check returns -EINVAL.

-EIO signals an I/O error or communication failure, e.g., the caller
passed a valid address, but the device isn't ready yet, for whatever
reason. Maybe -EAGAIN or -EBUSY instead? -EIO seemed like the most
reasonable choice to me.

Since the error code will be propagated by my other patch [1], now would
probably be a good time to adjust it.

Thanks,
Thorsten

[1] https://lore.kernel.org/lkml/20260216074552.656814-1-thorsten.blum@linux.dev/