True. At least for PnP as designed by MS.
> Examination (RTFS & experiment) of at least serial.c and 3c509.c show that
> both only allocate their interrupts if they're opened. Conclusion: no working
> PnP, at least not with those two popular (PnP-) trouble-makers.
The reason for this is that interrupt sharing did not originally work, and
many devices wanted to "share" interrupts by making sure that only one
device was active at a time.
For example, irq5 used to be one very popular "extra" interrupt that has
been known to have multiple devices on it even on an ISA bus - and one way
to handle this has been to make sure that only the device you are
_currently_ using allocates the IRQ, and when not used the device makes
sure that its interrupt line is quiescent.
Of course, the correct way to handle this these days is to use shared PCI
interrupts, in which case none of this all matters (nor does PnP - devices
can just use the interrupt without really being aware of each other, as
long as they are ready to accept "spurious" interrupts).
> Question: are there guidelines for driver programming on when to declare
> resources used ? (IMHO: as soon as they're known. ISA IRQ-sharing sucks !)
ISA IRQ sharing does indeed suck, and quite badly.
However, one reason PnP has not gotten much support from me personally is
that PnP doesn't really help all that much in the general case. Yes, PnP
helps _if_ you have all-PnP-aware devices, but quite frankly the whole
standard is slightly broken and superceded by PCI anyway to a large
degree. As such I'm not all that excited about PnP, especially as trying
to be excessively PnP-aware has been known to result in problems on
systems that are _not_ PnP-ready.
> There is a kernel patch pointing into the right direction:
> ftp://sunsite.unc.edu/pub/Linux/kernel/patches/misc/PnP4kernel*
> It is 10 months old and I'm quite dissapointed that such a thing is still
> missing in 2.1.33.
>
> A strategic decision must be made. Mail me if you want more facts.
The strategic decision _has_ been made: I'm taking a "wait and see"
approach to PnP. So far, PnP hasn't convinced me.
HOWEVER - don't take this as a final "no" to PnP. I just want to make it
very clear that I think that some of the issues with PnP are essentially
dead: the ISA PnP irq stuff being one of them (the IRQ's are really an
issue only for ISA devices, and when it comes to ISA devices the _huge_
majority are totally unaware of PnP).
Other PnP stuff can certainly be worth pursuing (like the parallell and
serial port PnP autodetection - although even in this case I suspect that
PnP will be superceded by the USB: anything so clever that it responds to
PnP queries will probably be using USB within the year anyway).
In short, I think PnP was too little, too late, and that it hasn't caught
on enough to worry about it more than we do. I will certainly accept
PnP-aware patches, but those patches may under _no_ circumstances break
more important stuff (ie non-PnP devices).
Linus