All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Mark Hasemeyer <markhas@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Raul Rangel <rrangel@chromium.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	Rob Herring <robh@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Benson Leung <bleung@chromium.org>,
	Bhanu Prakash Maiya <bhanumaiya@chromium.org>,
	Chen-Yu Tsai <wenst@chromium.org>,
	Guenter Roeck <groeck@chromium.org>, Lee Jones <lee@kernel.org>,
	Prashant Malani <pmalani@chromium.org>,
	Rob Barnes <robbarnes@google.com>,
	Stephen Boyd <swboyd@chromium.org>,
	chrome-platform@lists.linux.dev
Subject: Re: [PATCH v2 22/22] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq
Date: Thu, 21 Dec 2023 16:58:07 +0800	[thread overview]
Message-ID: <ZYP-H27vsJvMTupH@google.com> (raw)
In-Reply-To: <20231220165423.v2.22.Ieee574a0e94fbaae01fd6883ffe2ceeb98d7df28@changeid>

On Wed, Dec 20, 2023 at 04:54:36PM -0700, Mark Hasemeyer wrote:
> The IRQ wake logic was added on an interface basis (lpc, spi, uart) as
> opposed to adding it to cros_ec.c because the i2c subsystem already
> enables the wakirq (if applicable) on our behalf.

The setting flow are all the same.  I think helper functions in cros_ec.c help
to deduplicate the code.

> diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c
[...]
> +static const struct dmi_system_id untrusted_fw_irq_wake_capable[] = {
> +	{
> +		.ident = "Brya",
> +		.matches = {
> +			DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Brya")
> +		}
> +	},
> +	{
> +		.ident = "Brask",
> +		.matches = {
> +			DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Brask")
> +		}
> +	},
> +	{ }
> +}
> +MODULE_DEVICE_TABLE(dmi, untrusted_fw_irq_wake_capable);

Does it really need `MODULE_DEVICE_TABLE`?

> +static bool cros_ec_should_force_irq_wake_capable(void)

Suggestion: either drop "cros_ec_" prefix or use "cros_ec_lpc_" prefix.

> @@ -428,20 +453,36 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
>  	 * Some boards do not have an IRQ allotted for cros_ec_lpc,
>  	 * which makes ENXIO an expected (and safe) scenario.
>  	 */
> -	irq = platform_get_irq_optional(pdev, 0);
> -	if (irq > 0)
> +	irq = platform_get_irq_resource_optional(pdev, 0, &irqres);
> +	if (irq > 0) {
>  		ec_dev->irq = irq;
> -	else if (irq != -ENXIO) {
> +		if (cros_ec_should_force_irq_wake_capable())

Please see suggestion above.

>  	ret = cros_ec_register(ec_dev);
>  	if (ret) {
> -		dev_err(dev, "couldn't register ec_dev (%d)\n", ret);
> +		dev_err_probe(dev, ret, "couldn't register ec_dev (%d)\n", ret);

The change is irrelevant to the series.

> +	if (irq_wake) {
> +		ret = device_init_wakeup(dev, true);
> +		if (ret) {
> +			dev_err_probe(dev, ret, "Failed to init device for wakeup");
> +			return ret;
> +		}
> +		ret = dev_pm_set_wake_irq(dev, irq);
> +		if (ret)
> +			return ret;
> +	}
[...]
> @@ -470,6 +512,8 @@ static void cros_ec_lpc_remove(struct platform_device *pdev)
>  		acpi_remove_notify_handler(adev->handle, ACPI_ALL_NOTIFY,
>  					   cros_ec_lpc_acpi_notify);
>  
> +	dev_pm_clear_wake_irq(dev);
> +	device_init_wakeup(dev, false);

Is it safe to call them anyway regardless of `irq_wake` in cros_ec_lpc_probe()?

> diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c
[...]
> -static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device *dev)
> +static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct spi_device *spi)
>  {
> -	struct device_node *np = dev->of_node;
> +	struct cros_ec_device *ec_dev = spi_get_drvdata(spi);
> +	struct device_node *np = spi->dev.of_node;

struct spi_device *spi = ec_spi->spi; [1]

[1]: https://elixir.bootlin.com/linux/v6.6/source/drivers/platform/chrome/cros_ec_spi.c#L751

> +	if (!np)
> +		return;
> +

The change is an improvement (or rather say it could change behavior).  But
strictly speaking, the change is irrelevant to the series.

> @@ -702,6 +710,11 @@ static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device *dev)
>  	ret = of_property_read_u32(np, "google,cros-ec-spi-msg-delay", &val);
>  	if (!ret)
>  		ec_spi->end_of_msg_delay = val;
> +
> +	if (ec_dev->irq > 0 && of_property_read_bool(np, "wakeup-source")) {

Or just use `spi->irq`[2].

[2]: https://elixir.bootlin.com/linux/v6.6/source/drivers/platform/chrome/cros_ec_spi.c#L762

They are the same, but does of_property_present() make more sense?

> @@ -768,6 +778,9 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>  			   sizeof(struct ec_response_get_protocol_info);
>  	ec_dev->dout_size = sizeof(struct ec_host_request);
>  
> +	/* Check for any DT properties */
> +	cros_ec_spi_dt_probe(ec_spi, spi);

`spi` is possibly not needed.  See comment above.

> @@ -776,19 +789,31 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>  
>  	err = cros_ec_register(ec_dev);
>  	if (err) {
> -		dev_err(dev, "cannot register EC\n");
> +		dev_err_probe(dev, err, "cannot register EC\n");

The change is irrelevant to the series.

> -	device_init_wakeup(&spi->dev, true);
> +	if (ec_spi->irq_wake) {
> +		err = device_init_wakeup(dev, true);
> +		if (err) {
> +			dev_err_probe(dev, err, "Failed to init device for wakeup\n");
> +			return err;
> +		}
> +		err = dev_pm_set_wake_irq(dev, ec_dev->irq);
> +		if (err)
> +			dev_err_probe(dev, err, "Failed to set irq(%d) for wake\n", ec_dev->irq);

The part is different from what the patch changed in cros_ec_lpc.c.  Better to
be consistent.
- Just return vs. dev_err_probe().
- %i vs. %d.

>  static void cros_ec_spi_remove(struct spi_device *spi)
>  {
>  	struct cros_ec_device *ec_dev = spi_get_drvdata(spi);
> +	struct device *dev = ec_dev->dev;
>  
> +	dev_pm_clear_wake_irq(dev);
> +	device_init_wakeup(dev, false);

Ditto, is it safe to just call them regardless of `ec_spi->irq_wake`?

> diff --git a/drivers/platform/chrome/cros_ec_uart.c b/drivers/platform/chrome/cros_ec_uart.c
[...]
> @@ -301,13 +307,31 @@ static int cros_ec_uart_probe(struct serdev_device *serdev)
>  
>  	serdev_device_set_client_ops(serdev, &cros_ec_uart_client_ops);
>  
> -	return cros_ec_register(ec_dev);
> +	/* Register a new cros_ec device */
> +	ret = cros_ec_register(ec_dev);
> +	if (ret) {
> +		dev_err(dev, "Couldn't register ec_dev (%d)\n", ret);

From reading the changes above, I thought it would use dev_err_probe().

> +	if (ec_uart->irq_wake) {
> +		ret = device_init_wakeup(dev, true);
> +		if (ret) {
> +			dev_err_probe(dev, ret, "Failed to init device for wakeup");
> +			return ret;
> +		}
> +		ret = dev_pm_set_wake_irq(dev, ec_uart->irq);

Ditto, better to be consistent.

>  static void cros_ec_uart_remove(struct serdev_device *serdev)
>  {
>  	struct cros_ec_device *ec_dev = serdev_device_get_drvdata(serdev);
> +	struct device *dev = ec_dev->dev;
>  
> +	dev_pm_clear_wake_irq(dev);
> +	device_init_wakeup(dev, false);

Ditto, is it safe to just call them regardless of `ec_uart->irq_wake`?

  reply	other threads:[~2023-12-21  8:58 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20 23:54 [PATCH v2 00/22] Improve IRQ wake capability reporting and update the cros_ec driver to use it Mark Hasemeyer
2023-12-20 23:54 ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 01/22] gpiolib: acpi: Modify acpi_dev_irq_wake_get_by() to use resource Mark Hasemeyer
2023-12-21 15:17   ` Andy Shevchenko
2023-12-23  2:05   ` kernel test robot
2023-12-23  3:09     ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 02/22] i2c: acpi: Modify i2c_acpi_get_irq() " Mark Hasemeyer
2023-12-21 13:51   ` Andy Shevchenko
2023-12-20 23:54 ` [PATCH v2 03/22] Documentation: devicetree: Clarify wording for wakeup-source property Mark Hasemeyer
2023-12-21  8:13   ` Krzysztof Kozlowski
2023-12-21 18:16     ` Mark Hasemeyer
2023-12-21 18:42       ` Krzysztof Kozlowski
2023-12-20 23:54 ` [PATCH v2 04/22] ARM: dts: tegra: Enable cros-ec-spi as wake source Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 05/22] ARM: dts: rockchip: rk3288: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 06/22] ARM: dts: samsung: exynos5420: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-21  8:14   ` Krzysztof Kozlowski
2023-12-21  8:14     ` Krzysztof Kozlowski
2023-12-21 18:29     ` Mark Hasemeyer
2023-12-21 18:29       ` Mark Hasemeyer
2023-12-21 18:38       ` Krzysztof Kozlowski
2023-12-21 18:38         ` Krzysztof Kozlowski
2023-12-21 19:24         ` Mark Hasemeyer
2023-12-21 19:24           ` Mark Hasemeyer
2023-12-21 20:34           ` Krzysztof Kozlowski
2023-12-21 20:34             ` Krzysztof Kozlowski
2024-01-22 11:15   ` (subset) " Krzysztof Kozlowski
2024-01-22 11:15     ` Krzysztof Kozlowski
2023-12-20 23:54 ` [PATCH v2 07/22] ARM: dts: samsung: exynos5800: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2024-01-22 11:15   ` (subset) " Krzysztof Kozlowski
2024-01-22 11:15     ` Krzysztof Kozlowski
2023-12-20 23:54 ` [PATCH v2 08/22] arm64: dts: mediatek: mt8173: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 09/22] arm64: dts: mediatek: mt8183: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 10/22] arm64: dts: mediatek: mt8192: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 11/22] arm64: dts: mediatek: mt8195: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 12/22] arm64: dts: tegra: " Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 13/22] arm64: dts: qcom: sc7180: " Mark Hasemeyer
2023-12-21  0:10   ` Doug Anderson
2023-12-20 23:54 ` [PATCH v2 14/22] arm64: dts: qcom: sc7280: " Mark Hasemeyer
2023-12-21  0:10   ` Doug Anderson
2023-12-20 23:54 ` [PATCH v2 15/22] arm64: dts: qcom: sdm845: " Mark Hasemeyer
2023-12-21  0:11   ` Doug Anderson
2023-12-20 23:54 ` [PATCH v2 16/22] arm64: dts: rockchip: rk3399: " Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54   ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 17/22] of: irq: add wake capable bit to of_irq_resource() Mark Hasemeyer
2023-12-21 15:25   ` Andy Shevchenko
2023-12-22 22:22     ` Mark Hasemeyer
2023-12-21 20:44   ` Rob Herring
2023-12-20 23:54 ` [PATCH v2 18/22] of: irq: Add default implementation for of_irq_to_resource() Mark Hasemeyer
2023-12-21 20:48   ` Rob Herring
2023-12-20 23:54 ` [PATCH v2 19/22] of: irq: Remove extern from function declarations Mark Hasemeyer
2023-12-21 20:49   ` Rob Herring
2023-12-20 23:54 ` [PATCH v2 20/22] device property: Modify fwnode irq_get() to use resource Mark Hasemeyer
2023-12-21 10:37   ` Sakari Ailus
2023-12-21 23:52     ` Mark Hasemeyer
2023-12-22 12:48       ` Andy Shevchenko
2023-12-21 13:56   ` Andy Shevchenko
2023-12-21 23:46     ` Mark Hasemeyer
     [not found]       ` <CAHQZ30BOA7zuRrN-kK5Qw+NYSVydfhJ0gDPr9q-U+7VKXHzG8g@mail.gmail.com>
2023-12-21 23:59         ` Mark Hasemeyer
2023-12-22 12:46           ` Andy Shevchenko
2023-12-22 12:46         ` Andy Shevchenko
2023-12-22 12:44       ` Andy Shevchenko
2023-12-20 23:54 ` [PATCH v2 21/22] platform: Modify platform_get_irq_optional() " Mark Hasemeyer
2023-12-21 15:33   ` Andy Shevchenko
2023-12-22 21:51     ` Mark Hasemeyer
2023-12-20 23:54 ` [PATCH v2 22/22] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq Mark Hasemeyer
2023-12-21  8:58   ` Tzung-Bi Shih [this message]
2023-12-22 22:19     ` Mark Hasemeyer
2023-12-21 15:45   ` Andy Shevchenko
2023-12-22 22:21     ` Mark Hasemeyer
2023-12-23  0:32   ` kernel test robot
2023-12-23  3:11     ` Mark Hasemeyer
2023-12-23 16:41   ` kernel test robot
2023-12-21 13:42 ` [PATCH v2 00/22] Improve IRQ wake capability reporting and update the cros_ec driver to use it Andy Shevchenko
2023-12-21 13:42   ` Andy Shevchenko
2023-12-21 13:42   ` Andy Shevchenko
2023-12-22 22:30   ` Mark Hasemeyer
2023-12-22 22:30     ` Mark Hasemeyer
2023-12-22 22:30     ` Mark Hasemeyer
2023-12-27 16:01     ` Andy Shevchenko
2023-12-27 16:01       ` Andy Shevchenko
2023-12-27 16:01       ` Andy Shevchenko

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=ZYP-H27vsJvMTupH@google.com \
    --to=tzungbi@kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bhanumaiya@chromium.org \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=groeck@chromium.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markhas@chromium.org \
    --cc=pmalani@chromium.org \
    --cc=robbarnes@google.com \
    --cc=robh@kernel.org \
    --cc=rrangel@chromium.org \
    --cc=sudeep.holla@arm.com \
    --cc=swboyd@chromium.org \
    --cc=wenst@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.