All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Biju Das <biju.das.jz@bp.renesas.com>
Subject: Re: [RFC PATCH] of: platform: Skip mapping of interrupts in of_device_alloc()
Date: Fri, 10 Dec 2021 08:19:58 -0600	[thread overview]
Message-ID: <CAL_Jsq+jyqbhA1jpgZ+yTwWGvCMRu9VmgoDq8MDM9SMqJ-XSBw@mail.gmail.com> (raw)
In-Reply-To: <CA+V-a8sifb8zpMB=VwBn6qXob=3JRQdMTh1PWD-M7SquP9S9+g@mail.gmail.com>

On Thu, Dec 9, 2021 at 7:16 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> On Thu, Dec 9, 2021 at 8:34 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Thu, Dec 9, 2021 at 5:35 AM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > Hi Rob and Marc,
> > >
> > > On Thu, Dec 9, 2021 at 10:33 AM Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > On Thu, 09 Dec 2021 10:00:44 +0000,
> > > > "Lad, Prabhakar" <prabhakar.csengg@gmail.com> wrote:
> > > > >
> > > > > > 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.
> > > > > >
> > > > > As suggested by Rob, if we switch the drivers to use
> > > > > platform_get_resource(pdev, IORESOURCE_IRQ, n) call with
> > > > > platform_get_irq() this code should go away and with this switch the
> > > > > resource allocation will happen demand. Is this approach OK?
> > > >
> > > > If you get rid of of_irq_to_resource_table() altogether, then yes,
> > > > this has a fighting chance to work.
> > > >
> > > Yes, switching to platform_get_irq() will eventually cause
> > > of_irq_to_resource_table() to go away.
> > >
> > > On second thought, instead of touching all the drivers, if we update
> > > platform_get_resource/platform_get_resource_byname to internally call
> > > platform_get_irq() internally if it's a IORESOURCE_IRQ resource. Does
> > > that sound good or should I just get on changing all the drivers to
> > > use platform_get_irq() instead?
> >
> > Except that platform_get_irq() already internally calls
> > platform_get_resource()... I think changing the drivers is the right
> > way. Happy to do some if you want to divide it up.
> >
> Thank you, I think I'll manage.
>
> > Using coccigrep, I think I've found all the places using
> > platform_device.resource directly. A large swath are Sparc drivers
> > which don't matter. The few that do matter I've prepared patches for
> > here[1]. Most of what I found were DT based drivers that copy
> > resources to a child platform device. That case will not work with
> > platform_get_irq() callers either unless the child device has it's DT
> > node set to the parent node which is the change I made.
> >
> Thank you for getting this done. Do you want me to include those along
> with my conversion patches?

No, I'll send them out.

> Any reason why we dont care for Sparc drivers?

Sparc does its own thing and doesn't use drivers/of/platform.c to
create devices. I'm sure we could modernize a bunch of them, but
that's not a blocker.

Rob

  reply	other threads:[~2021-12-10 14:20 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
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 [this message]
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=CAL_Jsq+jyqbhA1jpgZ+yTwWGvCMRu9VmgoDq8MDM9SMqJ-XSBw@mail.gmail.com \
    --to=robh+dt@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=maz@kernel.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --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.