Received-SPF: pass (google.com: domain of linux-crypto+bounces-4381-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 24 May 2024 10:58:04 +0300
From: Dan Carpenter <dan.carpenter@linaro.org>
To: l.rubusch@gmail.com
Cc: linux-crypto@vger.kernel.org
Subject: [bug report] crypto: atmel-sha204a - add reading from otp zone
Message-ID: <34cd4179-090e-479d-b459-8d0d35dd327d@moroto.mountain>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello Lothar Rubusch,

Commit e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp
zone") from May 3, 2024 (linux-next), leads to the following Smatch
static checker warning:

	drivers/crypto/atmel-sha204a.c:109 atmel_sha204a_otp_read()
	warn: should this return really be negated?

drivers/crypto/atmel-sha204a.c
    94 static int atmel_sha204a_otp_read(struct i2c_client *client, u16 addr, u8 *otp)
    95 {
    96         struct atmel_i2c_cmd cmd;
    97         int ret = -1;

ret is set to -EPERM here.

    98 
    99         if (atmel_i2c_init_read_otp_cmd(&cmd, addr) < 0) {
    100                 dev_err(&client->dev, "failed, invalid otp address %04X\n",
    101                         addr);
    102                 return ret;

It would be more readable to return a literal.

    103         }
    104 
    105         ret = atmel_i2c_send_receive(client, &cmd);
    106 
    107         if (cmd.data[0] == 0xff) {
    108                 dev_err(&client->dev, "failed, device not ready\n");
--> 109                 return -ret;

atmel_i2c_send_receive() either returns zero on success or a negative
kernel error code or a positive error code from error_list[].  It really
doesn't work to mix them like this where -EPERM and negative 0x01 could
be confused.

    110         }
    111 
    112         memcpy(otp, cmd.data+1, 4);
    113 
    114         return ret;
    115 }

regards,
dan carpenter