> This is why I'm so adamant that we need to _know_ that it works before we
> use it. When irq's get mis-routed, things go downhill real fast. We're
> usually talking "dead machines", and there is very little that a driver
> can do about it.
well we could cheat some. And have the generic code for this just
register the irq handler for both somehow. At least the case for "only
does old style and no actual MSI" will work then.
For the duplicate issue... if the generic irq layer keeps track of the
"mirror" property of the handler it could be dealt with (eg clear the
unhandled count of the "mirror" as well on each handled irq)..
I'll grant you that it's a bit evil, and probably ulgy to keep the
mirror information, but if it gets the thing reliable..... it could
solve a lot of the mess.
(Oh and I would *love* for this to printk once if the kernel detects
cheating behavior so that we can make things like the linux firmware
test kit complain to the hw/bios folks early on)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
