[PATCH V1 0/5] Fix some issues of irq controllers for dual-bridges scenario

[PATCH V1 0/5] Fix some issues of irq controllers for dual-bridges scenario

[Jianmin Lv]

In dual-bridges scenario, some bugs were found for irq
controllers drivers, so the patch serie is used to fix them.

Jianmin Lv (5):
  irqchip/loongson-eiointc: Fix returned value on parsing MADT
  irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent
  irqchip/loongson-pch-pic: Fix pch_pic_acpi_init calling
  irqchip/loongson-eiointc: Fix registration of syscore_ops
  irqchip/loongson-pch-pic: Fix registration of syscore_ops

 drivers/irqchip/irq-loongson-eiointc.c | 27 ++++++++++++++++----------
 drivers/irqchip/irq-loongson-pch-pic.c |  6 +++++-
 2 files changed, 22 insertions(+), 11 deletions(-)

-- 
2.31.1

[PATCH V1 1/5] irqchip/loongson-eiointc: Fix returned value on parsing MADT

[Jianmin Lv]

In pch_pic_parse_madt(), a NULL parent pointer will be
returned from acpi_get_vec_parent() for second pch-pic domain
related to second bridge while calling eiointc_acpi_init() at
first time, where the parent of it has not been initialized
yet, and will be initialized during second time calling
eiointc_acpi_init(). So, it's reasonable to return zero so
that failure of acpi_table_parse_madt() will be avoided, or else
acpi_cascade_irqdomain_init() will return and initialization of
followed pch_msi domain will be skipped.

Although it does not matter when pch_msi_parse_madt() returns
-EINVAL if no invalid parent is found, it's also reasonable to
return zero for that.

Change-Id: I4d278534999ec3e5c8db6d40155ba2665d9de86f
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
---
 drivers/irqchip/irq-loongson-eiointc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
index d15fd38c1756..62a632d73991 100644
--- a/drivers/irqchip/irq-loongson-eiointc.c
+++ b/drivers/irqchip/irq-loongson-eiointc.c
@@ -343,7 +343,7 @@ static int __init pch_pic_parse_madt(union acpi_subtable_headers *header,
 	if (parent)
 		return pch_pic_acpi_init(parent, pchpic_entry);
 
-	return -EINVAL;
+	return 0;
 }
 
 static int __init pch_msi_parse_madt(union acpi_subtable_headers *header,
@@ -355,7 +355,7 @@ static int __init pch_msi_parse_madt(union acpi_subtable_headers *header,
 	if (parent)
 		return pch_msi_acpi_init(parent, pchmsi_entry);
 
-	return -EINVAL;
+	return 0;
 }
 
 static int __init acpi_cascade_irqdomain_init(void)
-- 
2.31.1

[PATCH V1 2/5] irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent

[Jianmin Lv]

In eiointc_acpi_init(), a *eiointc* node is passed into
acpi_get_vec_parent() instead of a required *NUMA* node (on some chip
like 3C5000L, a *NUMA* node means a *eiointc* node, but on some chip
like 3C5000, a *NUMA* node contains 4 *eiointc* nodes), and node in
struct acpi_vector_group is essentially a *NUMA* node, which will
lead to no parent matched for passed *eiointc* node. so the patch
adjusts code to use *NUMA* node for parameter node of
acpi_set_vec_parent/acpi_get_vec_parent.

Change-Id: Iddd8423f9694cadc1ce28ee290c2e98ca17dfccc
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
---
 drivers/irqchip/irq-loongson-eiointc.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
index 62a632d73991..b165c27a3609 100644
--- a/drivers/irqchip/irq-loongson-eiointc.c
+++ b/drivers/irqchip/irq-loongson-eiointc.c
@@ -280,9 +280,6 @@ static void acpi_set_vec_parent(int node, struct irq_domain *parent, struct acpi
 {
 	int i;
 
-	if (cpu_has_flatmode)
-		node = cpu_to_node(node * CORES_PER_EIO_NODE);
-
 	for (i = 0; i < MAX_IO_PICS; i++) {
 		if (node == vec_group[i].node) {
 			vec_group[i].parent = parent;
@@ -349,8 +346,13 @@ static int __init pch_pic_parse_madt(union acpi_subtable_headers *header,
 static int __init pch_msi_parse_madt(union acpi_subtable_headers *header,
 					const unsigned long end)
 {
+	struct irq_domain *parent;
 	struct acpi_madt_msi_pic *pchmsi_entry = (struct acpi_madt_msi_pic *)header;
-	struct irq_domain *parent = acpi_get_vec_parent(eiointc_priv[nr_pics - 1]->node, msi_group);
+	int node = eiointc_priv[nr_pics - 1]->node;
+
+	if (cpu_has_flatmode)
+		node = cpu_to_node(node * CORES_PER_EIO_NODE);
+	parent = acpi_get_vec_parent(node, msi_group);
 
 	if (parent)
 		return pch_msi_acpi_init(parent, pchmsi_entry);
@@ -379,6 +381,7 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
 	int i, ret, parent_irq;
 	unsigned long node_map;
 	struct eiointc_priv *priv;
+	int node = acpi_eiointc->node;
 
 	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -421,8 +424,10 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
 				  "irqchip/loongarch/intc:starting",
 				  eiointc_router_init, NULL);
 
-	acpi_set_vec_parent(acpi_eiointc->node, priv->eiointc_domain, pch_group);
-	acpi_set_vec_parent(acpi_eiointc->node, priv->eiointc_domain, msi_group);
+	if (cpu_has_flatmode)
+		node = cpu_to_node(node * CORES_PER_EIO_NODE);
+	acpi_set_vec_parent(node, priv->eiointc_domain, pch_group);
+	acpi_set_vec_parent(node, priv->eiointc_domain, msi_group);
 	ret = acpi_cascade_irqdomain_init();
 
 	return ret;
-- 
2.31.1

[PATCH V1 3/5] irqchip/loongson-pch-pic: Fix pch_pic_acpi_init calling

[Jianmin Lv]

For dual-bridges scenario, pch_pic_acpi_init() will be called in
following path:

cpuintc_acpi_init
  acpi_cascade_irqdomain_init(in cpuintc driver)
    acpi_table_parse_madt
      eiointc_parse_madt
        eiointc_acpi_init /* this will be called two times corresponding
                             to parsing two eiointc entrys in MADT under
                             dual-bridges scenario*/
          acpi_cascade_irqdomain_init(in pch_pic driver)
            acpi_table_parse_madt
              pch_pic_parse_madt
                pch_pic_acpi_init /* this will be called depend on valid parent IRQ
                                     domain handle for one or two times corresponding
                                     to parsing two pchpic entrys in MADT druring
                                     calling eiointc_acpi_init() under dual-bridges
                                     scenario*/

During the first eiointc_acpi_init() calling, the pch_pic_acpi_init()
will be called just one time since only one valid parent IRQ domain
handle will be found for current eiointc IRQ domain.

During the second eiointc_acpi_init() calling, the pch_pic_acpi_init()
will be called two times since two valid parent IRQ domain handles
will be found. So in pch_pic_acpi_init(), we must have a reasonable
way to prevent from creating second same pch_pic IRQ domain.

The patch matches gsi base information in created pch_pic IRQ domains
to check if the target domain has been created to avoid the bug
mentioned above.

Change-Id: Iacba57be83dcbfe7f61b94632d472bccfaaddc22
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
---
 drivers/irqchip/irq-loongson-pch-pic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/irqchip/irq-loongson-pch-pic.c b/drivers/irqchip/irq-loongson-pch-pic.c
index 437f1af693d0..e3c698ca11e9 100644
--- a/drivers/irqchip/irq-loongson-pch-pic.c
+++ b/drivers/irqchip/irq-loongson-pch-pic.c
@@ -403,6 +403,9 @@ int __init pch_pic_acpi_init(struct irq_domain *parent,
 	int ret, vec_base;
 	struct fwnode_handle *domain_handle;
 
+	if (find_pch_pic(acpi_pchpic->gsi_base) >= 0)
+		return 0;
+
 	vec_base = acpi_pchpic->gsi_base - GSI_MIN_PCH_IRQ;
 
 	domain_handle = irq_domain_alloc_fwnode(&acpi_pchpic->address);
-- 
2.31.1

[PATCH V1 4/5] irqchip/loongson-eiointc: Fix registration of syscore_ops

[Jianmin Lv]

When support suspend/resume for loongson-eiointc, the syscore_ops is
registered twice in dual-bridges machines where there are two eiointc IRQ
domains. Repeated registration of an same syscore_ops broke syscore_ops_list.
Also, cpuhp_setup_state_nocalls is only needed to call for once. So the
patch will corret them.

Change-Id: I7a9060fa109baab5e9b155baa51f12e46633d304
Fixes: a90335c2dfb4 ("irqchip/loongson-eiointc: Add suspend/resume support")
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
---
 drivers/irqchip/irq-loongson-eiointc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
index b165c27a3609..e7e1201e61f2 100644
--- a/drivers/irqchip/irq-loongson-eiointc.c
+++ b/drivers/irqchip/irq-loongson-eiointc.c
@@ -419,10 +419,12 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
 	parent_irq = irq_create_mapping(parent, acpi_eiointc->cascade);
 	irq_set_chained_handler_and_data(parent_irq, eiointc_irq_dispatch, priv);
 
-	register_syscore_ops(&eiointc_syscore_ops);
-	cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_LOONGARCH_STARTING,
+	if (nr_pics == 1) {
+		register_syscore_ops(&eiointc_syscore_ops);
+		cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_LOONGARCH_STARTING,
 				  "irqchip/loongarch/intc:starting",
 				  eiointc_router_init, NULL);
+	}
 
 	if (cpu_has_flatmode)
 		node = cpu_to_node(node * CORES_PER_EIO_NODE);
-- 
2.31.1

[PATCH V1 5/5] irqchip/loongson-pch-pic: Fix registration of syscore_ops

[Jianmin Lv]

When support suspend/resume for loongson-pch-pic, the syscore_ops is
registered twice in dual-bridges machines where there are two pch-pic IRQ
domains. Repeated registration of an same syscore_ops broke syscore_ops_list,
so the patch will corret it.

Change-Id: Ib08e102931f1b90082d8eaa752287f60147bf777
Fixes: 1ed008a2c331 ("irqchip/loongson-pch-pic: Add suspend/resume support")
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
---
 drivers/irqchip/irq-loongson-pch-pic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-loongson-pch-pic.c b/drivers/irqchip/irq-loongson-pch-pic.c
index e3c698ca11e9..e5fe4d50be05 100644
--- a/drivers/irqchip/irq-loongson-pch-pic.c
+++ b/drivers/irqchip/irq-loongson-pch-pic.c
@@ -311,7 +311,8 @@ static int pch_pic_init(phys_addr_t addr, unsigned long size, int vec_base,
 	pch_pic_handle[nr_pics] = domain_handle;
 	pch_pic_priv[nr_pics++] = priv;
 
-	register_syscore_ops(&pch_pic_syscore_ops);
+	if (nr_pics == 1)
+		register_syscore_ops(&pch_pic_syscore_ops);
 
 	return 0;
 
-- 
2.31.1

Re: [PATCH V1 0/5] Fix some issues of irq controllers for dual-bridges scenario

[Huacai Chen]

Hi, Jianmin,

1, Please remove the Change-Id: lines in every patch;
2, Please Cc: stable@vger.kernel.org to make them be backported to
stable branch;
3, Maybe changing the order of Patch3/Patch4 is better.

Huacai

On Fri, Mar 24, 2023 at 2:09 PM Jianmin Lv <lvjianmin@loongson.cn> wrote:
>
> In dual-bridges scenario, some bugs were found for irq
> controllers drivers, so the patch serie is used to fix them.
>
> Jianmin Lv (5):
>   irqchip/loongson-eiointc: Fix returned value on parsing MADT
>   irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent
>   irqchip/loongson-pch-pic: Fix pch_pic_acpi_init calling
>   irqchip/loongson-eiointc: Fix registration of syscore_ops
>   irqchip/loongson-pch-pic: Fix registration of syscore_ops
>
>  drivers/irqchip/irq-loongson-eiointc.c | 27 ++++++++++++++++----------
>  drivers/irqchip/irq-loongson-pch-pic.c |  6 +++++-
>  2 files changed, 22 insertions(+), 11 deletions(-)
>
> --
> 2.31.1
>
>

Re: [PATCH V1 0/5] Fix some issues of irq controllers for dual-bridges scenario

[Jianmin Lv]

Hi, Huacai

Thanks very much for your reminder and suggestion, I'll change them in 
next version.

On 2023/3/24 下午2:32, Huacai Chen wrote:
> Hi, Jianmin,
> 
> 1, Please remove the Change-Id: lines in every patch;
> 2, Please Cc: stable@vger.kernel.org to make them be backported to
> stable branch;
> 3, Maybe changing the order of Patch3/Patch4 is better.
> 
> Huacai
> 
> On Fri, Mar 24, 2023 at 2:09 PM Jianmin Lv <lvjianmin@loongson.cn> wrote:
>>
>> In dual-bridges scenario, some bugs were found for irq
>> controllers drivers, so the patch serie is used to fix them.
>>
>> Jianmin Lv (5):
>>    irqchip/loongson-eiointc: Fix returned value on parsing MADT
>>    irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent
>>    irqchip/loongson-pch-pic: Fix pch_pic_acpi_init calling
>>    irqchip/loongson-eiointc: Fix registration of syscore_ops
>>    irqchip/loongson-pch-pic: Fix registration of syscore_ops
>>
>>   drivers/irqchip/irq-loongson-eiointc.c | 27 ++++++++++++++++----------
>>   drivers/irqchip/irq-loongson-pch-pic.c |  6 +++++-
>>   2 files changed, 22 insertions(+), 11 deletions(-)
>>
>> --
>> 2.31.1
>>
>>
> _______________________________________________
> Loongson-kernel mailing list -- loongson-kernel@lists.loongnix.cn
> To unsubscribe send an email to loongson-kernel-leave@lists.loongnix.cn
> 

Re: [PATCH V1 2/5] irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent

[Marc Zyngier]

On Fri, 24 Mar 2023 06:08:51 +0000,
Jianmin Lv <lvjianmin@loongson.cn> wrote:
> 
> In eiointc_acpi_init(), a *eiointc* node is passed into
> acpi_get_vec_parent() instead of a required *NUMA* node (on some chip
> like 3C5000L, a *NUMA* node means a *eiointc* node, but on some chip
> like 3C5000, a *NUMA* node contains 4 *eiointc* nodes), and node in
> struct acpi_vector_group is essentially a *NUMA* node, which will
> lead to no parent matched for passed *eiointc* node. so the patch
> adjusts code to use *NUMA* node for parameter node of
> acpi_set_vec_parent/acpi_get_vec_parent.
> 
> Change-Id: Iddd8423f9694cadc1ce28ee290c2e98ca17dfccc
> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
> ---
>  drivers/irqchip/irq-loongson-eiointc.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
> index 62a632d73991..b165c27a3609 100644
> --- a/drivers/irqchip/irq-loongson-eiointc.c
> +++ b/drivers/irqchip/irq-loongson-eiointc.c
> @@ -280,9 +280,6 @@ static void acpi_set_vec_parent(int node, struct irq_domain *parent, struct acpi
>  {
>  	int i;
>  
> -	if (cpu_has_flatmode)
> -		node = cpu_to_node(node * CORES_PER_EIO_NODE);
> -
>  	for (i = 0; i < MAX_IO_PICS; i++) {
>  		if (node == vec_group[i].node) {
>  			vec_group[i].parent = parent;
> @@ -349,8 +346,13 @@ static int __init pch_pic_parse_madt(union acpi_subtable_headers *header,
>  static int __init pch_msi_parse_madt(union acpi_subtable_headers *header,
>  					const unsigned long end)
>  {
> +	struct irq_domain *parent;
>  	struct acpi_madt_msi_pic *pchmsi_entry = (struct acpi_madt_msi_pic *)header;
> -	struct irq_domain *parent = acpi_get_vec_parent(eiointc_priv[nr_pics - 1]->node, msi_group);
> +	int node = eiointc_priv[nr_pics - 1]->node;
> +
> +	if (cpu_has_flatmode)
> +		node = cpu_to_node(node * CORES_PER_EIO_NODE);

This is a bit unreadable. I'd rather see:

	int node;

	if (cpu_has_flatmode)
		node = ....;
	else
		node = ....;

which makes it easy to detect the use of an uninitialised 'node'
rather than using the wrong default variable.

> +	parent = acpi_get_vec_parent(node, msi_group);
>  
>  	if (parent)
>  		return pch_msi_acpi_init(parent, pchmsi_entry);
> @@ -379,6 +381,7 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
>  	int i, ret, parent_irq;
>  	unsigned long node_map;
>  	struct eiointc_priv *priv;
> +	int node = acpi_eiointc->node;
>  
>  	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>  	if (!priv)
> @@ -421,8 +424,10 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
>  				  "irqchip/loongarch/intc:starting",
>  				  eiointc_router_init, NULL);
>  
> -	acpi_set_vec_parent(acpi_eiointc->node, priv->eiointc_domain, pch_group);
> -	acpi_set_vec_parent(acpi_eiointc->node, priv->eiointc_domain, msi_group);
> +	if (cpu_has_flatmode)
> +		node = cpu_to_node(node * CORES_PER_EIO_NODE);
> +	acpi_set_vec_parent(node, priv->eiointc_domain, pch_group);
> +	acpi_set_vec_parent(node, priv->eiointc_domain, msi_group);
>  	ret = acpi_cascade_irqdomain_init();
>  
>  	return ret;

Same thing here.

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH V1 1/5] irqchip/loongson-eiointc: Fix returned value on parsing MADT

[Marc Zyngier]

On Fri, 24 Mar 2023 06:08:50 +0000,
Jianmin Lv <lvjianmin@loongson.cn> wrote:
> 
> In pch_pic_parse_madt(), a NULL parent pointer will be
> returned from acpi_get_vec_parent() for second pch-pic domain
> related to second bridge while calling eiointc_acpi_init() at
> first time, where the parent of it has not been initialized
> yet, and will be initialized during second time calling
> eiointc_acpi_init(). So, it's reasonable to return zero so
> that failure of acpi_table_parse_madt() will be avoided, or else
> acpi_cascade_irqdomain_init() will return and initialization of
> followed pch_msi domain will be skipped.
> 
> Although it does not matter when pch_msi_parse_madt() returns
> -EINVAL if no invalid parent is found, it's also reasonable to
> return zero for that.
> 
> Change-Id: I4d278534999ec3e5c8db6d40155ba2665d9de86f
> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
> ---
>  drivers/irqchip/irq-loongson-eiointc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
> index d15fd38c1756..62a632d73991 100644
> --- a/drivers/irqchip/irq-loongson-eiointc.c
> +++ b/drivers/irqchip/irq-loongson-eiointc.c
> @@ -343,7 +343,7 @@ static int __init pch_pic_parse_madt(union acpi_subtable_headers *header,
>  	if (parent)
>  		return pch_pic_acpi_init(parent, pchpic_entry);
>  
> -	return -EINVAL;
> +	return 0;

Why can't you detect this particular case instead of blindly
suppressing the error?

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH V1 1/5] irqchip/loongson-eiointc: Fix returned value on parsing MADT

[Jianmin Lv]

On 2023/3/24 下午11:36, Marc Zyngier wrote:
> On Fri, 24 Mar 2023 06:08:50 +0000,
> Jianmin Lv <lvjianmin@loongson.cn> wrote:
>>
>> In pch_pic_parse_madt(), a NULL parent pointer will be
>> returned from acpi_get_vec_parent() for second pch-pic domain
>> related to second bridge while calling eiointc_acpi_init() at
>> first time, where the parent of it has not been initialized
>> yet, and will be initialized during second time calling
>> eiointc_acpi_init(). So, it's reasonable to return zero so
>> that failure of acpi_table_parse_madt() will be avoided, or else
>> acpi_cascade_irqdomain_init() will return and initialization of
>> followed pch_msi domain will be skipped.
>>
>> Although it does not matter when pch_msi_parse_madt() returns
>> -EINVAL if no invalid parent is found, it's also reasonable to
>> return zero for that.
>>
>> Change-Id: I4d278534999ec3e5c8db6d40155ba2665d9de86f
>> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
>> ---
>>   drivers/irqchip/irq-loongson-eiointc.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
>> index d15fd38c1756..62a632d73991 100644
>> --- a/drivers/irqchip/irq-loongson-eiointc.c
>> +++ b/drivers/irqchip/irq-loongson-eiointc.c
>> @@ -343,7 +343,7 @@ static int __init pch_pic_parse_madt(union acpi_subtable_headers *header,
>>   	if (parent)
>>   		return pch_pic_acpi_init(parent, pchpic_entry);
>>   
>> -	return -EINVAL;
>> +	return 0;
> 
> Why can't you detect this particular case instead of blindly
> suppressing the error?
> 

For dual-bridges scenario, parent handle for pch_pic IRQ domain will be 
set by acpi_set_vec_parent() during each eiointc initialization. And
the parent handle for one pch_pic will be set during *first* eiointc
entry parsing, and the parent handle for another pch_pic will be
set during *second* eiointc entry parsing. But two pch_pic entries
will be parsed during each eiointc entry parsing, so a NULL parent
pointer must be returned druing first eiointc initialization, which
is reasonable and should not be treated as an error.

The calling stack of pch_pic_parse_madt (where acpi_get_vec_parent is 
called to get parent handle) is like this:

cpuintc_acpi_init
   acpi_cascade_irqdomain_init(in cpuintc driver)
     acpi_table_parse_madt
       eiointc_parse_madt
         eiointc_acpi_init /* this will be called two times 
corresponding  to parsing two eiointc entries in MADT under dual-bridges 
scenario*/
           acpi_set_vec_parent /* set parent handle for one pch_pic 
during first eiointc entry parsing, and set parent handle for another 
pch_pic during second eiointc entry parsing*/
             acpi_cascade_irqdomain_init(in eiointc driver)
               acpi_table_parse_madt
                 pch_pic_parse_madt /* this will be called twice because 
of two pchpic entries, and only one valid parent handle will be returned 
from acpi_get_vec_parent() during first eiointc entry parsing (another 
parent handle is not set yet), so a NULL parent pointer must be returned 
during first eiointc entry parsing, which is reasonable and should not 
be treated as an error.*/

Thanks!

> 	M.
> 

Re: [PATCH V1 2/5] irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent

[Jianmin Lv]

On 2023/3/24 下午11:34, Marc Zyngier wrote:
> On Fri, 24 Mar 2023 06:08:51 +0000,
> Jianmin Lv <lvjianmin@loongson.cn> wrote:
>>
>> In eiointc_acpi_init(), a *eiointc* node is passed into
>> acpi_get_vec_parent() instead of a required *NUMA* node (on some chip
>> like 3C5000L, a *NUMA* node means a *eiointc* node, but on some chip
>> like 3C5000, a *NUMA* node contains 4 *eiointc* nodes), and node in
>> struct acpi_vector_group is essentially a *NUMA* node, which will
>> lead to no parent matched for passed *eiointc* node. so the patch
>> adjusts code to use *NUMA* node for parameter node of
>> acpi_set_vec_parent/acpi_get_vec_parent.
>>
>> Change-Id: Iddd8423f9694cadc1ce28ee290c2e98ca17dfccc
>> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn>
>> ---
>>   drivers/irqchip/irq-loongson-eiointc.c | 17 +++++++++++------
>>   1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-loongson-eiointc.c b/drivers/irqchip/irq-loongson-eiointc.c
>> index 62a632d73991..b165c27a3609 100644
>> --- a/drivers/irqchip/irq-loongson-eiointc.c
>> +++ b/drivers/irqchip/irq-loongson-eiointc.c
>> @@ -280,9 +280,6 @@ static void acpi_set_vec_parent(int node, struct irq_domain *parent, struct acpi
>>   {
>>   	int i;
>>   
>> -	if (cpu_has_flatmode)
>> -		node = cpu_to_node(node * CORES_PER_EIO_NODE);
>> -
>>   	for (i = 0; i < MAX_IO_PICS; i++) {
>>   		if (node == vec_group[i].node) {
>>   			vec_group[i].parent = parent;
>> @@ -349,8 +346,13 @@ static int __init pch_pic_parse_madt(union acpi_subtable_headers *header,
>>   static int __init pch_msi_parse_madt(union acpi_subtable_headers *header,
>>   					const unsigned long end)
>>   {
>> +	struct irq_domain *parent;
>>   	struct acpi_madt_msi_pic *pchmsi_entry = (struct acpi_madt_msi_pic *)header;
>> -	struct irq_domain *parent = acpi_get_vec_parent(eiointc_priv[nr_pics - 1]->node, msi_group);
>> +	int node = eiointc_priv[nr_pics - 1]->node;
>> +
>> +	if (cpu_has_flatmode)
>> +		node = cpu_to_node(node * CORES_PER_EIO_NODE);
> 
> This is a bit unreadable. I'd rather see:
> 
> 	int node;
> 
> 	if (cpu_has_flatmode)
> 		node = ....;
> 	else
> 		node = ....;
> 
> which makes it easy to detect the use of an uninitialised 'node'
> rather than using the wrong default variable.
> 
>> +	parent = acpi_get_vec_parent(node, msi_group);
>>   
>>   	if (parent)
>>   		return pch_msi_acpi_init(parent, pchmsi_entry);
>> @@ -379,6 +381,7 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
>>   	int i, ret, parent_irq;
>>   	unsigned long node_map;
>>   	struct eiointc_priv *priv;
>> +	int node = acpi_eiointc->node;
>>   
>>   	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>>   	if (!priv)
>> @@ -421,8 +424,10 @@ int __init eiointc_acpi_init(struct irq_domain *parent,
>>   				  "irqchip/loongarch/intc:starting",
>>   				  eiointc_router_init, NULL);
>>   
>> -	acpi_set_vec_parent(acpi_eiointc->node, priv->eiointc_domain, pch_group);
>> -	acpi_set_vec_parent(acpi_eiointc->node, priv->eiointc_domain, msi_group);
>> +	if (cpu_has_flatmode)
>> +		node = cpu_to_node(node * CORES_PER_EIO_NODE);
>> +	acpi_set_vec_parent(node, priv->eiointc_domain, pch_group);
>> +	acpi_set_vec_parent(node, priv->eiointc_domain, msi_group);
>>   	ret = acpi_cascade_irqdomain_init();
>>   
>>   	return ret;
> 
> Same thing here.
> 

Ok, I'll change them  in next version.

Thanks!

> 	M.
>