public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Mark Hasemeyer <markhas@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Raul Rangel" <rrangel@chromium.org>,
	"David Gow" <davidgow@google.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Takashi Iwai" <tiwai@suse.de>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH v1 5/6] platform: Modify platform_get_irq_optional() to use resource
Date: Wed, 13 Dec 2023 16:04:37 -0600	[thread overview]
Message-ID: <20231213220437.GA2115075-robh@kernel.org> (raw)
In-Reply-To: <20231213110009.v1.5.Ife9ebad2bbfbab3a05e90040f344d750aa0aac7e@changeid>

On Wed, Dec 13, 2023 at 11:00:23AM -0700, Mark Hasemeyer wrote:
> Unify handling of ACPI, GPIO, devictree, and platform resource
> interrupts in platform_get_irq_optional(). Each of these subsystems
> provide their own apis which provide IRQ information as a struct
> resource. This simplifies the logic of the function and allows callers
> to get more information about the irq by looking at the resource flags.
> For example, whether or not an irq is wake capable.
> 
> Rename the function to platform_get_irq_resource() to better describe
> the function's new behavior.

This is misleading as the original function is still there.

The get_optional() functions are designed to not print an error message 
where as the non-optional variant will. You've broken that pattern here 
in that there is no platform_get_irq_resource_optional() (at least named 
that because your implementation is that since there is no error 
message).

What about versions equivalent to platform_get_irq_byname() 
and platform_get_irq_byname_optional(), though I guess we need users 
first.

> 
> Signed-off-by: Mark Hasemeyer <markhas@chromium.org>
> ---
> 
>  drivers/base/platform.c         | 78 ++++++++++++++++++---------------
>  include/linux/platform_device.h |  9 +++-
>  2 files changed, 50 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 76bfcba250039..6b58bde776d4f 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -151,9 +151,10 @@ EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname);
>  #endif /* CONFIG_HAS_IOMEM */
>  
>  /**
> - * platform_get_irq_optional - get an optional IRQ for a device
> + * platform_get_irq_resource - get an IRQ for a device and populate resource struct
>   * @dev: platform device
>   * @num: IRQ number index
> + * @r: pointer to resource to populate with irq information. It is not modified on failure.
>   *
>   * Gets an IRQ for a platform device. Device drivers should check the return
>   * value for errors so as to not pass a negative integer value to the
> @@ -162,59 +163,47 @@ EXPORT_SYMBOL_GPL(devm_platform_ioremap_resource_byname);
>   *
>   * For example::
>   *
> - *		int irq = platform_get_irq_optional(pdev, 0);
> + *		int irq = platform_get_irq_resource(pdev, 0, &res);
>   *		if (irq < 0)
>   *			return irq;
>   *
>   * Return: non-zero IRQ number on success, negative error number on failure.
>   */
> -int platform_get_irq_optional(struct platform_device *dev, unsigned int num)
> +int platform_get_irq_resource(struct platform_device *dev, unsigned int num, struct resource *r)
>  {
>  	int ret;
>  #ifdef CONFIG_SPARC
>  	/* sparc does not have irqs represented as IORESOURCE_IRQ resources */
>  	if (!dev || num >= dev->archdata.num_irqs)
> -		goto out_not_found;
> +		return -ENXIO;
>  	ret = dev->archdata.irqs[num];
> +	if (ret >= 0)
> +		*r = (struct resource)DEFINE_RES_IRQ(ret);
>  	goto out;
>  #else
> -	struct resource *r;
> +	struct resource *platform_res;
>  
>  	if (IS_ENABLED(CONFIG_OF_IRQ) && dev->dev.of_node) {
> -		ret = of_irq_get(dev->dev.of_node, num);
> +		ret = of_irq_to_resource(dev->dev.of_node, num, r);
>  		if (ret > 0 || ret == -EPROBE_DEFER)
>  			goto out;
>  	}
>  
> -	r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> -	if (has_acpi_companion(&dev->dev)) {
> -		if (r && r->flags & IORESOURCE_DISABLED) {
> -			ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> -			if (ret)
> -				goto out;
> -		}
> -	}
> -
> -	/*
> -	 * The resources may pass trigger flags to the irqs that need
> -	 * to be set up. It so happens that the trigger flags for
> -	 * IORESOURCE_BITS correspond 1-to-1 to the IRQF_TRIGGER*
> -	 * settings.
> -	 */
> -	if (r && r->flags & IORESOURCE_BITS) {
> -		struct irq_data *irqd;
> -
> -		irqd = irq_get_irq_data(r->start);
> -		if (!irqd)
> -			goto out_not_found;
> -		irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS);
> -	}
> -
> -	if (r) {
> +	platform_res = platform_get_resource(dev, IORESOURCE_IRQ, num);
> +	if (platform_res && !(platform_res->flags & IORESOURCE_DISABLED)) {
> +		*r = *platform_res;
>  		ret = r->start;
>  		goto out;
>  	}
>  
> +	if (has_acpi_companion(&dev->dev)) {
> +		ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> +		if (!ret || ret == -EPROBE_DEFER) {
> +			ret = ret ?: r->start;
> +			goto out;
> +		}
> +	}
> +
>  	/*
>  	 * For the index 0 interrupt, allow falling back to GpioInt
>  	 * resources. While a device could have both Interrupt and GpioInt
> @@ -223,21 +212,38 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num)
>  	 * allows a common code path across either kind of resource.
>  	 */
>  	if (num == 0 && has_acpi_companion(&dev->dev)) {
> -		ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num);
> +		ret = acpi_dev_get_gpio_irq_resource(ACPI_COMPANION(&dev->dev), NULL,
> +						     num, r);
>  		/* Our callers expect -ENXIO for missing IRQs. */
> -		if (ret >= 0 || ret == -EPROBE_DEFER)
> +		if (!ret || ret == -EPROBE_DEFER) {
> +			ret = ret ?: r->start;
>  			goto out;
> +		}
>  	}
> -
>  #endif
> -out_not_found:
>  	ret = -ENXIO;
>  out:
>  	if (WARN(!ret, "0 is an invalid IRQ number\n"))
>  		return -EINVAL;
> +
> +	/*
> +	 * The resources may pass trigger flags to the irqs that need
> +	 * to be set up. It so happens that the trigger flags for
> +	 * IORESOURCE_BITS correspond 1-to-1 to the IRQF_TRIGGER*
> +	 * settings.
> +	 */
> +	if (ret > 0 && r->flags & IORESOURCE_BITS) {
> +		struct irq_data *irqd;
> +
> +		irqd = irq_get_irq_data(r->start);
> +		if (!irqd)
> +			ret = -ENXIO;
> +		else
> +			irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS);

We were not doing any of this in the DT or Sparc cases before. It's 
probably just redundant for DT. It might break Sparc.

Rob

  parent reply	other threads:[~2023-12-13 22:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 18:00 [PATCH v1 1/6] gpiolib: acpi: Modify acpi_dev_irq_wake_get_by to use resource Mark Hasemeyer
2023-12-13 18:00 ` [PATCH v1 2/6] arm: arm64: dts: Enable cros-ec-spi as wake source Mark Hasemeyer
2023-12-13 18:08   ` Krzysztof Kozlowski
2023-12-13 22:11   ` Rob Herring
2023-12-14 21:04     ` Mark Hasemeyer
2023-12-14 22:20       ` Rob Herring
2023-12-14 10:55   ` AngeloGioacchino Del Regno
2023-12-14 11:53     ` Konrad Dybcio
2023-12-13 18:00 ` [PATCH v1 3/6] of: irq: add wake capable bit to of_irq_resource() Mark Hasemeyer
2023-12-13 19:44   ` Andy Shevchenko
2023-12-13 22:19   ` Rob Herring
2023-12-14 21:05     ` Mark Hasemeyer
2023-12-15 15:30       ` Rob Herring
2023-12-15 20:56         ` Mark Hasemeyer
2023-12-18 10:49           ` Sudeep Holla
2023-12-13 18:00 ` [PATCH v1 4/6] of: irq: Add default implementation for of_irq_to_resource() Mark Hasemeyer
2023-12-13 19:45   ` Andy Shevchenko
2023-12-13 18:00 ` [PATCH v1 5/6] platform: Modify platform_get_irq_optional() to use resource Mark Hasemeyer
2023-12-13 19:52   ` Andy Shevchenko
2023-12-18 20:23     ` Mark Hasemeyer
2023-12-19 14:58       ` Andy Shevchenko
2023-12-13 22:04   ` Rob Herring [this message]
2023-12-13 18:00 ` [PATCH v1 6/6] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq Mark Hasemeyer
2023-12-14  3:09   ` Tzung-Bi Shih
2023-12-15 21:02     ` Mark Hasemeyer
2023-12-13 19:34 ` [PATCH v1 1/6] gpiolib: acpi: Modify acpi_dev_irq_wake_get_by to use resource Andy Shevchenko
2023-12-14 20:56   ` Mark Hasemeyer
2023-12-13 19:40 ` 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=20231213220437.GA2115075-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=broonie@kernel.org \
    --cc=davidgow@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markhas@chromium.org \
    --cc=rafael@kernel.org \
    --cc=rrangel@chromium.org \
    --cc=tiwai@suse.de \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox