public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Sunil V L <sunilvl@ventanamicro.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-serial@vger.kernel.org, acpica-devel@lists.linux.dev,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Len Brown" <lenb@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Anup Patel" <anup@brainfault.org>,
	"Samuel Holland" <samuel.holland@sifive.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	"Robert Moore" <robert.moore@intel.com>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Atish Kumar Patra" <atishp@rivosinc.com>,
	"Andrei Warkentin" <andrei.warkentin@intel.com>,
	"Haibo1 Xu" <haibo1.xu@intel.com>,
	"Björn Töpel" <bjorn@kernel.org>
Subject: Re: [PATCH v5 13/17] irqchip/riscv-intc: Add ACPI support for AIA
Date: Mon, 27 May 2024 10:09:26 +0530	[thread overview]
Message-ID: <ZlQOfrMHHaGV0cDg@sunil-laptop> (raw)
In-Reply-To: <874jaofbfp.ffs@tglx>

Hi Thomas,

On Thu, May 23, 2024 at 11:47:06PM +0200, Thomas Gleixner wrote:
> On Wed, May 01 2024 at 17:47, Sunil V L wrote:
> > diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> > index 9e71c4428814..af7a2f78f0ee 100644
> > --- a/drivers/irqchip/irq-riscv-intc.c
> > +++ b/drivers/irqchip/irq-riscv-intc.c
> > @@ -249,14 +249,105 @@ IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init);
> >  IRQCHIP_DECLARE(andes, "andestech,cpu-intc", riscv_intc_init);
> >  
> >  #ifdef CONFIG_ACPI
> > +struct rintc_data {
> > +	u32 ext_intc_id;
> > +	unsigned long hart_id;
> > +	u64 imsic_addr;
> > +	u32 imsic_size;
> 
> https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#struct-declarations-and-initializers
>
Sure, thanks!
 
> > +};
> > +
> > +static u32 nr_rintc;
> > +static struct rintc_data *rintc_acpi_data[NR_CPUS];
> > +
> > +int acpi_get_intc_index_hartid(u32 index, unsigned long *hartid)
> 
> Why int? All of these functions have strictly boolean return values:
> success = true, fail = false, no?
> 
> Either bool or get rid of the pointer and let the function return
> either the real hart id or an invalid one.
>
Sure. I just tried to keep it similar to the parent function. But let me
go with your suggestion in the next revision.
 
> > +{
> > +	if (index >= nr_rintc)
> > +		return -1;
> > +
> > +	*hartid = rintc_acpi_data[index]->hart_id;
> > +	return 0;
> 
> I.e.
> 
> 	return index >= nr_rintc ? rintc_acpi_data[index]->hart_id : INVALID_HART_ID;
> 
Sure.

> > +int acpi_get_ext_intc_parent_hartid(u8 id, u32 idx, unsigned long *hartid)
> > +{
> > +	int i, j = 0;
> > +
> > +	for (i = 0; i < nr_rintc; i++) {
> > +		if (APLIC_PLIC_ID(rintc_acpi_data[i]->ext_intc_id) == id) {
> > +			if (idx == j) {
> > +				*hartid = rintc_acpi_data[i]->hart_id;
> > +				return 0;
> > +			}
> > +			j++;
> > +		}
> > +	}
> > +
> > +	return -1;
> > +}
> > +
> > +void acpi_get_plic_nr_contexts(u8 id, int *nr_contexts)
> > +{
> > +	int i, j = 0;
> > +
> > +	for (i = 0; i < nr_rintc; i++) {
> > +		if (APLIC_PLIC_ID(rintc_acpi_data[i]->ext_intc_id) == id)
> > +			j++;
> > +	}
> > +
> > +	*nr_contexts = j;
> > +}
> > +
> > +int acpi_get_plic_context(u8 id, u32 idx, int *context_id)
> > +{
> > +	int i, j = 0;
> > +
> > +	for (i = 0; i < nr_rintc; i++) {
> > +		if (APLIC_PLIC_ID(rintc_acpi_data[i]->ext_intc_id) == id) {
> > +			if (idx == j) {
> > +				*context_id = IDC_CONTEXT_ID(rintc_acpi_data[i]->ext_intc_id);
> > +				return 0;
> > +			}
> > +
> > +			j++;
> > +		}
> > +	}
> 
> So that's the third incarnation of the same loop with the truly self
> explaining variable and argument names.
> 
>     j is actually the index of the context which is associated to a
>     given PLIC ID.
> 
>     idx is the context index to search for
> 
> Right? So why can't these things be named in a way which makes the
> intent of the code clear?
> 
> Also why are all the arguments u8/u32? There is no hardware
> involved. Simple 'unsigned int' is just fine and the u8/u32 is not bying
> you anything here.
> 
> Aside of that these ugly macros can be completely avoided and the code
> can be written without a copy & pasta orgy.
> 
> struct rintc_data {
> 	union {
> 		u32		ext_intc_id;
>                 struct {
>                 	u32	context_id	: 16,
>                         			:  8,
>                         	aplic_plic_id	:  8;
>                 }
>         };
> 	unsigned long		hart_id;
> 	u64			imsic_addr;
> 	u32			imsic_size;
> };
> 
> #define for_each_matching_plic(_plic, _plic_id)				\
> 	for (_plic = 0; _plic < nr_rintc; _plict++)			\
>         	if (rintc_acpi_data[_plic]->aplic_plic_id != _plic_id)	\
>                 	continue;					\
>                 else
> 
> unsigned int acpi_get_plic_nr_contexts(unsigned int plic_id)
> {
> 	unsigned int nctx = 0;
> 
> 	for_each_matching_plic(plic, plic_id)
> 		nctx++;
> 
> 	return nctx;
> }
> 
> static struct rintc_data *get_plic_context(unsigned int plic_id, unsigned int ctxt_idx)
> {
> 	unsigned int ctxt = 0;
> 
> 	for_each_matching_plic(plic, plic_id) {
>         	if (ctxt == ctxt_idx)
>                 	return rintc_acpi_data + plic;
>         }
>         return NULL;
> }
> 
> unsigned long acpi_get_ext_intc_parent_hartid(unsigned int plic_id, unsigned int ctxt_idx)
> {
>         struct rintc_data *data = get_plic_context(plic_id, ctxt_idx);
> 
>         return data ? data->hart_id : INVALID_HART_ID;
> }
> 
> unsigned int acpi_get_plic_context(unsigned int plic_id, unsigned int ctxt_idx)
> {
>         struct rintc_data *data = get_plic_context(plic_id, ctxt_idx);
> 
>         return data ? data->context_id : INVALID_CONTEXT;
> }
> 
> Or something like that. Hmm?
>
Nice!. Yes, this is better. Thanks a lot for the suggestion. Let me
update in the next revision.
 
> > +int acpi_get_imsic_mmio_info(u32 index, struct resource *res)
> > +{
> > +	if (index >= nr_rintc)
> > +		return -1;
> > +
> > +	res->start = rintc_acpi_data[index]->imsic_addr;
> > +	res->end = res->start + rintc_acpi_data[index]->imsic_size - 1;
> > +	res->flags = IORESOURCE_MEM;
> > +	return 0;
> > +}
> > +
> > +static struct fwnode_handle *ext_entc_get_gsi_domain_id(u32 gsi)
> > +{
> > +	return riscv_acpi_get_gsi_domain_id(gsi);
> > +}
> 
> This wrapper is required because using riscv_acpi_get_gsi_domain_id()
> directly is too obvious, right?
>
:-). Let me remove it.
 
> >  static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
> >  				       const unsigned long end)
> >  {
> > -	struct fwnode_handle *fn;
> >  	struct acpi_madt_rintc *rintc;
> > +	struct fwnode_handle *fn;
> > +	int rc;
> >  
> >  	rintc = (struct acpi_madt_rintc *)header;
> > +	rintc_acpi_data[nr_rintc] = kzalloc(sizeof(*rintc_acpi_data[0]), GFP_KERNEL);
> > +	if (!rintc_acpi_data[nr_rintc])
> > +		return -ENOMEM;
> > +
> > +	rintc_acpi_data[nr_rintc]->ext_intc_id = rintc->ext_intc_id;
> > +	rintc_acpi_data[nr_rintc]->hart_id = rintc->hart_id;
> > +	rintc_acpi_data[nr_rintc]->imsic_addr = rintc->imsic_addr;
> > +	rintc_acpi_data[nr_rintc]->imsic_size = rintc->imsic_size;
> > +	nr_rintc++;
> >  
> >  	/*
> >  	 * The ACPI MADT will have one INTC for each CPU (or HART)
> > @@ -273,7 +364,14 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
> >  		return -ENOMEM;
> >  	}
> >  
> > -	return riscv_intc_init_common(fn, &riscv_intc_chip);
> > +	rc = riscv_intc_init_common(fn, &riscv_intc_chip);
> > +	if (rc) {
> > +		irq_domain_free_fwnode(fn);
> > +		return rc;
> > +	}
> 
> This looks like a completely unrelated bug fix. Please don't mix functional
> changes and fixes.
> 
Makes sense. Let me create separate patch.

Thanks a lot for the review!
Sunil

  reply	other threads:[~2024-05-27  4:39 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-01 12:17 [PATCH v5 00/17] RISC-V: ACPI: Add external interrupt controller support Sunil V L
2024-05-01 12:17 ` [PATCH v5 01/17] arm64: PCI: Migrate ACPI related functions to pci-acpi.c Sunil V L
2024-05-01 12:59   ` Will Deacon
2024-05-02  9:22   ` Andy Shevchenko
2024-05-02  9:56     ` Sunil V L
2024-05-01 12:17 ` [PATCH v5 02/17] ACPI: scan: Add a weak function to reorder the IRQCHIP probe Sunil V L
2024-05-01 12:17 ` [PATCH v5 03/17] ACPI: bus: Add acpi_riscv_init function Sunil V L
2024-05-02  9:24   ` Andy Shevchenko
2024-05-02 10:02     ` Sunil V L
2024-05-02 10:12       ` Sudeep Holla
2024-05-02 10:19         ` Andy Shevchenko
2024-05-02 11:00           ` Sunil V L
2024-05-01 12:17 ` [PATCH v5 04/17] ACPI: scan: Refactor dependency creation Sunil V L
2024-05-02  9:20   ` Andy Shevchenko
2024-05-02  9:55     ` Sunil V L
2024-05-01 12:17 ` [PATCH v5 05/17] ACPI: scan: Add RISC-V interrupt controllers to honor list Sunil V L
2024-05-01 12:17 ` [PATCH v5 06/17] ACPI: scan: Define weak function to populate dependencies Sunil V L
2024-05-01 12:17 ` [PATCH v5 07/17] ACPI: bus: Add RINTC IRQ model for RISC-V Sunil V L
2024-05-23 21:59   ` Bjorn Helgaas
2024-05-27  4:35     ` Sunil V L
2024-05-01 12:17 ` [PATCH v5 08/17] ACPI: pci_link: Clear the dependencies after probe Sunil V L
2024-05-01 16:56   ` Bjorn Helgaas
2024-05-02  9:25     ` Andy Shevchenko
2024-05-02  9:32       ` Sunil V L
2024-05-01 12:17 ` [PATCH v5 09/17] ACPI: RISC-V: Implement PCI related functionality Sunil V L
2024-05-01 12:17 ` [PATCH v5 10/17] ACPI: RISC-V: Implement function to reorder irqchip probe entries Sunil V L
2024-05-01 12:17 ` [PATCH v5 11/17] ACPI: RISC-V: Initialize GSI mapping structures Sunil V L
2024-05-01 12:17 ` [PATCH v5 12/17] ACPI: RISC-V: Implement function to add implicit dependencies Sunil V L
2024-05-01 12:17 ` [PATCH v5 13/17] irqchip/riscv-intc: Add ACPI support for AIA Sunil V L
2024-05-23 21:47   ` Thomas Gleixner
2024-05-27  4:39     ` Sunil V L [this message]
2024-05-01 12:17 ` [PATCH v5 14/17] irqchip/riscv-imsic: Add ACPI support Sunil V L
2024-05-23 22:00   ` Thomas Gleixner
2024-05-27  4:52     ` Sunil V L
2024-05-01 12:17 ` [PATCH v5 15/17] irqchip/riscv-aplic: " Sunil V L
2024-05-01 12:17 ` [PATCH v5 16/17] irqchip/sifive-plic: " Sunil V L
2024-05-01 12:17 ` [PATCH v5 17/17] serial: 8250: Add 8250_acpi driver Sunil V L
2024-05-02  9:17   ` Andy Shevchenko
2024-05-02  9:50     ` Sunil V L
2024-05-02 10:09       ` Andy Shevchenko
2024-05-02 11:20         ` Sunil V L
2024-05-02 15:35           ` Andy Shevchenko
2024-05-03 13:59             ` Sunil V L
2024-05-03 15:32               ` Andy Shevchenko
2024-05-06 11:45                 ` Sunil V L
2024-05-04 15:53   ` Greg Kroah-Hartman

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=ZlQOfrMHHaGV0cDg@sunil-laptop \
    --to=sunilvl@ventanamicro.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=ajones@ventanamicro.com \
    --cc=andrei.warkentin@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=atishp@rivosinc.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=conor.dooley@microchip.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=haibo1.xu@intel.com \
    --cc=jirislaby@kernel.org \
    --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=linux-riscv@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=paul.walmsley@sifive.com \
    --cc=rafael@kernel.org \
    --cc=robert.moore@intel.com \
    --cc=samuel.holland@sifive.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox