From: Andrey Panin <pazke@donpac.ru>
To: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] irq handling code consolidation (common part)
Date: Fri, 27 Jun 2003 08:33:20 +0400 [thread overview]
Message-ID: <20030627043320.GW9679@pazke> (raw)
In-Reply-To: <20030626121318.A6576@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
On 177, 06 26, 2003 at 12:13:18PM +0100, Christoph Hellwig wrote:
> > +#ifndef HAVE_ARCH_IRQ_DESC
> > +
> > +/*
> > + * Controller mappings for all interrupt sources:
> > + */
> > +irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = {
> > + [0 ... NR_IRQS - 1] = {
> > + .handler = &no_irq_type,
> > + .lock = SPIN_LOCK_UNLOCKED,
> > + }
> > +};
> > +
> > +#endif
>
> What about getting rid of that ifdef and having irq_desc always
> in arch code? Seems a lot cleaner to me.
So it will be duplicated in allmost every architecture ?
> > +#if defined(CONFIG_SMP) && !defined(HAVE_ARCH_SYNCRONIZE_IRQ)
> > +
> > +inline void synchronize_irq(unsigned int irq)
> > +{
> > + irq_desc_t *desc = irq_desc(irq);
> > +
> > + /* is there anything to synchronize with? */
> > + if (!desc->action)
> > + return;
> > +
> > + while (desc->status & IRQ_INPROGRESS)
> > + cpu_relax();
> > +}
> > +
> > +#endif
>
> Hmm, what arch can't use the generic version and why? I really
> don't like the HAVE_ARCH_ macros if there's a way around it.
This function implemented differently in allmost every architecture.
I beleive that most of them can use generic version, but I'm still not sure.
v850 and mips define synchronize_irq() as barrier() for example.
> > +#ifndef HAVE_ARCH_IRQ_PROC
> > +void register_irq_proc(unsigned int irq);
> > +#endif
>
> Again, what arch can't use the generic code?
IIRC v850 architecture doesn't need it at all.
> > +#ifndef HAVE_ARCH_IRQ_PROBE
> > +
> > +/*
> > + * IRQ autodetection code..
> > + *
> > + * This depends on the fact that any interrupt that
> > + * comes in on to an unassigned handler will get stuck
> > + * with "IRQ_WAITING" cleared and the interrupt
> > + * disabled.
> > + */
>
> Which architecture uses it's own version here? Also we might
> move this to a separate file as it doesn't make a lot of sense
> without CONFIG_ISA
Some architectures provide empty stubs for these functions.
I'm not sure about CONFIG_ISA, IMHO any legacy device driver
can use irq autoprobing.
> Otherwise it looks fine (of course)! Let's hope we'll get some variant
> of it in before 2.6.
--
Andrey Panin | Linux and UNIX system administrator
pazke@donpac.ru | PGP key: wwwkeys.pgp.net
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-06-27 4:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-26 11:02 [PATCH][RFC] irq handling code consolidation (common part) Andrey Panin
2003-06-26 11:13 ` Christoph Hellwig
2003-06-27 4:33 ` Andrey Panin [this message]
2003-06-26 17:55 ` Anton Blanchard
2003-06-27 5:00 ` Andrey Panin
2003-06-27 6:04 ` Miles Bader
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=20030627043320.GW9679@pazke \
--to=pazke@donpac.ru \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.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