I will think about this some more. There are some tricky issues that
may make it not so easy. Some CardBus bridge configuration registers
apply to the whole bridge, not just one socket. So, retaining the
configuration of a socket that was set up by the BIOS, while firing up
full CardBus support after booting, may be difficult (and this is a
key requirement for this idea to be practical).
> The only reason normal drivers don't know about insertion and removal is
> because they haven't had to deal with it before. We'll make them deal with
> it. It would be easy to add a per-interrupt-descriptor "disable" bit, for
> example, so that when a specific card was removed only THAT particular
> interrupt never happens any more (so PCMCIA devices could use the normal
> "request_irq()" and "free_irq()" logic, and yet we'd make it work right so
> that when a card is removed only THAT particular interrupt goes away -
> instead of getting interrupts from another card that got inserted).
Blocking the interrupt turns out to rarely be a useful thing to do.
Ignore the fact that an eject can happen when an interrupt is already
being serviced. It turns out that in practice, you almost always get
spurious interrupts at the instant a card is ejected, before the card
removal interrupt can be serviced, regardless of the relative
priorities of the two interrupts. It seems to be an artifact of the
electrical specification. I eventually decided that the only way to
deal with hot ejects was for each driver's interrupt routine to check
for device existence, not spin indefinitely on status registers, etc.
> This is the second and more insidious problem with the current PCMCIA
> "outside the mainline kernel" - none of the PCMCIA issues ever get fixed.
> Because nothing else would be using them - the infrastructure just never
> gets built up, and then you complain about the fact that you can't find
> out what interrupts are in use.
You're exaggerating somewhat. All sorts of PCMCIA issues with the
kernel tree get fixed. Shared interrupts, better IO port management,
better module handling, bullet proofing of drivers against hot
ejection: all happened despite PCMCIA not being physically located in
the kernel tree. There are a few key things that have not been
resolved (like PnP) but I can't think of that many cases where kernel
issues have been limiting for me.
In the past, I've also advocated for some of this infrastructure, and
sent you patches for bits and pieces of it, and I'd turn your argument
around and say that a reason PCMCIA has stayed out of the kernel is
*because* that infrastructure never got built up. You demand that
kernels work well on your machines... I demand that PCMCIA works well,
and I won't sacrifice functionality just to have it in the kernel
tree.
-- Dave Hinds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/