In message [off-list ref],jingai writes:
Doh! I didn't even think to check if the second get_property() call
was returning > 0.. this fixes it! Thanks bunches for spotting that!
it seems like someone was confused about the meaning of the 'interrupts'
property when they wrote prom.c. its basically the number of interrupts
supported by this pci device. interpret_dbdma_props() also has the
same confusion, so the following would be a more complete patch to
prom.c. note that it checks to see if a pci node has an interrupt
property before assigning one, otherwise devices on the far side of
a pci bridge (that shares interrupts) would be assigned interrupts
when they dont need them.
--- prom.c.000 Thu Dec 28 08:43:12 2000
+++ prom.c Fri Dec 29 10:05:54 2000
@@ -1562,9 +1562,12 @@
return mem_start;
}
+ if ((ip = (int *) get_property(np, "interrupts", &l)) == 0)
+ return mem_start;
+
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
- ip = (int *) get_property(np, "interrupts", &l);
+ if (ip == 0 && np->parent != NULL)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);@@ -1615,9 +1618,12 @@
if (use_of_interrupt_tree)
return mem_start;
+ if ((ip = (int *) get_property(np, "interrupts", &l)) == 0)
+ return mem_start;
+
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
- ip = (int *) get_property(np, "interrupts", &l);
+ if (ip == 0 && np->parent != NULL)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fre, 29. Dez 2000, Chas Williams [off-list ref] wrote:
In message [off-list ref],jingai writes:
quoted
Doh! I didn't even think to check if the second get_property() call
was returning > 0.. this fixes it! Thanks bunches for spotting that!
it seems like someone was confused about the meaning of the 'interrupts'
property when they wrote prom.c. its basically the number of interrupts
supported by this pci device. interpret_dbdma_props() also has the
same confusion, so the following would be a more complete patch to
prom.c. note that it checks to see if a pci node has an interrupt
property before assigning one, otherwise devices on the far side of
a pci bridge (that shares interrupts) would be assigned interrupts
when they dont need them.
Today I tried your patch. Well, I breaks the hole interrupt stuff.
Now, even Mesh has trouble with interrupts (kernel crash), the
console=ttyS0 doesn't work so no output from the booting ...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
it seems like someone was confused about the meaning of the 'interrupts'
property when they wrote prom.c. its basically the number of interrupts
supported by this pci device. interpret_dbdma_props() also has the
same confusion, so the following would be a more complete patch to
prom.c. note that it checks to see if a pci node has an interrupt
property before assigning one, otherwise devices on the far side of
a pci bridge (that shares interrupts) would be assigned interrupts
when they dont need them.
Today I tried your patch. Well, I breaks the hole interrupt stuff.
Now, even Mesh has trouble with interrupts (kernel crash), the
console=ttyS0 doesn't work so no output from the booting ...
The "interrupts" property can have various meanings depending on the OF
version, I suggest you don't mess with it. Just check that if you find no
AAPL,interrupts, and that pmac_newworld == 0, then look for parent
AAPL,interrupts.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
The "interrupts" property can have various meanings depending on the OF
version, I suggest you don't mess with it. Just check that if you find no
AAPL,interrupts, and that pmac_newworld == 0, then look for parent
AAPL,interrupts.
So, then does the following patch seem valid? If so, I'd appreciate it if
others with different macs (newworld and oldworld) could try it and let
me know if it breaks anything...
..and if not, how would one go about getting this into the official trees?
--- prom.c.old Wed Jan 3 20:31:59 2001
+++ prom.c Thu Jan 4 17:44:02 2001
@@ -1564,8 +1564,15 @@
}
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
+ if (ip == 0) {
+ /* hack to force a look at the parent node for interrupts on
+ * oldworld macs with funky PCI<->PCI bridges (ie, UMAX S900)
+ */
+ if (!pmac_newworld && np->parent != NULL)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts",&l);
+ else
ip = (int *) get_property(np, "interrupts", &l);
+ }
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);@@ -1617,8 +1624,15 @@
return mem_start;
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
+ if (ip == 0) {
+ /* hack to force a look at the parent node for interrupts on
+ * oldworld macs with funky PCI<->PCI bridges (ie, UMAX S900)
+ */
+ if (!pmac_newworld && np->parent != NULL)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts",&l);
+ else
ip = (int *) get_property(np, "interrupts", &l);
+ }
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);@@ -1774,8 +1788,15 @@
return mem_start;
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
+ if (ip == 0) {
+ /* hack to force a look at the parent node for interrupts on
+ * oldworld macs with funky PCI<->PCI bridges (ie, UMAX S900)
+ */
+ if (!pmac_newworld && np->parent != NULL)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts",&l);
+ else
ip = (int *) get_property(np, "interrupts", &l);
+ }
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/