[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zl2NMG3NdQHPfe7s@google.com>
Date: Mon, 3 Jun 2024 09:30:24 +0000
From: Tzung-Bi Shih <tzungbi@...nel.org>
To: Ben Walsh <ben@...nut.com>
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
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?
> @@ -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?
Powered by blists - more mailing lists