Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3190489pxb; Fri, 12 Feb 2021 11:27:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJymK3WpqTB/WRIlPvpbn+2hCeIwAOHSAG2kPALQY9j944yHCUdtoVYWhuiLwHWBEakxMqli X-Received: by 2002:a17:906:804a:: with SMTP id x10mr4498728ejw.184.1613158057205; Fri, 12 Feb 2021 11:27:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613158057; cv=none; d=google.com; s=arc-20160816; b=ao5smlHrc7zSF7hFdXafVMhPkAP0PcIIAKPLUOBZbuUhG9R6Es8qdPrSjffbbf/Oz4 QOf7ep0khWYmTwBniNBURQi4RBKwt5LXeN7X4rwHGD5FjcpWYyiaOQBdi0YWbHvWgAyN oIpEYJA3Aw+DgEo29dGIuzK8Hcyun7UI07WBhzNa3H423p5ClzFZhJ0a2ytzyqU2rVNx irEzbk63ECMX4Oa5ytLMiqQRJiRRJA54PyGVN3psVdgXVObrS0dOW11MZwaKMJUoDyTA l/8wGyjDEL4cXmG5MDkO07Y6JJWhJvnvQkOAJHBqoZwVt+ihfmVoSHsTcUMnBglV+glr Ddeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=LxS5cUpKBcl5T2WAI80JBd2lVKJgCFSoSzgoNxoL1Hs=; b=Zdw3xgmvV8mP/8OnqdTSHpZxXCGbWuSB0m+YoL8HUvb9p7U6CQHv4sZ74/NSFfVKH5 eXw8IBMcs2qnwo+aKoq9Nn9dD4bcd1Tn0LwOobHqnVNxpPpgqYThiZPVgozvmFaKWabZ 1mnqJKkw7R8Yw/II51u/0Rx/I8CzmtksGk4n8HOHc0220l6bquipS3qdCxBXBGq+Xzqx b6Duq+mFS8dcv5kQFQkNn1t1CAFu3Cu4v849bdjPcPZG/wCQDiMCuhMjy2i1OGhzGOQC Wnca6BSAwTmiZGjN0cxibGLjSOokR5nTlvNekIhqRz67+fBK7TvaJfmkntoXiXH0dIdE NpLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=G7yR+HAc; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s6si6663685edc.573.2021.02.12.11.27.12; Fri, 12 Feb 2021 11:27:37 -0800 (PST) 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; dkim=pass header.i=@chromium.org header.s=google header.b=G7yR+HAc; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232084AbhBLTXu (ORCPT + 99 others); Fri, 12 Feb 2021 14:23:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44374 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231756AbhBLTX3 (ORCPT ); Fri, 12 Feb 2021 14:23:29 -0500 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A03DCC061574 for ; Fri, 12 Feb 2021 11:22:49 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id q7so350552iob.0 for ; Fri, 12 Feb 2021 11:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LxS5cUpKBcl5T2WAI80JBd2lVKJgCFSoSzgoNxoL1Hs=; b=G7yR+HAcsA5Kd+v7dV8kNIedjfbNhvZi0El63ZC1o1gIr2OHZPhC5rVAMrvMuVAkbi 8Cuf2eoWvpkYc6dLG2bR8zUAv4AtGlLOrKS2MHBqAPgZNhRyC/+8z6ri/YnQrS7zerxz 6OZ8bT6o6JFhzohpPgam8FYS7BXvi8ExKD2HY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LxS5cUpKBcl5T2WAI80JBd2lVKJgCFSoSzgoNxoL1Hs=; b=cZQcuI8EnIjEEexCTeeLwYPcCIxUX55uNjB+1FPgXktZUvUw8I+F/yc7JHitj/AeAV +X5orqKW/gGlN2rLSY0rA+4TkaeckDf4kXCdTHHVD55V96942CnWdcmqtm57dnLJoGaG kS/L48OSCh2wRLuPlsG1SVQox3hPUz0/+jQWmsQzMAPcg8cTXJDlZHacHRwTQQ61nGMV JizwdHIgqE9Urj1N8pyiB0LjZHvMjXKif3oSn6OuCXmDMnSzxMdCCUXtTQtd8I8qgYbw WA5PZn3lHX/P0yFxgkh0FRwZPdjmFaMJOGvzZ6bfnG5yjX4OLNUKnDUz5WCoaeVT8d8o KKCw== X-Gm-Message-State: AOAM531OCJZXriC1wraO7G1JMZd1c68zKvS1eiya/jNK+HjYQvQhieBX e9MRDb9ciYgBj2INR+72n1hxOYbeusRPWfCNOT6dgA== X-Received: by 2002:a6b:7501:: with SMTP id l1mr3253466ioh.92.1613157769086; Fri, 12 Feb 2021 11:22:49 -0800 (PST) MIME-Version: 1.0 References: <20210210025142.3609708-1-swboyd@chromium.org> <20210210025142.3609708-4-swboyd@chromium.org> <161297912701.418021.12174983952645253802@swboyd.mtv.corp.google.com> In-Reply-To: <161297912701.418021.12174983952645253802@swboyd.mtv.corp.google.com> From: Gwendal Grignou Date: Fri, 12 Feb 2021 11:22:37 -0800 Message-ID: Subject: Re: [PATCH v5 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver To: Stephen Boyd Cc: Jonathan Cameron , linux-kernel , linux-iio , Dmitry Torokhov , Benson Leung , Guenter Roeck , Douglas Anderson , Enric Balletbo i Serra Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 10, 2021 at 9:45 AM Stephen Boyd wrote: > > Quoting Gwendal Grignou (2021-02-10 00:29:45) > > On Tue, Feb 9, 2021 at 6:51 PM Stephen Boyd wrote: > > > + if (event_type == EC_MKBP_EVENT_SWITCH) { > > > + data = container_of(nb, struct cros_ec_mkbp_proximity_data, > > > + notifier); > > > + indio_dev = data->indio_dev; > > > + > > > + mutex_lock(&data->lock); > > > + if (data->enabled) { > > > + timestamp = ktime_to_ns(ec->last_event_time); > > Note to self, ktime_to_ns is a noop, but make code cleaner: need to > > change other access to ec->last_event_time. > > > > > + if (iio_device_get_clock(indio_dev) != CLOCK_BOOTTIME) > > > + timestamp = iio_get_time_ns(indio_dev); > > > + state = cros_ec_mkbp_proximity_parse_state(switches); > > > > There can be several switches in the EC (lid open, tablet mode, ...), > > so you can get a switch event even when the proximity switch did not > > trigger. > > You can keep the current state and push an iio event only when there > > is a change. See cbas_ec_notify(). > > > > Ah ok. So we'll have to save a state tracking variable and poll the bit > once at boot and then at resume time? Required at boot: There is provision in the EC to report switch events at init mkbp_report_switch_on_init(), but that's only useful when EC reboots or transitions from RO to RW while AP is up. No need to peek at resume time: the EC will send a switch event if the mask has changed during suspend: when the AP is sleeping, EC just put the event in a FIFO. But looking at the code, the FIFO can get full, so if no switch events can be added, we lose them - see mkbp_fifo_add()). Then cros_ec_report_events_during_suspend() will gather these events. > What happens to events that happen across suspend/resume? We drop them? We should not drop them: if the user gets close while the device is suspended and she resumes it, we should be able to send that info to the user space. EV stores switches values in a single field |mkbp_switch_state|, so 2 events that nullify themselves during suspend will be ignored. > Or we need to inject the last state > if it's different into IIO with the time of resume? The notifier routine will be called. Looking at the code, the ec last_event_time is not updated, I need to fix cros_ec_resume(). > > > > + dir = state ? IIO_EV_DIR_FALLING : IIO_EV_DIR_RISING; > > > + > > > + ev = IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY, 0, > > > + IIO_EV_TYPE_THRESH, dir); > > > + iio_push_event(indio_dev, ev, timestamp); > > > + } > > > + mutex_unlock(&data->lock); > > > + } > > > + > > > + return NOTIFY_OK; > > > +} > > > + > > > +static int cros_ec_mkbp_proximity_read_raw(struct iio_dev *indio_dev, > > > + const struct iio_chan_spec *chan, int *val, > > > + int *val2, long mask) > > > +{ > > > + struct cros_ec_mkbp_proximity_data *data = iio_priv(indio_dev); > > > + struct cros_ec_device *ec = data->ec; > > > + > > > + if (chan->type != IIO_PROXIMITY) > > > + return -EINVAL; > > > + > > > + switch (mask) { > > > > A switch is not necessary here. > > Ok. > > > > + case IIO_CHAN_INFO_RAW: