All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org,
	Prabhakar <prabhakar.csengg@gmail.com>,
	Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [RFC PATCH] of: platform: Skip mapping of interrupts in of_device_alloc()
Date: Thu, 09 Dec 2021 08:07:09 +0000	[thread overview]
Message-ID: <d290850bf95f4bdf0c329f278db458c7@kernel.org> (raw)
In-Reply-To: <20211209001056.29774-1-prabhakar.mahadev-lad.rj@bp.renesas.com>

On 2021-12-09 00:10, Lad Prabhakar wrote:
> of_device_alloc() in early boot stage creates a interrupt mapping if
> there exists a "interrupts" property in the node.
> 
> For hierarchical interrupt domains using "interrupts" property in the 
> node
> bypassed the hierarchical setup and messed up the irq setup.
> 
> This patch adds a check in of_device_alloc() to skip interrupt mapping 
> if
> "not-interrupt-producer" property is present in the node. This allows
> nodes to describe the interrupts using "interrupts" property.
> 
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> Hi All,
> 
> Spawning from discussion [1], here is simple patch (not the ideal 
> probably
> welcome for suggestions) from stopping the OF code from creating a map 
> for
> the interrupts when using "interrupts" property.
> 
> [1] https://lore.kernel.org/lkml/87pmqrck2m.wl-maz@kernel.org/
>     T/#mbd1e47c1981082aded4b32a52e2c04291e515508
> 
> Cheers,
> Prabhakar
> ---
>  drivers/of/platform.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b3faf89744aa..629776ca1721 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -114,7 +114,7 @@ struct platform_device *of_device_alloc(struct
> device_node *np,
>  				  struct device *parent)
>  {
>  	struct platform_device *dev;
> -	int rc, i, num_reg = 0, num_irq;
> +	int rc, i, num_reg = 0, num_irq = 0;
>  	struct resource *res, temp_res;
> 
>  	dev = platform_device_alloc("", PLATFORM_DEVID_NONE);
> @@ -124,7 +124,14 @@ struct platform_device *of_device_alloc(struct
> device_node *np,
>  	/* count the io and irq resources */
>  	while (of_address_to_resource(np, num_reg, &temp_res) == 0)
>  		num_reg++;
> -	num_irq = of_irq_count(np);
> +
> +	/*
> +	 * we don't want to map the interrupts of hierarchical interrupt 
> domain
> +	 * into the parent domain yet. This will be the job of the 
> hierarchical
> +	 * interrupt driver code to map the interrupts as and when needed.
> +	 */
> +	if (!of_property_read_bool(np, "not-interrupt-producer"))

I don't think this is right. If anything, the expected behaviour should 
be
indicated by the driver and not the device node.

> +		num_irq = of_irq_count(np);
> 
>  	/* Populate the resource table */
>  	if (num_irq || num_reg) {
> @@ -140,7 +147,7 @@ struct platform_device *of_device_alloc(struct
> device_node *np,
>  			rc = of_address_to_resource(np, i, res);
>  			WARN_ON(rc);
>  		}
> -		if (of_irq_to_resource_table(np, res, num_irq) != num_irq)
> +		if (num_irq && of_irq_to_resource_table(np, res, num_irq) != 
> num_irq)
>  			pr_debug("not all legacy IRQ resources mapped for %pOFn\n",
>  				 np);
>  	}

The root of the issue is that all the resource allocation is done 
upfront,
way before we even have a driver that could potentially deal with this
device. This is a potential waste of resource, and it triggers the
issue you noticed.

If you delay the resource allocation until there is an actual match with 
a
driver, you could have a per-driver flag telling you whether the IRQ
allocation should be performed before the probe() function is called.

         M.
-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2021-12-09  8:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09  0:10 [RFC PATCH] of: platform: Skip mapping of interrupts in of_device_alloc() Lad Prabhakar
2021-12-09  3:08 ` Rob Herring
2021-12-09  9:48   ` Lad, Prabhakar
2021-12-09  8:07 ` Marc Zyngier [this message]
2021-12-09 10:00   ` Lad, Prabhakar
2021-12-09 10:33     ` Marc Zyngier
2021-12-09 11:34       ` Lad, Prabhakar
2021-12-09 20:34         ` Rob Herring
2021-12-10  1:16           ` Lad, Prabhakar
2021-12-10 14:19             ` Rob Herring
2022-03-09 21:09       ` Lad, Prabhakar

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=d290850bf95f4bdf0c329f278db458c7@kernel.org \
    --to=maz@kernel.org \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.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 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.