From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrey Panin <pazke@orbita1.ru>
Cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [RFC] irq handling code consolidation, second try (ppc part)
Date: 04 Jan 2003 14:01:33 +0100 [thread overview]
Message-ID: <1041685293.641.17.camel@zion.wanadoo.fr> (raw)
In-Reply-To: <20030104115910.GF10477@pazke>
On Sat, 2003-01-04 at 12:59, Andrey Panin wrote:
> Hi all,
>
> attached patch is a second try of IRQ handling code consolidation.
> This is a ppc specific patch (compiled successfuly).
>
> Beware, this patch removes some old(?) and crappy code:
> - irq_kmalloc(), irq_kfree() removed. If ppc need to register
> irqs early, it should use setup_irq() as all decent people do :))
> - request_irq() with NULL handler argument == free_irq(), does
> anyone use this kludge ?
>
After a quick look, things look fine some of this old PPC crap should indeed
be killed now.
There's something else I would like to implement one of these days, and your
consolidation work makes it easier (except for archs that won't use it...).
Basically, I want some (few and rare enough though) drivers to be able
to define interrupt controllers and thus create their own IRQs.
The typical example for which I need that is cardbus. I need the cardbus
controller on PCI to be seen as a real cascaded controller, that is I want
devices below it (either PCI or PCMCIA) calls to request/free/enable/disable_irq
for their to be caught by the cardbus driver.
This is the only sane way to properly enable/disable bridging of the
interrupt upon request from the driver. Without that, I still can frequent
lockups with various pcmcia cards when inserted/removed due to IRQ line
beeing stuck down on slot shutdown or other crappy things happening
typically with legacy PCMCIA stuffs (ATA is a good example of crappy behaviour).
The "easy" way here to implement that is to make the irq_desc array larger than
NR_IRQs (or rather split NR_IRQs into NR_SYS_IRQS + NR_DYNAMIC_IRQS). The
additional "slots" could then easily be allocated/freed. Thus, keeping my
cardbus example, the cardbus driver can allocate a couple of slots (that is IRQ
numbers) dynamically, and use it's own startup/shutdown/enable/disable/...
hooks for them, dealing itself with the cascade from the PCI irq. (Of course,
this is not for systems using cardbus routed to legacy IRQs, but for systems
like PPC where the PCI irq is mux'ing both the device IRQs and the controller
own IRQ).
Ben.
next prev parent reply other threads:[~2003-01-04 12:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-04 11:59 Andrey Panin
2003-01-04 13:01 ` Benjamin Herrenschmidt [this message]
2003-01-04 17:41 ` Linus Torvalds
2003-01-05 8:56 ` Benjamin Herrenschmidt
2003-01-05 19:05 ` Linus Torvalds
2003-01-05 22:03 ` Benjamin Herrenschmidt
2003-01-05 0:25 ` Anton Blanchard
2003-01-05 0:50 ` Anton Blanchard
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=1041685293.641.17.camel@zion.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pazke@orbita1.ru \
--cc=torvalds@transmeta.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
all inboxes | Powered by JetHome®