[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNMnxAVn6Vy337Eq@sunil-laptop>
Date: Wed, 9 Aug 2023 11:14:36 +0530
From: Sunil V L <sunilvl@...tanamicro.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-doc@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
Jonathan Corbet <corbet@....net>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Daniel Scally <djrscally@...il.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Anup Patel <anup@...infault.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Robert Moore <robert.moore@...el.com>,
Haibo Xu <haibo1.xu@...el.com>,
Andrew Jones <ajones@...tanamicro.com>,
Conor Dooley <conor.dooley@...rochip.com>,
Atish Kumar Patra <atishp@...osinc.com>,
Anup Patel <apatel@...tanamicro.com>
Subject: Re: [RFC PATCH v1 11/21] swnode: Add support to create early during
boot
On Tue, Aug 08, 2023 at 02:17:22PM +0100, Marc Zyngier wrote:
> On Fri, 04 Aug 2023 09:11:05 +0100,
> Sunil V L <sunilvl@...tanamicro.com> wrote:
> >
> > Hi Andy,
> >
> > On Fri, Aug 04, 2023 at 09:09:16AM +0300, Andy Shevchenko wrote:
> > > On Thu, Aug 03, 2023 at 11:29:06PM +0530, Sunil V L wrote:
> > > > From: Anup Patel <apatel@...tanamicro.com>
> > > >
> > > > swnode framework can be used to create fwnode for interrupt
> > > > controllers.
> > >
> > > Why? What is this for?
> > > Can you elaborate? This commit message is poorly written...
> > >
> > > And why firmware node is not enough for ACPI case?
> > > I assume the fwnode in DT case is already provided by OF.
> > >
> > Thanks a lot for the review!.
> >
> > You are right, OF provides the fwnode for irqchip drivers. However, for
> > ACPI case, it is typically created using irq_domain_alloc_named_fwnode
> > or irq_domain_alloc_fwnode since these are not ACPI devices in the
> > namespace but from MADT. The fwnode created using
> > irq_domain_alloc_fwnode() is a simple one which doesn't support properties
> > similar to the one created by OF framework or software node framework.
> > Hence, lot of data from the MADT structures need to be cached as
> > separate structures in the drivers and also would need several ifdefs to
> > check for ACPI and some amount of code duplication is also required due
> > to the way DT driver gets the information vs ACPI.
> >
> > The beauty of software node framework is, it supports adding properties
> > and also is a supported fwnode type in __irq_domain_create().
>
> There is no beauty here. Only some extra bloat that we do not need.
>
> DT and ACPI exposes very different attributes. One describe the HW,
> the other one describe an OS abstraction. Pretending that you can
> summon both into the same infrastructure is a fallacy. You'll just end
> up with the cross product of both infrastructure, and pollute the rest
> of the kernel with pointless cruft.
>
Hi Marc,
Thank you very much for the feedback!. Sure, let me revert this approach
and do as you recommended in next version.
> > So, if we
> > can create the fwnode for these irqchip using software node, we can
> > attach the same properties and the actual irqchip driver which uses the
> > fwnode doesn't need to have any ACPI vs DT checks. Same driver will work
> > seamlessly on both DT and ACPI platforms. But the challenge is,
> > currently swnode expects to be created with sysfs which won't be
> > available during early boot when irqchip drivers need to be probed. So,
> > adding support to create without dependency on sysfs help us to reuse
> > the same framework for irqchip use case also.
>
> That's another fallacy.
>
> Most irqchips *DO NOT* need to be probed early. Only the root
> irqchip. Given that this series is about *secondary* interrupt
> controllers, they absolutely don't need to be probed early.
>
Since we created swnode for root irqchip also in this approach, we had
to support early creation. With your feedback, this is no longer
required.
> To be clear: I do not intend to merge anything that:
>
> - invents yet another way to "abstract" firmware interfaces
>
> - adds more "early probe" hacks for non-primary interrupt controllers
>
> I have already said that in response to Anup's AIA series, and this
> equally applies to this series.
>
In Anup's AIA v7 series, he has made non-primary controller drivers as
platform drivers which are not probed early.
Thanks,
Sunil
Powered by blists - more mailing lists