Re: [PARPORT] disable/elable_irq() in parport_claim/release().

Andrea Arcangeli (
Wed, 24 Feb 1999 14:50:01 +0100 (CET)

On Wed, 24 Feb 1999, Joerg Dorchain wrote:

>I understand the idea. In this case weīd better remove the handler
>completely (free_irq()) instead of brute-force disabling.

Read irq.c and then you'll see why I used disable_irq(). disable_irq()
does only a `decl' over a 32 bit variable in memory, free/request_irq()
does something more ;).

>I also donīt like the idea of having a mid- or highlevel function caring
>about hardware things like irqs. They donīt know about the specific


>> is automagically done in the parport_pc only saving/restoring the control
>> port.
>I would consider this a side effect of PC-ish hardware. When I wrote the
>amiga parport drivers, I found it quite confusing that the irq-mask was
>in the same register as the control lines.
>How about documenting the semantics clearly?

The new semantic implicit in my latest patch I sent to the list yesterday
is that save_state and restore_state lowlevel operations has to care to
save/restore also the irq masking details of the hardware.

>This is currently done automatically for m68k-ports. Here, request_irq()
>also enables the irq-level. (When you register an irq-handler, you

The same is true for x86.

>BTW, what do I have to do to get the sources for m68k into the parport
>development tree?

You must sent them to Tim I think. He is releasing the latest parport

Andrea Arcangeli

-- To unsubscribe, send mail to: --
-- with the single word "unsubscribe" in the body of the message. --

This archive was generated by hypermail 2.0b3 on Wed 24 Feb 1999 - 09:01:37 EST