All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	Robert Moore <robert.moore@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Hanjun Guo <guohanjun@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>, <linux-acpi@vger.kernel.org>,
	<acpica-devel@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v2 3/7] irqdomain: Add parent field to struct irqchip_fwid
Date: Wed, 7 Jan 2026 10:04:52 +0000	[thread overview]
Message-ID: <20260107100452.00004b6f@huawei.com> (raw)
In-Reply-To: <aV4gH/yHaOmOtK0J@lpieralisi>

On Wed, 7 Jan 2026 09:58:07 +0100
Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:

> On Mon, Jan 05, 2026 at 12:01:08PM +0000, Jonathan Cameron wrote:
> > On Thu, 18 Dec 2025 11:14:29 +0100
> > Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >   
> > > The GICv5 driver IRQ domain hierarchy requires adding a parent field to
> > > struct irqchip_fwid so that core code can reference a fwnode_handle parent
> > > for a given fwnode.
> > > 
> > > Add a parent field to struct irqchip_fwid and update the related kernel API
> > > functions to initialize and handle it.
> > > 
> > > Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Marc Zyngier <maz@kernel.org>  
> > Hi Lorenzo,
> > 
> > Happy new year.  
> 
> Happy New Year !
> 
> > > ---
> > >  include/linux/irqdomain.h | 30 ++++++++++++++++++++++++++----
> > >  kernel/irq/irqdomain.c    | 14 +++++++++++++-
> > >  2 files changed, 39 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> > > index 62f81bbeb490..b9df84b447a1 100644
> > > --- a/include/linux/irqdomain.h
> > > +++ b/include/linux/irqdomain.h
> > > @@ -257,7 +257,8 @@ static inline void irq_domain_set_pm_device(struct irq_domain *d, struct device
> > >  
> > >  #ifdef CONFIG_IRQ_DOMAIN
> > >  struct fwnode_handle *__irq_domain_alloc_fwnode(unsigned int type, int id,
> > > -						const char *name, phys_addr_t *pa);
> > > +						const char *name, phys_addr_t *pa,
> > > +						struct fwnode_handle *parent);
> > >  
> > >  enum {
> > >  	IRQCHIP_FWNODE_REAL,
> > > @@ -267,18 +268,39 @@ enum {
> > >  
> > >  static inline struct fwnode_handle *irq_domain_alloc_named_fwnode(const char *name)
> > >  {
> > > -	return __irq_domain_alloc_fwnode(IRQCHIP_FWNODE_NAMED, 0, name, NULL);
> > > +	return __irq_domain_alloc_fwnode(IRQCHIP_FWNODE_NAMED, 0, name, NULL, NULL);
> > > +}
> > > +
> > > +static inline
> > > +struct fwnode_handle *irq_domain_alloc_named_fwnode_parent(const char *name,
> > > +							   struct fwnode_handle *parent)  
> > 
> > The name of this makes me think it's allocating the named fwnode parent, rather that
> > the named fwnode + setting it's parent.
> > 
> > There aren't all that many calls to irq_domain_named_fwnode(), maybe to avoid challenge
> > of a new name, just add the parameter to all of them? (25ish)  Mind you the current
> > pattern for similar cases is a helper, so maybe not.  
> 
> Similar cases ? Have you got anything specific I can look into ?

I meant all the different irq_domain_alloc_xxxxx variants that call
__irq_domain_alloc_fwnode() with a subset of parameters set to NULL.

That seems to say there is a precedence for making the presence of the parameter
part of the name rather than requiring callers to set the ones they don't want to
NULL.  So it argues for a helper like this one just for consistency.

> 
> > Or go with something similar to named and have
> > 
> > irq_domain_alloc_named_parented_fwnode()?  
> 
> Or I can add a set_parent() helper (though that's a bit of churn IMO) ?
> 
> If Thomas has a preference I will follow that, all of the above is doable
> for me.

Agreed. Let's see what Thomas prefers (i.e. make the decision his problem ;)

Jonathan

> 
> > I'm not that bothered though if you think the current naming is the best we can do.  
> 
> I think you have a point - as per my comment above.
> 
> Thanks,
> Lorenzo
> 
> > Jonathan
> >   
> > > +{
> > > +	return __irq_domain_alloc_fwnode(IRQCHIP_FWNODE_NAMED, 0, name, NULL, parent);
> > >  }  
> > 
> >   
> 


  reply	other threads:[~2026-01-07 10:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 10:14 [PATCH v2 0/7] irqchip/gic-v5: Code first ACPI boot support Lorenzo Pieralisi
2025-12-18 10:14 ` [PATCH v2 1/7] ACPICA: Add GICv5 MADT structures Lorenzo Pieralisi
2025-12-18 10:14 ` [PATCH v2 2/7] ACPICA: Add Arm IORT IWB node definitions Lorenzo Pieralisi
2025-12-18 10:14 ` [PATCH v2 3/7] irqdomain: Add parent field to struct irqchip_fwid Lorenzo Pieralisi
2026-01-05 12:01   ` Jonathan Cameron
2026-01-07  8:58     ` Lorenzo Pieralisi
2026-01-07 10:04       ` Jonathan Cameron [this message]
2026-01-07 17:31         ` Lorenzo Pieralisi
2026-01-13  9:37           ` Thomas Gleixner
2026-01-13 11:04         ` Lorenzo Pieralisi
2025-12-18 10:14 ` [PATCH v2 4/7] PCI/MSI: Make the pci_msi_map_rid_ctlr_node() interface firmware agnostic Lorenzo Pieralisi
2026-01-05 12:21   ` Jonathan Cameron
2026-01-07  9:23     ` Lorenzo Pieralisi
2026-01-05 17:35   ` Bjorn Helgaas
2025-12-18 10:14 ` [PATCH v2 5/7] irqchip/gic-v5: Add ACPI IRS probing Lorenzo Pieralisi
2026-01-05 13:24   ` Jonathan Cameron
2026-01-08 16:22     ` Lorenzo Pieralisi
2025-12-18 10:14 ` [PATCH v2 6/7] irqchip/gic-v5: Add ACPI ITS probing Lorenzo Pieralisi
2026-01-05 13:55   ` Jonathan Cameron
2026-01-08 16:13     ` Lorenzo Pieralisi
2025-12-18 10:14 ` [PATCH v2 7/7] irqchip/gic-v5: Add ACPI IWB probing Lorenzo Pieralisi
2026-01-05 15:35   ` Jonathan Cameron
2026-01-08 16:12     ` Lorenzo Pieralisi
2026-01-14 15:56 ` [PATCH v2 0/7] irqchip/gic-v5: Code first ACPI boot support Rafael J. Wysocki
2026-01-14 17:03   ` Lorenzo Pieralisi

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=20260107100452.00004b6f@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=bhelgaas@google.com \
    --cc=guohanjun@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robert.moore@intel.com \
    --cc=sudeep.holla@arm.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.