Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote: > > 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. > > For the large sweeps through the tree, these patches are grouped into > "trivial" changes -- simply removing the unused irq arg -- or all other > changes. Very cool stuff, I like it :) greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote: 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. For the large sweeps through the tree, these patches are grouped into trivial changes -- simply removing the unused irq arg -- or all other changes. Very cool stuff, I like it :) greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Thomas Gleixner wrote: On Fri, 19 Oct 2007, Eric W. Biederman wrote: Ingo Molnar <[EMAIL PROTECTED]> writes: * Eric W. Biederman <[EMAIL PROTECTED]> wrote: 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. the get_irq_regs() approach worked out really well. We should do a get_irq_nr() and be done with it? The problem are some drivers today pass in 0 for their irq number to flag that they are calling the interrupt handler in a polling mode (not from interrupt context?) so the same logic doesn't quite apply. Do what you suggest would likely break those drivers. How many of them do we have ? This is a wilful abuse of the API, so its not a big damage if they break. I would prefer to simply clean up the drivers such that get_irqfunc_irq() and set_irqfunc_irq() are not needed. One of the many reasons why I'm explicitly not pushing it upstream yet :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, 19 Oct 2007, Eric W. Biederman wrote: > Ingo Molnar <[EMAIL PROTECTED]> writes: > > > * Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > > >> > 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. > > > > the get_irq_regs() approach worked out really well. We should do a > > get_irq_nr() and be done with it? > > The problem are some drivers today pass in 0 for their irq number > to flag that they are calling the interrupt handler in a polling > mode (not from interrupt context?) so the same logic doesn't quite apply. > > Do what you suggest would likely break those drivers. How many of them do we have ? This is a wilful abuse of the API, so its not a big damage if they break. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Ingo Molnar <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> wrote: > >> > 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. > > the get_irq_regs() approach worked out really well. We should do a > get_irq_nr() and be done with it? The problem are some drivers today pass in 0 for their irq number to flag that they are calling the interrupt handler in a polling mode (not from interrupt context?) so the same logic doesn't quite apply. Do what you suggest would likely break those drivers. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
* Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > 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. the get_irq_regs() approach worked out really well. We should do a get_irq_nr() and be done with it? (Then once the mechanic conversion has been done we could eliminate all uses of get_irq_nr() and remove the small overhead it takes to maintain this per-cpu value in the irq entry layer.) full ACK on the concept from me too. Please go ahead! :) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Jeff Garzik wrote: Once that effort is done, everything should be in the 'trivial' pile and not have the logic that you are worried about (and thus there would be no need to add an additional branch to the error handling path). er, s/error/irq/ the perils of a multi-threaded brain... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Eric W. Biederman wrote: 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. This is why I'm taking it slow, and not rushing to get this upstream :) I am finding a ton of bugs in each get_irqfunc_irq() driver, so I would rather patiently sift through them, and push fixes and cleanups upstream. Once that effort is done, everything should be in the 'trivial' pile and not have the logic that you are worried about (and thus there would be no need to add an additional branch to the error handling path). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote: > > WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE then whats the point ? > > 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. why not? --mgross > > 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. > > For the large sweeps through the tree, these patches are grouped into > "trivial" changes -- simply removing the unused irq arg -- or all other > changes. > >[IRQ ARG REMOVAL] core interrupt delivery infrastructure updates >[IRQ ARG REMOVAL] various non-trivial arch updates >[IRQ ARG REMOVAL] trivial arch updates >[IRQ ARG REMOVAL] non-trivial driver updates >[IRQ ARG REMOVAL] trivial net driver updates >[IRQ ARG REMOVAL] trivial sound driver updates >[IRQ ARG REMOVAL] trivial scsi driver updates >[IRQ ARG REMOVAL] trivial driver updates >[IRQ ARG REMOVAL] x86-64 build fixes, cleanups > > WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Thomas Gleixner <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
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. 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. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] Remove 'irq' argument from all irq handlers
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. For the large sweeps through the tree, these patches are grouped into "trivial" changes -- simply removing the unused irq arg -- or all other changes. [IRQ ARG REMOVAL] core interrupt delivery infrastructure updates [IRQ ARG REMOVAL] various non-trivial arch updates [IRQ ARG REMOVAL] trivial arch updates [IRQ ARG REMOVAL] non-trivial driver updates [IRQ ARG REMOVAL] trivial net driver updates [IRQ ARG REMOVAL] trivial sound driver updates [IRQ ARG REMOVAL] trivial scsi driver updates [IRQ ARG REMOVAL] trivial driver updates [IRQ ARG REMOVAL] x86-64 build fixes, cleanups WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Ingo Molnar [EMAIL PROTECTED] writes: * Eric W. Biederman [EMAIL PROTECTED] wrote: 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. the get_irq_regs() approach worked out really well. We should do a get_irq_nr() and be done with it? The problem are some drivers today pass in 0 for their irq number to flag that they are calling the interrupt handler in a polling mode (not from interrupt context?) so the same logic doesn't quite apply. Do what you suggest would likely break those drivers. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Thomas Gleixner wrote: On Fri, 19 Oct 2007, Eric W. Biederman wrote: Ingo Molnar [EMAIL PROTECTED] writes: * Eric W. Biederman [EMAIL PROTECTED] wrote: 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. the get_irq_regs() approach worked out really well. We should do a get_irq_nr() and be done with it? The problem are some drivers today pass in 0 for their irq number to flag that they are calling the interrupt handler in a polling mode (not from interrupt context?) so the same logic doesn't quite apply. Do what you suggest would likely break those drivers. How many of them do we have ? This is a wilful abuse of the API, so its not a big damage if they break. I would prefer to simply clean up the drivers such that get_irqfunc_irq() and set_irqfunc_irq() are not needed. One of the many reasons why I'm explicitly not pushing it upstream yet :) Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Jeff Garzik wrote: Once that effort is done, everything should be in the 'trivial' pile and not have the logic that you are worried about (and thus there would be no need to add an additional branch to the error handling path). er, s/error/irq/ the perils of a multi-threaded brain... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
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. 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. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] Remove 'irq' argument from all irq handlers
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. For the large sweeps through the tree, these patches are grouped into trivial changes -- simply removing the unused irq arg -- or all other changes. [IRQ ARG REMOVAL] core interrupt delivery infrastructure updates [IRQ ARG REMOVAL] various non-trivial arch updates [IRQ ARG REMOVAL] trivial arch updates [IRQ ARG REMOVAL] non-trivial driver updates [IRQ ARG REMOVAL] trivial net driver updates [IRQ ARG REMOVAL] trivial sound driver updates [IRQ ARG REMOVAL] trivial scsi driver updates [IRQ ARG REMOVAL] trivial driver updates [IRQ ARG REMOVAL] x86-64 build fixes, cleanups WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, 19 Oct 2007, Eric W. Biederman wrote: Ingo Molnar [EMAIL PROTECTED] writes: * Eric W. Biederman [EMAIL PROTECTED] wrote: 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. the get_irq_regs() approach worked out really well. We should do a get_irq_nr() and be done with it? The problem are some drivers today pass in 0 for their irq number to flag that they are calling the interrupt handler in a polling mode (not from interrupt context?) so the same logic doesn't quite apply. Do what you suggest would likely break those drivers. How many of them do we have ? This is a wilful abuse of the API, so its not a big damage if they break. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
* Eric W. Biederman [EMAIL PROTECTED] wrote: 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. the get_irq_regs() approach worked out really well. We should do a get_irq_nr() and be done with it? (Then once the mechanic conversion has been done we could eliminate all uses of get_irq_nr() and remove the small overhead it takes to maintain this per-cpu value in the irq entry layer.) full ACK on the concept from me too. Please go ahead! :) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote: WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE then whats the point ? 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. why not? --mgross 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. For the large sweeps through the tree, these patches are grouped into trivial changes -- simply removing the unused irq arg -- or all other changes. [IRQ ARG REMOVAL] core interrupt delivery infrastructure updates [IRQ ARG REMOVAL] various non-trivial arch updates [IRQ ARG REMOVAL] trivial arch updates [IRQ ARG REMOVAL] non-trivial driver updates [IRQ ARG REMOVAL] trivial net driver updates [IRQ ARG REMOVAL] trivial sound driver updates [IRQ ARG REMOVAL] trivial scsi driver updates [IRQ ARG REMOVAL] trivial driver updates [IRQ ARG REMOVAL] x86-64 build fixes, cleanups WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Thomas Gleixner [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] Remove 'irq' argument from all irq handlers
Eric W. Biederman wrote: 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. This is why I'm taking it slow, and not rushing to get this upstream :) I am finding a ton of bugs in each get_irqfunc_irq() driver, so I would rather patiently sift through them, and push fixes and cleanups upstream. Once that effort is done, everything should be in the 'trivial' pile and not have the logic that you are worried about (and thus there would be no need to add an additional branch to the error handling path). Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
