Having different devices sharing a hardware interrupt is kind of a neat idea, but unless you really need to do it—because you've run out of hardware interrupt lines—it generally doesn't help you much. In fact, it can cause you trouble. For example, if your driver doesn't work (e.g., no received packets), check to see if it's sharing an interrupt with another device, and if so, reconfigure your board so it doesn't.
Most of the time, when shared interrupts are configured, there's no good reason for it (i.e., you haven't really run out of interrupts) and this can decrease your performance, because when the interrupt fires, all of the devices sharing the interrupt need to run and check to see if it's for them. Some drivers do the “right thing,” which is to read registers in their interrupt handlers to see if the interrupt is really for them, and then ignore it if not. But many drivers don't; they schedule their thread-level event handlers to check their hardware, which is inefficient and reduces performance.
If you're using the PCI bus, use the pci-tool utility to check the interrupt allocation.
Sharing interrupts can vastly increase interrupt latency, depending upon exactly what each of the drivers does. After an interrupt fires, the kernel doesn't reenable it until all driver handlers tell the kernel that they've finished handling it. So, if one driver takes a long time servicing a shared interrupt that's masked, then if another device on the same interrupt causes an interrupt during that time period, processing of that interrupt can be delayed for an unknown duration of time.
Interrupt sharing can cause problems, and reduce performance, increase CPU consumption, and seriously increase latency. Unless you really need to do it, don't. If you must share interrupts, make sure your drivers are doing the “right thing.”