From: Robert Hancock <hancockr@shaw.ca>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: de2104x: interrupts before interrupt handler is registered
Date: Tue, 07 Mar 2006 18:00:31 -0600 [thread overview]
Message-ID: <440E1E9F.3020208@shaw.ca> (raw)
In-Reply-To: <Pine.LNX.4.61.0603070908460.9133@chaos.analogic.com>
linux-os (Dick Johnson) wrote:
> Thinking that a device powers ON in a stable state is naive.
I don't think so.. if you build a device that connects to the PCI bus it
had better come up in a stable state if it wants to be compliant with
the spec. That's what the reset line and power-up reset interval is for.
> Many
> complex devices will have FPGA devices with floating pins that don't
> become stable until their contents are loaded serially. Others will
> have IRQ requests based upon power-on states that need to be cleared
> with a software reset. One can't issue a software reset until the
> device is enabled and enabling the device may generate interrupts
> with no handler in place so you have a "can't get there from here"
> problem.
You still aren't seeing my point. Why does enabling the device BARs
cause the device to generate interrupts? And if there's something you
need to do to prevent the device from generating interrupts, how can you
do it without enabling the device?
Also, the device's ISR must clear the condition which is causing the
interrupt, otherwise interrupt storms will result. If your device can
enter a state where the interrupt cannot be reliably cleared, how can
you possibly comply with this?
> Linux-2.4.x had IRQs that were stable. One could put
> a handler in place that would handle the possible burst of interrupts
> upon startup. Then this was changed so the IRQ value is wrong
> until an unrelated and illogical event occurs. Now, you need to
> make work-arounds that were never before necessary. My request
> to fix this fell upon deaf ears.
I don't think any workarounds are needed except for devices that don't
comply with the spec. Asserting interrupts that have not been
specifically enabled by the driver would meet that definition in my
view. If a device happens to do this then maybe a workaround would be
needed, but that's what it would be, a workaround for a broken device.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
next prev parent reply other threads:[~2006-03-08 0:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5N5Ql-30C-11@gated-at.bofh.it>
[not found] ` <5NnDE-44v-11@gated-at.bofh.it>
2006-03-07 0:02 ` de2104x: interrupts before interrupt handler is registered Robert Hancock
2006-03-07 12:07 ` linux-os (Dick Johnson)
2006-03-07 13:58 ` Robert Hancock
2006-03-07 14:21 ` linux-os (Dick Johnson)
2006-03-07 17:51 ` Bjorn Helgaas
2006-03-07 18:17 ` linux-os (Dick Johnson)
2006-03-08 0:05 ` Robert Hancock
2006-03-08 8:18 ` Jesse Brandeburg
2006-03-08 16:05 ` Bjorn Helgaas
2006-03-08 19:34 ` Martin Michlmayr
2006-03-08 0:00 ` Robert Hancock [this message]
2006-03-08 12:03 ` linux-os (Dick Johnson)
2006-03-08 23:34 ` Robert Hancock
2006-03-09 12:42 ` linux-os (Dick Johnson)
[not found] <5Nz1Y-4hZ-25@gated-at.bofh.it>
[not found] ` <5NKTG-4F7-21@gated-at.bofh.it>
[not found] ` <5NLmp-5sk-5@gated-at.bofh.it>
[not found] ` <5NODG-1RH-3@gated-at.bofh.it>
[not found] ` <5O23T-59S-15@gated-at.bofh.it>
2006-03-09 0:02 ` Robert Hancock
2006-03-05 18:07 Martin Michlmayr
2006-03-05 18:59 ` Francois Romieu
2006-03-06 14:35 ` Martin Michlmayr
2006-03-06 19:17 ` Martin Michlmayr
2006-03-06 19:48 ` Francois Romieu
2006-03-06 19:59 ` Martin Michlmayr
2006-03-06 20:23 ` Francois Romieu
2006-03-06 20:29 ` Martin Michlmayr
2006-03-06 20:54 ` Francois Romieu
2006-03-07 5:16 ` Martin Michlmayr
2006-03-06 21:17 ` Francois Romieu
2006-03-07 5:11 ` Martin Michlmayr
2006-03-07 14:57 ` Martin Michlmayr
2006-03-08 0:15 ` Francois Romieu
2006-03-08 3:22 ` Martin Michlmayr
2006-03-07 15:16 ` Martin Michlmayr
2006-03-06 13:02 ` linux-os (Dick Johnson)
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=440E1E9F.3020208@shaw.ca \
--to=hancockr@shaw.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/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