x86/ioapic: Fix fallout from IRQ domain conversion
PATCH 1/1 x86/ioapic: Fix fallout from IRQ domain conversion
When I/O APIC support was converted to the generic IRQ domain code, various things were broken. First, the number of interrupts required for an I/O APIC can be dynamically obtained from the mp_ioapic_gsi structure instead of hardcoded to 32. Furthermore, the legacy IRQ domain requires the irq_domain_ops.map() function to be implemented, which it currently isn't. This function can be empty because all the programming is done in io_apic_setup_irq_pin_once().
Another issue is that the number of interrupts reserved is currently determined by the value of the NR_IRQS_LEGACY macro (16). However the legacy IRQ domain mapping needs at least the number of interrupts provided by the I/O APIC. If an I/O APIC has been registered that number is dynamically computed and used instead of NR_IRQS_LEGACY.
--- arch/x86/kernel/apic/io_apic.c | 5 +++++ arch/x86/kernel/devicetree.c | 13 +++++++++++-- 2 files changed, 16 insertions(+), 2 deletions(-)
arch/x86/kernel/apic/io_apic.c +5 -0
@@ -3465,6 +3465,7 @@ int get_nr_irqs_gsi(void)int __init arch_probe_nr_irqs (void ) { +struct mp_ioapic_gsi *gsi_cfg;int nr;if (nr_irqs > (NR_VECTORS * nr_cpu_ids))
@@ -3480,6 +3481,10 @@ int __init arch_probe_nr_irqs(void)if (nr < nr_irqs) nr_irqs = nr; + gsi_cfg =mp_ioapic_gsi_routing (0 ); +if (gsi_cfg) +return gsi_cfg->gsi_end - gsi_cfg->gsi_base; +return NR_IRQS_LEGACY ; }
arch/x86/kernel/devicetree.c +11 -2
@@ -338,8 +338,15 @@ static int ioapic_xlate(struct irq_domain *domain,return 0 ; } +static int ioapic_map (struct irq_domain *domain,unsigned int virq, +irq_hw_number_t hw) +{ +return 0 ; +} +const struct irq_domain_ops ioapic_irq_domain_ops = { .xlate = ioapic_xlate, + .map = ioapic_map, };static void __init ioapic_add_ofnode (struct device_node *np)
@@ -358,11 +365,13 @@ static void __init ioapic_add_ofnode(struct device_node *np)if (r.start ==mpc_ioapic_addr (i)) {struct irq_domain *id;struct mp_ioapic_gsi *gsi_cfg; +unsigned int num; gsi_cfg =mp_ioapic_gsi_routing (i); + num = gsi_cfg->gsi_end - gsi_cfg->gsi_base; - id =irq_domain_add_legacy (np,32 , gsi_cfg->gsi_base,0 , - &ioapic_irq_domain_ops, + id =irq_domain_add_legacy (np, num, gsi_cfg->gsi_base, +0 , &ioapic_irq_domain_ops, (void *)i);BUG_ON (!id);return ;
Signature · 1 line
1.7.11.3
PATCH 1/1 x86/dt: use linear irq domain for ioapic(s).
The former conversion to irq_domain_add_legacy() did not fully work since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and program the virq <-> line mapping directly into ioapic) but this would require a different irq lookup in "do_IRQ()" and won't work with ACPI without changes. So this is probably easiest for everyone.
--- arch/x86/kernel/devicetree.c | 52 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 43 insertions(+), 9 deletions(-)
arch/x86/kernel/devicetree.c +43 -9
@@ -342,6 +342,48 @@ const struct irq_domain_ops ioapic_irq_domain_ops = { .xlate = ioapic_xlate, }; +static void dt_add_ioapic_domain (unsigned int ioapic_num, +struct device_node *np) +{ +struct irq_domain *id; +struct mp_ioapic_gsi *gsi_cfg; +int ret; +int num; + + gsi_cfg =mp_ioapic_gsi_routing (ioapic_num); + num = gsi_cfg->gsi_end - gsi_cfg->gsi_base +1 ; + + id =irq_domain_add_linear (np, num, + &ioapic_irq_domain_ops, + (void *)ioapic_num); +BUG_ON (!id); +if (gsi_cfg->gsi_base ==0 ) { +/* +* The first NR_IRQS_LEGACY irq descs are allocated in +* early_irq_init() and need just a mapping. The +* remaining irqs need both. All of them are preallocated +* and assigned so we can keep the 1:1 mapping which the ioapic +* is having. +*/ + ret =irq_domain_associate_many (id,0 ,0 ,NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error mapping legacy irqs: %d\n" , ret); + +if (num >NR_IRQS_LEGACY ) { + ret =irq_create_strict_mappings (id,NR_IRQS_LEGACY , +NR_IRQS_LEGACY , num -NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error creating mapping for the " +"remaining irqs: %d\n" , ret); + } +irq_set_default_host (id); + }else { + ret =irq_create_strict_mappings (id, gsi_cfg->gsi_base,0 , num); +if (ret) +pr_err ("Error creating irq mapping: %d\n" , ret); + } +} +static void __init ioapic_add_ofnode (struct device_node *np) {struct resource r;
@@ -356,15 +398,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)for (i =0 ; i < nr_ioapics; i++) {if (r.start ==mpc_ioapic_addr (i)) { -struct irq_domain *id; -struct mp_ioapic_gsi *gsi_cfg; - - gsi_cfg =mp_ioapic_gsi_routing (i); - - id =irq_domain_add_legacy (np,32 , gsi_cfg->gsi_base,0 , - &ioapic_irq_domain_ops, - (void *)i); -BUG_ON (!id); +dt_add_ioapic_domain (i, np);return ; } }
Signature · 1 line
1.7.10.4
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 8 lines · Sebastian Andrzej Siewior
The former conversion to
irq_domain_add_legacy()did not fully work since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could useirq_domain_add_simple()or the no-map variant (and program the virq <-> line mapping directly into ioapic) but this would require a different irq lookup in "do_IRQ()" and won't work with ACPI without changes. So this is probably easiest for everyone.Signed-off-by Sebastian Andrzej Siewior <[email protected]>
From a quick glance this looks much better than my patch. This depends on a couple of patches in linux-next it seems, so I'll have to do some rebasing before I can test. Still I think I should be able to get back to you until the end of the week.
Thierry
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
In reply to Sebastian Andrzej SiewiorQuoted 24 lines · Sebastian Andrzej Siewior
The former conversion to
irq_domain_add_legacy()did not fully work since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could useirq_domain_add_simple()or the no-map variant (and program the virq <-> line mapping directly into ioapic) but this would require a different irq lookup in "do_IRQ()" and won't work with ACPI without changes. So this is probably easiest for everyone.Signed-off-by Sebastian Andrzej Siewior <[email protected]>--- arch/x86/kernel/devicetree.c | 52 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 43 insertions(+), 9 deletions(-)arch/x86/kernel/devicetree.c +4
-0@@ -342,6 +342,48 @@ const struct irq_domain_ops ioapic_irq_domain_ops = { .xlate = ioapic_xlate, }; +static void dt_add_ioapic_domain (unsigned int ioapic_num, +struct device_node *np) +{ +struct irq_domain *id;
arch/x86/kernel/devicetree.c const struct irq_domain_ops ioapic_irq_domain_ops = { · line 358
Quoted 10 lines
arch/x86/kernel/devicetree.c +10
-0+struct mp_ioapic_gsi *gsi_cfg; +int ret; +int num; + + gsi_cfg =mp_ioapic_gsi_routing (ioapic_num); + num = gsi_cfg->gsi_end - gsi_cfg->gsi_base +1 ; + + id =irq_domain_add_linear (np, num, + &ioapic_irq_domain_ops, + (void *)ioapic_num);
This fits on two lines instead of three.
Quoted 9 lines
arch/x86/kernel/devicetree.c +9
-0+BUG_ON (!id); +if (gsi_cfg->gsi_base ==0 ) { +/* +* The first NR_IRQS_LEGACY irq descs are allocated in +* early_irq_init() and need just a mapping. The +* remaining irqs need both. All of them are preallocated +* and assigned so we can keep the 1:1 mapping which the ioapic +* is having. +*/
arch/x86/kernel/devicetree.c const struct irq_domain_ops ioapic_irq_domain_ops = { · line 377
Quoted 10 lines
arch/x86/kernel/devicetree.c +10
-0+ ret =irq_domain_associate_many (id,0 ,0 ,NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error mapping legacy irqs: %d\n" , ret); + +if (num >NR_IRQS_LEGACY ) { + ret =irq_create_strict_mappings (id,NR_IRQS_LEGACY , +NR_IRQS_LEGACY , num -NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error creating mapping for the " +"remaining irqs: %d\n" , ret);
There's an extra space between "remaining" and "irqs". Also other places use the spelling IRQ and IRQs respectively in strings, so it may be nice to stay consistent.
Quoted 19 lines
arch/x86/kernel/devicetree.c +9
-3+ } +irq_set_default_host (id); + }else { + ret =irq_create_strict_mappings (id, gsi_cfg->gsi_base,0 , num); +if (ret) +pr_err ("Error creating irq mapping: %d\n" , ret); + } +} +static void __init ioapic_add_ofnode (struct device_node *np) {struct resource r;@@ -356,15 +398,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)for (i =0 ; i < nr_ioapics; i++) {if (r.start ==mpc_ioapic_addr (i)) { -struct irq_domain *id; -struct mp_ioapic_gsi *gsi_cfg; -
arch/x86/kernel/devicetree.c static void __init ioapic_add_ofnode(struct device_node *np) · line 404
Quoted 10 lines
arch/x86/kernel/devicetree.c +1
-6- gsi_cfg =mp_ioapic_gsi_routing (i); - - id =irq_domain_add_legacy (np,32 , gsi_cfg->gsi_base,0 , - &ioapic_irq_domain_ops, - (void *)i); -BUG_ON (!id); +dt_add_ioapic_domain (i, np);return ; } }
Besides the above nitpicks:
On another note, I saw that you've used the "intel,ce4100" prefix in various places and I wonder if it would be useful to replace them with something more generic like "intel,hpet", "intel,lapic" and "intel,ioapic" respectively. The hardware that I use is based on an Atom N450 and works with the current code, so it really isn't ce4100- specific.
Given that this is x86/devicetree only and fixes things that didn't work before, can it go into 3.6? Backporting to stable is probably not worth it because it depends on a number of other IRQ domain patches that are only available in 3.6.
Thierry
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 5 lines · Thierry Reding
arch/x86/kernel/devicetree.c const struct irq_domain_ops ioapic_irq_domain_ops = { · line 358
Quoted 3 lines
arch/x86/kernel/devicetree.c +3
-0+ id =irq_domain_add_linear (np, num, + &ioapic_irq_domain_ops, + (void *)ioapic_num);This fits on two lines instead of three.
k
Quoted 6 lines
arch/x86/kernel/devicetree.c const struct irq_domain_ops ioapic_irq_domain_ops = { · line 377
Quoted 2 lines
arch/x86/kernel/devicetree.c +2
-0+pr_err ("Error creating mapping for the " +"remaining irqs: %d\n" , ret);There's an extra space between "remaining" and "irqs". Also other places use the spelling IRQ and IRQs respectively in strings, so it may be nice to stay consistent.
I see.
Quoted 4 lines
Besides the above nitpicks:
Reviewed-by Thierry Reding<[email protected]>Tested-by Thierry Reding<[email protected]>
Thanks for testing.
Quoted 6 lines
On another note, I saw that you've used the "intel,ce4100" prefix in various places and I wonder if it would be useful to replace them with something more generic like "intel,hpet", "intel,lapic" and "intel,ioapic" respectively. The hardware that I use is based on an Atom N450 and works with the current code, so it really isn't ce4100- specific.
No. You do have a compatible entry. It first appeared on the ce4100 CPU. If it happens to also work on the n450 then it seems to be compatible with that one. "This" is documented somewhere… Usually you add 'compatible = "your cpu", "generic binding"' in case you need a fixup / errata whatever for "your cpu". Even if you compare all hpets from Intel there is the one or other difference / errata.
Quoted 1 line
Thierry
Sebastian
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 8 lines · Sebastian Andrzej Siewior
Quoted 6 lines · Thierry Reding
On another note, I saw that you've used the "intel,ce4100" prefix in various places and I wonder if it would be useful to replace them with something more generic like "intel,hpet", "intel,lapic" and "intel,ioapic" respectively. The hardware that I use is based on an Atom N450 and works with the current code, so it really isn't ce4100- specific.
Quoted 6 lines
No. You do have a compatible entry. It first appeared on the ce4100 CPU. If it happens to also work on the n450 then it seems to be compatible with that one. "This" is documented somewhere… Usually you add 'compatible = "your cpu", "generic binding"' in case you need a fixup / errata whatever for "your cpu". Even if you compare all hpets from Intel there is the one or other difference / errata.
Exactly, but "ce4100-hpet" isn't very generic. What I'm saying is that the last entry in the compatible list should be something generic, like "intel,hpet", which can be overridden by putting a more specific entry in front. I'd expect the ce4100 HPET to use something like this:
compatible = "intel,ce4100-hpet", "intel,hpet";
On N450 this could for instance be:
compatible = "intel,n450-hpet", "intel,hpet";
With that in place, the driver code can match on "intel,hpet" to catch all implementations and use the more specific entries if quirks are required for the specific hardware.
Thierry
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 3 lines · * Thierry Reding | 2012-08-08 14:07:37 [+0200]:
With that in place, the driver code can match on "intel,hpet" to catch all implementations and use the more specific entries if quirks are required for the specific hardware.
from http://lkml.org/lkml/2011/2/16/350:
|"intel,ioapic" is probably too generic and can be dropped. Newer |devices can claim compatibility with "intel,ioapic-ce4100" if they are |indeed compatible so that device drivers don't need to be modified. |It is better to anchor compatible values to real implementations that |try to come up with 'generic' or wildcard strings. Ditto through the |rest of the file.
Quoted 1 line
Thierry
Sebastian
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 6 lines · Sebastian Andrzej Siewior
Quoted 3 lines · * Thierry Reding | 2012-08-08 14:07:37 [+0200]:
With that in place, the driver code can match on "intel,hpet" to catch all implementations and use the more specific entries if quirks are required for the specific hardware.
Quoted 8 lines
from http://lkml.org/lkml/2011/2/16/350:
|"intel,ioapic" is probably too generic and can be dropped. Newer |devices can claim compatibility with "intel,ioapic-ce4100" if they are |indeed compatible so that device drivers don't need to be modified. |It is better to anchor compatible values to real implementations that |try to come up with 'generic' or wildcard strings. Ditto through the |rest of the file.
Oh well. I've seen just the opposite used on ARM, where you start from a generic implementation and compatible value and use more specific compatible values for device-specific quirks.
But okay, the hardware that I use seems to work fine anyway, so I'll just leave it as-is.
Thierry
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
In reply to Sebastian Andrzej SiewiorQuoted 7 lines · Sebastian Andrzej Siewior <bigeasy <at> linutronix.de> writes:
No. You do have a compatible entry. It first appeared on the ce4100 CPU. If it happens to also work on the n450 then it seems to be compatible with that one. "This" is documented somewhere… Usually you add 'compatible = "your cpu", "generic binding"' in case you need a fixup / errata whatever for "your cpu". Even if you compare all hpets from Intel there is the one or other difference / errata.
Can we make sure that his hits the future 3.6 stable releases? We had to merge this back to your 3.6 kernel tree in order to have a functionnal CE4100 system.
Thank you!
--
Florian
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 9 lines · On Friday 19 October 2012 11:36:25 Fainelli wrote:
Quoted 7 lines · Sebastian Andrzej Siewior <bigeasy <at> linutronix.de> writes:
No. You do have a compatible entry. It first appeared on the ce4100 CPU. If it happens to also work on the n450 then it seems to be compatible with that one. "This" is documented somewhere… Usually you add 'compatible = "your cpu", "generic binding"' in case you need a fixup / errata whatever for "your cpu". Even if you compare all hpets from Intel there is the one or other difference / errata.
Quoted 4 lines
Can we make sure that his hits the future 3.6 stable releases? We had to merge this back to your 3.6 kernel tree in order to have a functionnal CE4100 system.
Thank you!
Adding Adding Thomas, Ingo and Sebastian in CC.
--
Florian
Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).
Quoted 10 lines · * Florian Fainelli | 2012-10-19 15:40:29 [+0200]:
Quoted 9 lines · On Friday 19 October 2012 11:36:25 Fainelli wrote:
Quoted 7 lines · Sebastian Andrzej Siewior <bigeasy <at> linutronix.de> writes:
No. You do have a compatible entry. It first appeared on the ce4100 CPU. If it happens to also work on the n450 then it seems to be compatible with that one. "This" is documented somewhere??? Usually you add 'compatible = "your cpu", "generic binding"' in case you need a fixup / errata whatever for "your cpu". Even if you compare all hpets from Intel there is the one or other difference / errata.
Quoted 6 lines
Quoted 4 lines
Can we make sure that his hits the future 3.6 stable releases? We had to merge this back to your 3.6 kernel tree in order to have a functionnal CE4100 system.
Thank you!
Adding Adding Thomas, Ingo and Sebastian in CC.
If someone needs it, yes. My understanding was that Thierry said we need a few OF specific patches and this alone won't help. Care to backport and test & post it?
Quoted 2 lines
--
Florian
Sebastian
PATCH v2 1/1 x86/dt: use linear irq domain for ioapic(s).
In reply to Thierry RedingThe former conversion to irq_domain_add_legacy() did not fully work since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and program the virq <-> line mapping directly into ioapic) but this would require a different irq lookup in "do_IRQ()" and won't work with ACPI without changes. So this is probably easiest for everyone.
---
v1..v2: - added tested tag from Thierry
- moved argument ioapic_irq_domain_ops of irq_domain_add_linear() one line up
- removed one extra space "remaining" and "irqs"
- use IRQs and IRQ instead of irq and irqs in printks.
arch/x86/kernel/devicetree.c | 51 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 42 insertions(+), 9 deletions(-)
arch/x86/kernel/devicetree.c +42 -9
@@ -342,6 +342,47 @@ const struct irq_domain_ops ioapic_irq_domain_ops = { .xlate = ioapic_xlate, }; +static void dt_add_ioapic_domain (unsigned int ioapic_num, +struct device_node *np) +{ +struct irq_domain *id; +struct mp_ioapic_gsi *gsi_cfg; +int ret; +int num; + + gsi_cfg =mp_ioapic_gsi_routing (ioapic_num); + num = gsi_cfg->gsi_end - gsi_cfg->gsi_base +1 ; + + id =irq_domain_add_linear (np, num, &ioapic_irq_domain_ops, + (void *)ioapic_num); +BUG_ON (!id); +if (gsi_cfg->gsi_base ==0 ) { +/* +* The first NR_IRQS_LEGACY irq descs are allocated in +* early_irq_init() and need just a mapping. The +* remaining irqs need both. All of them are preallocated +* and assigned so we can keep the 1:1 mapping which the ioapic +* is having. +*/ + ret =irq_domain_associate_many (id,0 ,0 ,NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error mapping legacy IRQs: %d\n" , ret); + +if (num >NR_IRQS_LEGACY ) { + ret =irq_create_strict_mappings (id,NR_IRQS_LEGACY , +NR_IRQS_LEGACY , num -NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error creating mapping for the " +"remaining IRQs: %d\n" , ret); + } +irq_set_default_host (id); + }else { + ret =irq_create_strict_mappings (id, gsi_cfg->gsi_base,0 , num); +if (ret) +pr_err ("Error creating IRQ mapping: %d\n" , ret); + } +} +static void __init ioapic_add_ofnode (struct device_node *np) {struct resource r;
@@ -356,15 +397,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)for (i =0 ; i < nr_ioapics; i++) {if (r.start ==mpc_ioapic_addr (i)) { -struct irq_domain *id; -struct mp_ioapic_gsi *gsi_cfg; - - gsi_cfg =mp_ioapic_gsi_routing (i); - - id =irq_domain_add_legacy (np,32 , gsi_cfg->gsi_base,0 , - &ioapic_irq_domain_ops, - (void *)i); -BUG_ON (!id); +dt_add_ioapic_domain (i, np);return ; } }
Signature · 1 line
1.7.10.4
[tip:x86/apic] x86: dt: Use linear irq domain for ioapic(s)
Commit-ID: ece3234a77ebcd5bbeea6b829c9798328d290cae Gitweb: http://git.kernel.org/tip/ece3234a77ebcd5bbeea6b829c9798328d290cae Author: Sebastian Andrzej Siewior <[email protected]> AuthorDate: Mon, 13 Aug 2012 22:23:33 +0200 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 21 Aug 2012 22:16:57 +0200
x86: dt: Use linear irq domain for ioapic(s)
The former conversion to irq_domain_add_legacy() did not fully work since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and program the virq <-> line mapping directly into ioapic) but this would require a different irq lookup in "do_IRQ()" and won't work with ACPI without changes. So this is probably easiest for everyone.
--- arch/x86/kernel/devicetree.c | 51 ++++++++++++++++++++++++++++++++++------- 1 files changed, 42 insertions(+), 9 deletions(-)
arch/x86/kernel/devicetree.c +42 -9
@@ -342,6 +342,47 @@ const struct irq_domain_ops ioapic_irq_domain_ops = { .xlate = ioapic_xlate, }; +static void dt_add_ioapic_domain (unsigned int ioapic_num, +struct device_node *np) +{ +struct irq_domain *id; +struct mp_ioapic_gsi *gsi_cfg; +int ret; +int num; + + gsi_cfg =mp_ioapic_gsi_routing (ioapic_num); + num = gsi_cfg->gsi_end - gsi_cfg->gsi_base +1 ; + + id =irq_domain_add_linear (np, num, &ioapic_irq_domain_ops, + (void *)ioapic_num); +BUG_ON (!id); +if (gsi_cfg->gsi_base ==0 ) { +/* +* The first NR_IRQS_LEGACY irq descs are allocated in +* early_irq_init() and need just a mapping. The +* remaining irqs need both. All of them are preallocated +* and assigned so we can keep the 1:1 mapping which the ioapic +* is having. +*/ + ret =irq_domain_associate_many (id,0 ,0 ,NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error mapping legacy IRQs: %d\n" , ret); + +if (num >NR_IRQS_LEGACY ) { + ret =irq_create_strict_mappings (id,NR_IRQS_LEGACY , +NR_IRQS_LEGACY , num -NR_IRQS_LEGACY ); +if (ret) +pr_err ("Error creating mapping for the " +"remaining IRQs: %d\n" , ret); + } +irq_set_default_host (id); + }else { + ret =irq_create_strict_mappings (id, gsi_cfg->gsi_base,0 , num); +if (ret) +pr_err ("Error creating IRQ mapping: %d\n" , ret); + } +} +static void __init ioapic_add_ofnode (struct device_node *np) {struct resource r;
@@ -356,15 +397,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)for (i =0 ; i < nr_ioapics; i++) {if (r.start ==mpc_ioapic_addr (i)) { -struct irq_domain *id; -struct mp_ioapic_gsi *gsi_cfg; - - gsi_cfg =mp_ioapic_gsi_routing (i); - - id =irq_domain_add_legacy (np,32 , gsi_cfg->gsi_base,0 , - &ioapic_irq_domain_ops, - (void *)i); -BUG_ON (!id); +dt_add_ioapic_domain (i, np);return ; } }