linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "linux-os \(Dick Johnson\)" <linux-os@analogic.com>
To: "Linus Torvalds" <torvalds@osdl.org>
Cc: "Stephen Hemminger" <shemminger@osdl.org>,
	"Andrew Morton" <akpm@osdl.org>, <linux-kernel@vger.kernel.org>
Subject: Re: better leve triggered IRQ management needed
Date: Mon, 24 Apr 2006 15:35:20 -0400	[thread overview]
Message-ID: <Pine.LNX.4.61.0604241529360.24459@chaos.analogic.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0604241156340.3701@g5.osdl.org>


On Mon, 24 Apr 2006, Linus Torvalds wrote:

>
>
> On Mon, 24 Apr 2006, Stephen Hemminger wrote:
>>
>> We should fail request_irq() if the SA_SHIRQ but the irq is edge-triggered.
>
> That would be HORRIBLE.
>
> Edge-triggered works perfectly fine for SA_SHIRQ, as long as there is just
> one user and the driver is properly written. Making request_irq() fail
   ^^^^^^^^_______ Must be a trick!
> would break existing and working setups.
>

If there is just one user then it isn't shared! Get real.

> If you have a driver that requires level-triggered interrupts, then your
> driver is arguably buggy. NAPI or no NAPI, doesn't matter. Edge-triggered
> interrupts is a fact of life, and deciding that you don't like them is not
> an excuse for saying "they should not work".
>

It's trivial to write a driver where the ISR completely handles the
interrupt so that another edge can happen. It is impossible to write
a driver that shares such an edge-driven interrupt with another.

> You can get an edge by having your driver make sure that it clears the
> interrupt source at some point where it requires an edge.
>
> And yes, that may mean that when you're ready to start taking interrupts
> again, you are required to first read all pending packets, instead of just
> assuming that a level-triggered interrupt will "just happen", but that's
> the harsh reality for writing a driver that actually WORKS.
>
> For a driver writer, there is one rule above _all_ other rules:
>
> 	"Reality sucks, deal with it"
>
> That rule is inviolate, and no amount of "I wish", and "it _should_ work
> this way" or "..but the documentation says" matters at all.
>
> If you can't take that rule, don't write drivers, and don't design
> infrastructure for them.
>
> 		Linus

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

  parent reply	other threads:[~2006-04-24 19:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-24 18:41 better leve triggered IRQ management needed Stephen Hemminger
2006-04-24 18:59 ` linux-os (Dick Johnson)
2006-04-24 19:02 ` Linus Torvalds
2006-04-24 19:08   ` Linus Torvalds
2006-04-24 19:53     ` Arjan van de Ven
2006-04-24 20:16       ` Alan Cox
2006-04-24 20:43         ` Arjan van de Ven
2006-04-24 21:07           ` Linus Torvalds
2006-04-24 21:20             ` Alan Cox
2006-04-24 22:26               ` Linus Torvalds
2006-04-24 21:22             ` [RFC 1/2] irq: record edge-level setting Stephen Hemminger
2006-04-24 21:49               ` Alan Cox
2006-04-24 21:41                 ` Stephen Hemminger
2006-04-24 22:34                   ` Linus Torvalds
2006-04-24 22:58                     ` Stephen Hemminger
     [not found]             ` <20060424141926.3872f921@localhost.localdomain>
2006-04-24 21:22               ` [RFC 2/2] warn on shared edge-triggered irq Stephen Hemminger
2006-04-25 15:23             ` better leve triggered IRQ management needed Michael Buesch
2006-04-24 19:15   ` Russell King
2006-04-24 20:18     ` Linus Torvalds
2006-04-24 19:25   ` Stephen Hemminger
2006-04-24 19:35   ` linux-os (Dick Johnson) [this message]
2006-04-24 20:19     ` Linus Torvalds
2006-04-24 20:50       ` linux-os (Dick Johnson)
2006-04-24 21:09         ` Linus Torvalds
2006-04-29 21:25 ` Alan Cox
2006-04-29 21:58   ` Linus Torvalds
2006-04-30  4:48     ` Neil Brown
2006-04-30  5:19       ` Linus Torvalds
2006-04-30  6:13         ` Neil Brown
2006-04-30  6:59           ` Linus Torvalds
2006-05-02  5:10             ` Neil Brown
2006-05-02 15:05               ` Linus Torvalds
2006-04-30  7:36       ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0604241529360.24459@chaos.analogic.com \
    --to=linux-os@analogic.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shemminger@osdl.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).