From: "Tom Arbuckle" <tom.d.arbuckle@gmail.com>
To: linuxppc-dev@ozlabs.org
Subject: Re: [RFC PATCH] "multifunc-device": fix IRQ assignment by also scanning dummy nodes
Date: Tue, 20 Jan 2009 19:17:50 +0000 [thread overview]
Message-ID: <e86dc2bc0901201117u3359c561pd1d8567484a8a17b@mail.gmail.com> (raw)
In-Reply-To: <e86dc2bc0901051200l1a111022o8842c2f66135da11@mail.gmail.com>
Hi,
Did anybody pick up on this patch necessary to have OF understand
so-called "multifunc-devices". I received no feedback on it.
I note that the problem persists with 2.6.28.1 (although it was
introduced by the PCI reorg for 2.6.20). File pci_32.c is unchanged in
the latest release.
Regards,
Tom Arbuckle
Homepage: http://www.ece.ul.ie/homepage/Tom_Arbuckle/
LinkedIn: http://www.linkedin.com/in/tomarbuckle
---------- Original message ----------
Kernel: 2.6.28; function: scan_OF_pci_childs; file: arch/powerpc/kernel/pci_32.c
Quoting from line 206 : 'some OFs create a parent node "multifunc-device" as a
fake root for all functions of a multi-function device. we go down
them as well.'
Function scan_OF_for_pci_dev (line 225) also needs to be taught about
these dummy nodes to prevent misallocation/non-allocation of IRQs for
this class of devices.
Why RFC? I have chosen to scan all 'unusual' nodes as possible
multifunc-devices. Is this too many?
Bug seen when using a bt878 multimedia controller card on a G3 Powermac.
This PCI card has separate audio and video nodes and was not being properly
assigned interrupts. (Either 'cannot grab irq 0' or type of assigned
interrupt wrt 'edge/level' was incorrect).
Signed off by: Tom Arbuckle <tom.d.arbuckle (at) gmail.com>
--- linux-2.6.28/arch/powerpc/kernel/pci_32.c.orig 2008-12-27
16:32:48.000000000 +0000
+++ linux-2.6.28/arch/powerpc/kernel/pci_32.c 2008-12-27
16:36:15.000000000 +0000
@@ -226,15 +226,21 @@ static struct device_node *scan_OF_for_p
unsigned int devfn)
{
struct device_node *np;
+ struct device_node *np_sub = NULL;
const u32 *reg;
unsigned int psize;
for_each_child_of_node(parent, np) {
reg = of_get_property(np, "reg", &psize);
- if (reg == NULL || psize < 4)
- continue;
- if (((reg[0] >> 8) & 0xff) == devfn)
- return np;
+ if (reg && psize >= 4) {
+ if (((reg[0] >> 8) & 0xff) == devfn)
+ return np;
+ }
+ if (!strcmp(np->name, "multifunc-device")) {
+ np_sub = scan_OF_for_pci_dev(np, devfn);
+ if (np_sub)
+ return np_sub;
+ }
}
return NULL;
}
prev parent reply other threads:[~2009-01-20 19:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-05 20:00 [RFC PATCH] "multifunc-device": fix IRQ assignment by also scanning dummy nodes Tom Arbuckle
2009-01-20 19:17 ` Tom Arbuckle [this message]
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=e86dc2bc0901201117u3359c561pd1d8567484a8a17b@mail.gmail.com \
--to=tom.d.arbuckle@gmail.com \
--cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).