From: ebiederm@xmission.com (Eric W. Biederman)
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jeff Garzik <jeff@garzik.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Date: Fri, 19 Oct 2007 12:38:12 -0600 [thread overview]
Message-ID: <m1bqavgdbf.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <alpine.LFD.0.9999.0710191649120.22770@localhost.localdomain> (Thomas Gleixner's message of "Fri, 19 Oct 2007 16:53:22 +0200 (CEST)")
Thomas Gleixner <tglx@linutronix.de> writes:
> On Fri, 19 Oct 2007, Jeff Garzik wrote:
>>
>> WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
>>
>> This posting is just to demonstrate something that I have been keeping
>> alive in the background. I have no urge to push it upstream anytime
>> soon.
>>
>> The overwhelming majority of drivers do not ever bother with the 'irq'
>> argument that is passed to each driver's irq handler.
>>
>> Of the minority of drivers that do use the arg, the majority of those
>> have the irq number stored in their private-info structure somewhere.
>>
>> There are a tiny few -- a couple Mac drivers -- which do weird things
>> with that argument, but that's it.
>
> Jeff,
>
> thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that use their irq argument.
> Full ACK.
>
> We should do this right at the edge of -rc1. And let's do this right
> now in .24 and not drag it out for no good reason.
There are two problems with that suggestion.
- We don't have all of the architectures converted.
- We don't have a solid plan for how to keep drivers that are
using the irq parameter today working.
I don't think the irq argument is something we want to keep
around forever, and I certainly don't see the need to do
the error prone get_irqfunc_irq and set_irqfunc_irq logic.
How about:
irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
{
irqreturn_t ret, retval = IRQ_NONE;
unsigned int status = 0;
handle_dynamic_tick(action);
if (!(action->flags & IRQF_DISABLED))
local_irq_enable_in_hardirq();
do {
if (action->flags & IRQF_VERBOSE)
ret = action->handler_verbose(irq, action->dev_id);
else
ret = action->handler(action->dev_id);
if (ret == IRQ_HANDLED)
status |= action->flags;
retval |= ret;
action = action->next;
} while (action);
if (status & IRQF_SAMPLE_RANDOM)
add_interrupt_randomness(irq);
local_irq_disable();
return retval;
}
And then:
typedef irqreturn_t (*irq_handler_verbose_t)(int, void *);
typedef irqreturn_t (*irq_handler_t)(void *);
struct irqaction {
union {
irq_handler_verbose_t handler_verbose;
irq_handler_t handler;
};
unsigned long flags;
cpumask_t mask;
const char *name;
void *dev_id;
struct irqaction *next;
int irq;
struct proc_dir_entry *dir;
};
int request_irq(unsigned int irq, irq_handler_t handler,
unsigned long irqflags, const char *devname, void *dev_id)
int request_verbose_irq(unsigned int irq, irq_handler_verbose_t handler,
unsigned long irqflags, const char *devname, void *dev_id)
Then we just need to go through all of the drivers and either change
their interrupt handler prototype or change the flavor of request_irq.
It is a bit of a pain but we should be able to do that without breaking
any drivers. Which it looks like we are in real danger of if someone
goes through them all interrupt handlers that are using the irq
argument and change them all at once. Especially since most of those
drivers are old an rarely used right now.
Eric
next prev parent reply other threads:[~2007-10-19 18:38 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-19 7:54 Jeff Garzik
2007-10-19 7:55 ` [PATCH 1/9] irq-remove: core Jeff Garzik
2007-10-19 17:27 ` Eric W. Biederman
2007-10-19 17:48 ` Jeff Garzik
2007-10-19 18:04 ` Eric W. Biederman
2007-10-19 18:21 ` Jeff Garzik
2007-10-19 19:50 ` Eric W. Biederman
2007-10-19 19:58 ` Jeff Garzik
2007-10-19 23:13 ` Eric W. Biederman
2007-10-19 23:46 ` Jeff Garzik
2007-10-19 23:53 ` Jeff Garzik
2007-10-19 7:55 ` [PATCH 2/9] irq-remove: arch non-trivial Jeff Garzik
2007-10-19 16:54 ` Jeremy Fitzhardinge
2007-10-19 17:31 ` Jeff Garzik
2007-10-19 17:50 ` Jeff Garzik
2007-10-19 17:11 ` Eric W. Biederman
2007-10-19 17:16 ` Jeff Garzik
2007-10-19 19:38 ` Eric W. Biederman
2007-10-19 7:56 ` [PATCH 3/9] irq-remove: arch trivial Jeff Garzik
2007-10-19 7:56 ` [PATCH 4/9] irq-remove: driver non-trivial Jeff Garzik
2007-10-19 18:19 ` Eric W. Biederman
2007-10-19 18:36 ` Jeff Garzik
2007-10-19 7:57 ` [PATCH 5/9] irq-remove: net driver trivial Jeff Garzik
2007-10-19 7:57 ` [PATCH 6/9] irq-remove: sound " Jeff Garzik
2007-10-19 7:58 ` [PATCH 7/9] irq-remove: scsi " Jeff Garzik
2007-10-19 13:00 ` Salyzyn, Mark
2007-10-26 21:35 ` Andrew Morton
2007-10-26 21:47 ` Jeff Garzik
2007-10-26 23:50 ` Arjan van de Ven
2007-10-27 0:12 ` Jeff Garzik
2007-10-27 0:16 ` Arjan van de Ven
2007-10-27 0:37 ` Jeff Garzik
2007-10-27 5:31 ` Arjan van de Ven
2007-10-27 7:06 ` Jeff Garzik
2007-10-27 7:46 ` Eric W. Biederman
2007-10-27 14:17 ` Arjan van de Ven
2007-10-19 7:58 ` [PATCH 8/9] irq-remove: " Jeff Garzik
2007-10-19 7:59 ` [PATCH 9/9] irq-remove: misc fixes and cleanups Jeff Garzik
2007-10-19 14:53 ` [PATCH 0/9] Remove 'irq' argument from all irq handlers Thomas Gleixner
2007-10-19 18:38 ` Eric W. Biederman [this message]
2007-10-19 18:57 ` Jeff Garzik
2007-10-19 19:02 ` Jeff Garzik
2007-10-19 19:07 ` Ingo Molnar
2007-10-19 19:35 ` Eric W. Biederman
2007-10-19 19:41 ` Thomas Gleixner
2007-10-19 19:55 ` Jeff Garzik
2007-10-19 18:45 ` Mark Gross
2007-10-20 6:07 ` Greg KH
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=m1bqavgdbf.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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®