[patches 6/8] pcmcia: remove racy try_irq()

[Dominik Brodowski]

On Tue, Jan 11, 2005 at 12:11:45PM -0800, David Hinds wrote:
> On Tue, Jan 11, 2005 at 05:59:00PM +0100, Dominik Brodowski wrote:
> 
> > Remove the racy try_irq/check_irq/undo_irq interface, and try to
> > register the correct handler directly in pcmcia_request_irq(). Also,
> > remove the unneeded database in rsrc_mgr, as the kernel IRQ
> > subsystem does that for us.
> 
> I don't think this will work, unless you require that cards register a
> handler at the time the interrupt is selected, which would break some
> drivers (serial_cs, ide-cs at least). 

I don't require it, it is just recommended as the availablity of the
specific IRQ may disappear in between (and thus is racy). The old "try dummy
handler first, register later" method still works.

> The kernel serial driver only
> registers an interrupt when a port is in-use.  So if you plug in two
> PCMCIA serial cards, both will get the same interrupt assigned, unless
> you change things around so that the serial interrupt handler is
> registered at card insertion time.

It depends on whether the first card is activated before the second one is
set up, whether the respective sockets have the same lowest bit in their
irq_mask and whether the user blocked ceratin IRQs on certain sockets (my
patch 7/8 allows the user to do this on a per-socket basis).

Also, what's the problem of sharing IRQs in general? On my notebook, at
least 6 devices share IRQ 10 without a problem.

> This exposes a basic problem with the kernel's scheme for managing
> system resources: it does not distinguish between a piece of hardware
> occupying a resource, and a driver using a resource to talk to some
> hardware.  Because the kernel relies on drivers to reserve resources,
> the kernel resource database can't be depended on for hot plug
> resource allocation.

If it's a problem at the kernel core level, it should be fixed there.
But before doing so, I'd like to get some additional feedback.

Thanks,
	Dominik