Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7712986ybl; Thu, 16 Jan 2020 04:28:27 -0800 (PST) X-Google-Smtp-Source: APXvYqycQ+07J4R/qXXcupdaoy/SUvCQ9l4w5X397Olh/IK1w3niDgsJqniD72SkBwUc11bVxZSI X-Received: by 2002:aca:503:: with SMTP id 3mr3924038oif.106.1579177707255; Thu, 16 Jan 2020 04:28:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579177707; cv=none; d=google.com; s=arc-20160816; b=dHe57mG2DfOqXjQ8jtUnPZ9Yie6UbbtuwwO3aSffTXhm5s4P58zcl7o3K60XZ9hxxw M00XHUqgL9fDmgZuItCkhkfbV0r4sLExEfR2VqfozTYveh04z42QZQXgoyrx/S+mxFGN fBfLYIz5QFR5bAL1Eo8SVg0iIRp4QBrSXpLK/48kYnjib5bLEcqs1V/+tdIFFMNAfu4V o3+SPvKt7cl3g7zTos3gG5FS5QDjMbup06SYpAFTxSg7idRzmPlky1ZfkyNDiv3gOpVS NZeFCVpDrl+G6f7xI0E8AsXSKALAw3gaWMVMU2iBcVpKivtjD30eC5lmABOavEMMtdsw 2SeA== 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:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=z5/n3LbLSvF9anDAMWP1+9rjDetguqOdEOOOFP3GHsk=; b=KA1hhg0IZxX8eM0bnLvG7DYvLSo3mBmZ30MFTRUXxCQvx+/9tYqnNplus3I4bPfK0X qcBK/KrL1OJxGQsbofcwp3HIZea5PGR4oIxFntdRgp8XkCbvZqCUs8r7KzH0uKgp8T+u yw1gGdGfsV3NINS9xEcmEx/m0giQJqA/EZjY1fqVRk4Qwbh6+Y5zWzU9aCqdEd5rME24 0BXLBYdLbA0VS/jA6giWAeXx2c00llTOhTMcchZDMM2WhnlW+gGMDyI54t1jWD0tGLnc H67kXb2rAUbpdrj9PN/0ADGoDSj5CtC8gQoQ9mnohPqApAIFK0FNcAB0JHSGvyKgIxZ3 lYRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id 38si3617298otu.166.2020.01.16.04.28.15; Thu, 16 Jan 2020 04:28:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1726867AbgAPM1U (ORCPT + 99 others); Thu, 16 Jan 2020 07:27:20 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:57028 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726082AbgAPM1U (ORCPT ); Thu, 16 Jan 2020 07:27:20 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: aragua) with ESMTPSA id 4A52D293CB6 Message-ID: Subject: Re: [PATCH] mfd / platform: cros_ec: Query EC protocol version if EC transitions between RO/RW From: Fabien Lahoudere To: Yicheng Li , linux-kernel@vger.kernel.org Cc: bleung@chromium.org, gwendal@chromium.org, enric.balletbo@collabora.com Date: Thu, 16 Jan 2020 13:27:15 +0100 In-Reply-To: <20191118200000.35484-1-yichengli@chromium.org> References: <20191118200000.35484-1-yichengli@chromium.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I tried to test that patch but I cannot switch to RO firmware. I do the following steps: root@debian:/sys/class/chromeos/cros_fp# cat version RO version: nocturne_fp_v2.2.64-58cf5974e RW version: nocturne_fp_v2.2.110-b936c0a3c Firmware copy: RW Build info: nocturne_fp_v2.2.110-b936c0a3c 2018-11-02 14:16:46 @swarm-cros-461 Chip vendor: stm Chip name: stm32h7x3 Chip revision: Board version: EC error 1 root@debian:/sys/class/chromeos/cros_fp# echo ro > reboot root@debian:/sys/class/chromeos/cros_fp# cat version RO version: nocturne_fp_v2.2.64-58cf5974e RW version: nocturne_fp_v2.2.110-b936c0a3c Firmware copy: RW Build info: nocturne_fp_v2.2.110-b936c0a3c 2018-11-02 14:16:46 @swarm-cros-461 Chip vendor: stm Chip name: stm32h7x3 Chip revision: Board version: EC error 1 root@debian:/sys/class/chromeos/cros_fp# We see here that cros_fp is still RW. I also tried with: debian@debian:/src/ec$ sudo build/bds/util/ectool --name=cros_fp reboot_ec RO debian@debian:/src/ec$ sudo build/bds/util/ectool --name=cros_fp version RO version: nocturne_fp_v2.2.64-58cf5974e RW version: nocturne_fp_v2.2.110-b936c0a3c Firmware copy: RW Build info: nocturne_fp_v2.2.110-b936c0a3c 2018-11-02 14:16:46 @swarm-cros-461 Tool version: v2.0.3074-a5052d4e7 2020-01-16 10:23:05 debian@debian debian@debian:/src/ec$ with the same result. Can you decribe us steps you follow to test that patch? Thanks Fabien Le lundi 18 novembre 2019 à 12:00 -0800, Yicheng Li a écrit : > RO and RW of EC may have different EC protocol version. If EC > transitions > between RO and RW, but AP does not reboot (this is true for > fingerprint > microcontroller / cros_fp, but not true for main ec / cros_ec), the > AP > still uses the protocol version queried before transition, which can > cause problems. In the case of fingerprint microcontroller, this > causes > AP to send the wrong version of EC_CMD_GET_NEXT_EVENT to RO in the > interrupt handler, which in turn prevents RO to clear the interrupt > line to AP, in an infinite loop. > > Once an EC_HOST_EVENT_INTERFACE_READY is received, we know that there > might have been a transition between RO and RW, so re-query the > protocol. > > Signed-off-by: Yicheng Li > > Change-Id: Ib58032ff4a8e113bdbd07212e8aff42807afff38 > Series-to: LKML > Series-cc: Benson Leung , Enric Balletbo i Serra > , Gwendal Grignou > > --- > drivers/platform/chrome/cros_ec.c | 24 > +++++++++++++++++++++ > include/linux/platform_data/cros_ec_proto.h | 1 + > 2 files changed, 25 insertions(+) > > diff --git a/drivers/platform/chrome/cros_ec.c > b/drivers/platform/chrome/cros_ec.c > index 9b2d07422e17..0c910846d99d 100644 > --- a/drivers/platform/chrome/cros_ec.c > +++ b/drivers/platform/chrome/cros_ec.c > @@ -104,6 +104,23 @@ static int cros_ec_sleep_event(struct > cros_ec_device *ec_dev, u8 sleep_event) > return ret; > } > > +static int cros_ec_ready_event(struct notifier_block *nb, > + unsigned long queued_during_suspend, void *_notify) > +{ > + struct cros_ec_device *ec_dev = container_of(nb, struct > cros_ec_device, > + notifier_ready); > + u32 host_event = cros_ec_get_host_event(ec_dev); > + > + if (host_event & > EC_HOST_EVENT_MASK(EC_HOST_EVENT_INTERFACE_READY)) { > + mutex_lock(&ec_dev->lock); > + cros_ec_query_all(ec_dev); > + mutex_unlock(&ec_dev->lock); > + return NOTIFY_OK; > + } else { > + return NOTIFY_DONE; > + } > +} > + > /** > * cros_ec_register() - Register a new ChromeOS EC, using the > provided info. > * @ec_dev: Device to register. > @@ -201,6 +218,13 @@ int cros_ec_register(struct cros_ec_device > *ec_dev) > dev_dbg(ec_dev->dev, "Error %d clearing sleep event to > ec", > err); > > + /* Register the notifier for EC_HOST_EVENT_INTERFACE_READY > event. */ > + ec_dev->notifier_ready.notifier_call = cros_ec_ready_event; > + err = blocking_notifier_chain_register(&ec_dev->event_notifier, > + &ec_dev- > >notifier_ready); > + if (err < 0) > + dev_warn(ec_dev->dev, "Failed to register notifier\n"); > + > dev_info(dev, "Chrome EC device registered\n"); > > return 0; > diff --git a/include/linux/platform_data/cros_ec_proto.h > b/include/linux/platform_data/cros_ec_proto.h > index 0d4e4aaed37a..9840408c0b01 100644 > --- a/include/linux/platform_data/cros_ec_proto.h > +++ b/include/linux/platform_data/cros_ec_proto.h > @@ -161,6 +161,7 @@ struct cros_ec_device { > int event_size; > u32 host_event_wake_mask; > u32 last_resume_result; > + struct notifier_block notifier_ready; > > /* The platform devices used by the mfd driver */ > struct platform_device *ec;