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

Tim Waugh (
Wed, 24 Feb 1999 09:20:53 +0000 (GMT)

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. 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 hardware
> (at least 4 different chip for different m68k parallel port types) and
> do usually more harm than good when they try to play with the
> hardware.

In the -1284 tree I've got things like "wait for a nudge from the port (or
a timeout)", which call parport_wait_event. parport_wait_event, however,
is a single function, in parport_ieee1284.c, and it just waits on a
wait_queue. It is woken up by the ieee1284 interrupt handler helper
function parport_ieee1284_interrupt.

Is that kind of thing okay?

> Yes, this is necessary. You canīt (shouldnīt ;-) disable an irq level
> when it is used by more than one device. This was in the patch I sent
> to the list.

I must admit, I haven't looked at the irq changes in your patch yet. I'll
take a look tonight.

> 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?

I think the intention is that port->ops->disable_irq is for telling the
parallel port interrupt source to be quiet until further notice (i.e.

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

It kind of already is, in my head. ;-) Without a development branch to
put things into, I've been accumulating patches. -1284 and -12843 are

When 2.3 is forked, I don't intend on sending Linus everything I have all
at once, obviously, so I figured it would be easier to keep things at
least a little separated.

That said, it's turning out to be a bit of a pain keeping the patches I
have in step (and I admit I haven't actually _done_ anything with yours
yet), so perhaps I should just bundle it together and learn to split
patches up.


-- 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 - 04:25:02 EST