All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Yicheng Li <yichengli@chromium.org>, LKML <linux-kernel@vger.kernel.org>
Cc: bleung@chromium.org, enric.balletbo@collabora.com,
	groeck@chromium.org, lee.jones@linaro.org, gwendal@chromium.org,
	andriy.shevchenko@linux.intel.com, Jonathan.Cameron@huawei.com,
	evgreen@chromium.org, rushikesh.s.kadam@intel.com,
	tglx@linutronix.de
Subject: Re: [PATCH v6] platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW
Date: Tue, 4 Feb 2020 08:30:32 +0100	[thread overview]
Message-ID: <54cbade6-c552-4877-a8d7-d2be9930cefd@samsung.com> (raw)
In-Reply-To: <20200203225356.203946-1-yichengli@chromium.org>

Hi

On 03.02.2020 23:53, Yicheng Li wrote:
> 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 <yichengli@chromium.org>

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Works fine on Samsung Exynos-based Chromebooks: Snow, Peach-Pit and 
Peach-Pi.

> ---
> Hi Enric and Marek,
>
>> This patch landed recently in linux-next as commit
>> 241a69ae8ea8e2defec751fe55dac1287aa044b8. Sadly, it causes following
>> kernel oops on any key press on Samsung Exynos-based Chromebooks (Snow,
>> Peach-Pit and Peach-Pi):
>
>> Many thanks for report the issue, we will take a look ASAP and revert
>> this commit meanwhile.
>
>> Simply removing the BUG_ON() from cros_ec_get_host_event() function
>> fixes the issue, but I don't know the protocol details to judge if this
>> is the correct way of fixing it.
> The issue was those Samsung Chromebooks (Snow, Peach-Pit and Peach-Pi)
> do not support mkbp events, yet we applied the same thing to them, which
> we shouldn't. This v6 should fix it: I Just added a check
>
> 	if (ec_dev->mkbp_event_supported)
>
> in cros_ec_register().
>
>
>
> drivers/platform/chrome/cros_ec.c           | 29 +++++++++++++++++++++
>   include/linux/platform_data/cros_ec_proto.h |  3 +++
>   2 files changed, 32 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec.c b/drivers/platform/chrome/cros_ec.c
> index 9b2d07422e17..f16804db805b 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;
> +	}
> +
> +	return NOTIFY_DONE;
> +}
> +
>   /**
>    * cros_ec_register() - Register a new ChromeOS EC, using the provided info.
>    * @ec_dev: Device to register.
> @@ -201,6 +218,18 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>   		dev_dbg(ec_dev->dev, "Error %d clearing sleep event to ec",
>   			err);
>   
> +	if (ec_dev->mkbp_event_supported) {
> +		/*
> +		 * 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)
> +			return err;
> +	}
> +
>   	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..a1c545c464e7 100644
> --- a/include/linux/platform_data/cros_ec_proto.h
> +++ b/include/linux/platform_data/cros_ec_proto.h
> @@ -121,6 +121,8 @@ struct cros_ec_command {
>    * @event_data: Raw payload transferred with the MKBP event.
>    * @event_size: Size in bytes of the event data.
>    * @host_event_wake_mask: Mask of host events that cause wake from suspend.
> + * @notifier_ready: The notifier_block to let the kernel re-query EC
> + *      communication protocol when the EC sends EC_HOST_EVENT_INTERFACE_READY.
>    * @ec: The platform_device used by the mfd driver to interface with the
>    *      main EC.
>    * @pd: The platform_device used by the mfd driver to interface with the
> @@ -161,6 +163,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;

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


  parent reply	other threads:[~2020-02-04  7:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 22:53 [PATCH v6] platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW Yicheng Li
     [not found] ` <CGME20200204073034eucas1p1592fa2436b5567c2d15cf2935c3a8804@eucas1p1.samsung.com>
2020-02-04  7:30   ` Marek Szyprowski [this message]
2020-02-04 20:40     ` Gwendal Grignou
2020-02-05  9:06       ` Enric Balletbo i Serra
2020-02-11  9:42 ` Enric Balletbo i Serra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54cbade6-c552-4877-a8d7-d2be9930cefd@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bleung@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=evgreen@chromium.org \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rushikesh.s.kadam@intel.com \
    --cc=tglx@linutronix.de \
    --cc=yichengli@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.