On Fri, Jun 21, 2002 at 11:48:23AM +0200, Wolfgang Grandegger wrote:
Hello,
I jump into the discussion as well.
On 06/21/2002 12:10 AM, Tom Rini wrote:
quoted
Well, I looked at it (after I sent but before your mail) and it wasn't a
patch but some cut'n paste bits. And to possibly Dan's dismay I don't
always agree with his opinions now :)
I first wanted to present my ideas ... before I prepare and send a
patch.
For future reference, unified diffs are the preferred way to present
ideas which you've already implemented. :)
quoted
Well, having never used RTAI (and by looking at the 'patch' at
http://lists.linuxppc.org/linuxppc-embedded/200110/txt00002.txt) I don't
get it..
RTAI and RTLinux actually use the "irq_desc[].handler" functions to
handle the interrupts and with the previous cpm_* functions it was
non-trivial to access CPM interrupts within RTAI because they are
handled in a separate interface.
Ah, which is why you just expanded things the way you did.. Which works
for that context but still leaves the larger problem of request_irq()
panic()'ing on unknown interrupt numbers.
[snip]
I understand DAN's argument, that the usage of an offset can be quite
messy especially during driver development but I cannot see a simple
way around it without breaking the (PC) "request_irq" function.
Well maybe Dan will get encouraged enough to try and properly fix
request_irq() and break some of the legacy PC drivers in 2.5 again. :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Tom Rini wrote:
Ah, which is why you just expanded things the way you did.. Which works
for that context but still leaves the larger problem of request_irq()
panic()'ing on unknown interrupt numbers.
All you need to do is modify request_irq() to check/map the numbers that
are OK for you to use on your system. The problem with request_irq() is
it is easy to pass a number you think is fine from some legacy perspective,
but it messes up the SIU due to "numberspace" overlap. To trap these and
print out a message saves lots of traffic on this mailing list :-)
Well maybe Dan will get encouraged enough to try and properly fix
request_irq() and break some of the legacy PC drivers in 2.5 again. :)
I can't break it until I dredge up some of the stuff we did way back in 2.1.xx
and get it to stick. Unless we have the underlying mechanism to manage
an arbitrary, cascaded interrupt controller, all we have are processor and
platform specific hacks with functions that behave differently. I guess
I can do it for PPC only, and then hope this time it gets generally
integrated entirely. In this case, there will be a different function name,
as request_irq() will be left as some macro or simple function for
legacy compatibility.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Mon, Jun 24, 2002 at 01:49:28PM -0400, Dan Malek wrote:
Tom Rini wrote:
quoted
Ah, which is why you just expanded things the way you did.. Which works
for that context but still leaves the larger problem of request_irq()
panic()'ing on unknown interrupt numbers.
All you need to do is modify request_irq() to check/map the numbers that
are OK for you to use on your system. The problem with request_irq() is
it is easy to pass a number you think is fine from some legacy perspective,
but it messes up the SIU due to "numberspace" overlap. To trap these and
print out a message saves lots of traffic on this mailing list :-)
First, I'm not so sure that it does save a lot of traffic. The number
of bad legacy drivers is rather small now, and the ones which _might_
ever be accidently enabled on 8xx are limited to CONFIG_SERIAL I would
think.
Second, if it does become a problem, we should look into grabbing the
ChangeSet from Andi Kleen (and a few others) that masks off legacy
drivers under CONFIG_ISA since they don't work on x86-64 (and probably
ia64). So the x86 world is finally almost caring about this problem :)
Finally, it's not the 'linux way' to preemptivly shoot users in the head
in case they might do something bad to their machine. (And the mapping
doesn't always work anyhow, the ne2k PCMCIA card I've got doesn't work
due to some actual driver issue that I'll look into sometime maybe..
:)).
quoted
Well maybe Dan will get encouraged enough to try and properly fix
request_irq() and break some of the legacy PC drivers in 2.5 again. :)
I can't break it until I dredge up some of the stuff we did way back in
2.1.xx
and get it to stick. Unless we have the underlying mechanism to manage
an arbitrary, cascaded interrupt controller, all we have are processor and
platform specific hacks with functions that behave differently. I guess
I can do it for PPC only, and then hope this time it gets generally
integrated entirely. In this case, there will be a different function name,
as request_irq() will be left as some macro or simple function for
legacy compatibility.
Go for it...
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/