Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2225546pxa; Mon, 17 Aug 2020 04:35:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyilxV1w/Q0dO0w63sfqPVVvzgoBG83VC2zxR+Ms3L5LwE/4wQhR/pZcfqr7hph+YF+goAh X-Received: by 2002:a17:906:c1d8:: with SMTP id bw24mr14457964ejb.91.1597664158889; Mon, 17 Aug 2020 04:35:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597664158; cv=none; d=google.com; s=arc-20160816; b=pf+MTR5zhwCABMncbJOk00Rmc4xdhGOsIIG8BBVR4s+GKFUKw9iBObUQyop5oH245X WCU7YjImyf51NHbfjP0t372O6C794C8AZr15/5uPJk7tD2J5la1WM+b/fkDOAPgt8X+M 7/oLeO6E5hGpaN3DnXHLoF+PVoty4AQtMjpbS6ed4pPm7Vdcnre4bYYO2De8dVuF6NzY q+slB0rdydwIpQSVW3tqbb0IeODhDBYtDJMFqV74rPSIWaYKh5ouM2DLrDav68CM3DZI sbhXX8DzJ0u/CIiOcicilGHvBQtUjiL/oyIfu9OjnE8oxW0Y7UqnGfai8WmvDRSTSSoe fHPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=9Zq1v1/z4TgIK4zk1TE7HRQw9jTMEcPvQ9uPlVQFYx0=; b=GIMIYNefxxxBLBoWFFwuzqIxrr/TF+4MIeNY+OjsveIEvbNLEOFURxgY0Es7ApNjE1 GL1HL6IZPhCM+6auIN9wEm0/JUyPkeHRaKN9VEEVG0wKQBXBmU5ptd9HiNy+WGYB9Buo 4lj05KLKbr2W+7pFX6U3aaR7q+ZRS3FRXngDMM0mf8Pm1dsqIHbVUMGm1NtHB2hA/E7o 3JpATCC5t4hs19dB68Ll/V2iuidhpRwedRx+U05FZMUYD8mvpWhn64jsTP+JGaZRZo9f AQVa24XWFZO1h8n1xwavB3/hNhxKW7xlzf6m2fnESQH2+36pGgZga7AtKlTkeZApLoKq TxUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s26si10819597ejv.28.2020.08.17.04.35.35; Mon, 17 Aug 2020 04:35:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728450AbgHQLbS (ORCPT + 99 others); Mon, 17 Aug 2020 07:31:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728168AbgHQLbL (ORCPT ); Mon, 17 Aug 2020 07:31:11 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B80FDC061389 for ; Mon, 17 Aug 2020 04:31:10 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: eballetbo) with ESMTPSA id 6D12728DA67 Subject: Re: [PATCH v2 2/2] platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK To: Brian Norris , Benson Leung , Guenter Roeck Cc: linux-kernel@vger.kernel.org References: <20200724190841.3112365-1-briannorris@chromium.org> <20200724190841.3112365-2-briannorris@chromium.org> From: Enric Balletbo i Serra Message-ID: <6c200c61-209f-eb76-88b6-16491e2bc69c@collabora.com> Date: Mon, 17 Aug 2020 13:31:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200724190841.3112365-2-briannorris@chromium.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Brian, On 24/7/20 21:08, Brian Norris wrote: > As with cros_ec_cmd_xfer_status(), etc., it's not enough to simply check > for the return status of send_command() -- that only covers transport or > other similarly-fatal errors. One must also check the ->result field, to > see whether the command really succeeded. If not, we can't use the data > it returns. > > The caller of cros_ec_get_host_event_wake_mask() ignores this, and so > for example, on EC's where the command is not implemented, we're using > junk (or in practice, all zeros) for our wake-mask. We should be using a > non-zero default (currently, it's supposed to be all-1's). > > Fix this by checking the ->result field and returning -EPROTO for > errors. > > I might label this as fixing commit 29d99b966d60 ("cros_ec: Don't signal > wake event for non-wake host events"), except that this fix alone > actually may make things worse, as it now allows for a lot more spurious > wakeups. The patch "platform/chrome: cros_ec_proto: ignore battery/AC > wakeups on old ECs" helps to mitigate this. > > Signed-off-by: Brian Norris Sorry for late notice. The patch has been applied for 5.9. > --- > v2: > * EOPNOTSUPP, not ENOTSUPP > --- > drivers/platform/chrome/cros_ec_proto.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c > index e93024b55ce8..31ca0af62388 100644 > --- a/drivers/platform/chrome/cros_ec_proto.c > +++ b/drivers/platform/chrome/cros_ec_proto.c > @@ -208,6 +208,12 @@ static int cros_ec_get_host_event_wake_mask(struct cros_ec_device *ec_dev, > msg->insize = sizeof(*r); > > ret = send_command(ec_dev, msg); > + if (ret >= 0) { > + if (msg->result == EC_RES_INVALID_COMMAND) > + return -EOPNOTSUPP; > + if (msg->result != EC_RES_SUCCESS) > + return -EPROTO; > + } > if (ret > 0) { > r = (struct ec_response_host_event_mask *)msg->data; > *mask = r->mask; > @@ -488,6 +494,13 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev) > BIT(EC_HOST_EVENT_BATTERY_CRITICAL) | > BIT(EC_HOST_EVENT_PD_MCU) | > BIT(EC_HOST_EVENT_BATTERY_STATUS)); > + /* > + * Old ECs may not support this command. Complain about all > + * other errors. > + */ > + if (ret != -EOPNOTSUPP) > + dev_err(ec_dev->dev, > + "failed to retrieve wake mask: %d\n", ret); > } > > ret = 0; >