linux-kernel - Re: [PATCH v2 1/5] platform/chrome: cros_ec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87le3l25gk.fsf@jubnut.com>
Date: Mon, 03 Jun 2024 20:26:19 +0100
From: Ben Walsh <ben@...nut.com>
To: Tzung-Bi Shih <tzungbi@...nel.org>
Cc: Benson Leung <bleung@...omium.org>, Guenter Roeck <groeck@...omium.org>,
 "Dustin L. Howett" <dustin@...ett.net>, Kieran Levin <ktl@...me.work>,
 Thomas Weißschuh <linux@...ssschuh.net>, Mario Limonciello
 <mario.limonciello@....com>, chrome-platform@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] platform/chrome: cros_ec_lpc: MEC access can
 return error code

Tzung-Bi Shih <tzungbi@...nel.org> writes:

> On Mon, Jun 03, 2024 at 07:38:30AM +0100, Ben Walsh wrote:
>> @@ -425,8 +469,8 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
>>  	 */
>>  	cros_ec_lpc_ops.read = cros_ec_lpc_mec_read_bytes;
>>  	cros_ec_lpc_ops.write = cros_ec_lpc_mec_write_bytes;
>> -	cros_ec_lpc_ops.read(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, 2, buf);
>> -	if (buf[0] != 'E' || buf[1] != 'C') {
>> +	ret = cros_ec_lpc_ops.read(EC_LPC_ADDR_MEMMAP + EC_MEMMAP_ID, 2, buf);
>> +	if (ret < 0 || buf[0] != 'E' || buf[1] != 'C') {
>
> Slight concern: if the read failed (-EBUSY, because of the lock contention
> failed for example), does it still need to probe for non-MEC devices?

That's a very good point! Negative ret here means there's really an
error, not just "no MEC".

I think it's better to return early with the return code (not -ENODEV)
in these cases.

>> @@ -436,9 +480,9 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
>>  		/* Re-assign read/write operations for the non MEC variant */
>>  		cros_ec_lpc_ops.read = cros_ec_lpc_read_bytes;
>>  		cros_ec_lpc_ops.write = cros_ec_lpc_write_bytes;
>> -		cros_ec_lpc_ops.read(ec_lpc->mmio_memory_base + EC_MEMMAP_ID, 2,
>> -				     buf);
>> -		if (buf[0] != 'E' || buf[1] != 'C') {
>> +		ret = cros_ec_lpc_ops.read(ec_lpc->mmio_memory_base + EC_MEMMAP_ID, 2,
>> +					   buf);
>> +		if (ret < 0 || buf[0] != 'E' || buf[1] != 'C') {
>>  			dev_err(dev, "EC ID not detected\n");
>>  			return -ENODEV;
>
> Similar concern here: should `ret < 0` see as a -ENODEV?

As above, I think it should "return ret".