On Thu, Dec 9, 2021 at 7:16 PM Lad, Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote: > > On Thu, Dec 9, 2021 at 8:34 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > On Thu, Dec 9, 2021 at 5:35 AM Lad, Prabhakar > > <prabhakar.csengg@xxxxxxxxx> wrote: > > > > > > Hi Rob and Marc, > > > > > > On Thu, Dec 9, 2021 at 10:33 AM Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > > > > > > On Thu, 09 Dec 2021 10:00:44 +0000, > > > > "Lad, Prabhakar" <prabhakar.csengg@xxxxxxxxx> 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
