[PATCH 01/15] ARM minor irq handler cleanups - Kernel

This is a discussion on [PATCH 01/15] ARM minor irq handler cleanups - Kernel ; Avoid confusion by /not/ passing an unused pointer to arm_rtc_interrupt() This change's main purpose is to prepare for the patchset in jgarzik/misc-2.6.git#irq-remove, that explores removal of the never-used 'irq' argument in each interrupt handler. Signed-off-by: Jeff Garzik --- arch/arm/mach-integrator/time.c | ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: [PATCH 01/15] ARM minor irq handler cleanups

  1. [PATCH 01/15] ARM minor irq handler cleanups

    Avoid confusion by /not/ passing an unused pointer to
    arm_rtc_interrupt()

    This change's main purpose is to prepare for the patchset in
    jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    never-used 'irq' argument in each interrupt handler.

    Signed-off-by: Jeff Garzik
    ---
    arch/arm/mach-integrator/time.c | 2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)

    diff --git a/arch/arm/mach-integrator/time.c b/arch/arm/mach-integrator/time.c
    index 5278f58..5235f64 100644
    --- a/arch/arm/mach-integrator/time.c
    +++ b/arch/arm/mach-integrator/time.c
    @@ -125,7 +125,7 @@ static int rtc_probe(struct amba_device *dev, void *id)
    xtime.tv_sec = __raw_readl(rtc_base + RTC_DR);

    ret = request_irq(dev->irq[0], arm_rtc_interrupt, IRQF_DISABLED,
    - "rtc-pl030", dev);
    + "rtc-pl030", NULL);
    if (ret)
    goto map_out;

    --
    1.5.4.1

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 02/15] [SPARC] minor irq handler cleanups

    From: Jeff Garzik
    Date: Fri, 18 Apr 2008 19:22:46 -0400 (EDT)

    > - mark timer_interrupt() static
    >
    > - sparc_floppy_request_irq() prototype should use irq_handler_t
    >
    > Signed-off-by: Jeff Garzik


    Acked-by: David S. Miller
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 01/15] ARM minor irq handler cleanups

    On Fri, 18 Apr 2008 19:22:45 -0400 (EDT)
    Jeff Garzik wrote:

    > Avoid confusion by /not/ passing an unused pointer to
    > arm_rtc_interrupt()
    >
    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.


    #irq-remove doesn't seem to be included in the #ALL branch which
    I'm grabbing?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 01/15] ARM minor irq handler cleanups

    On Fri, Apr 18, 2008 at 07:22:45PM -0400, Jeff Garzik wrote:

    > Avoid confusion by /not/ passing an unused pointer to
    > arm_rtc_interrupt()


    Looks OK to me.


    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.


    What do you mean? I know at least one of two interrupt handlers
    in-tree that use their 'irq' arguments.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 01/15] ARM minor irq handler cleanups

    Lennert Buytenhek wrote:
    > On Fri, Apr 18, 2008 at 07:22:45PM -0400, Jeff Garzik wrote:
    >> This change's main purpose is to prepare for the patchset in
    >> jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    >> never-used 'irq' argument in each interrupt handler.

    >
    > What do you mean? I know at least one of two interrupt handlers
    > in-tree that use their 'irq' arguments.


    They can use new function get_irqfunc_irq(), similar to the existing
    method of getting pt_regs for the tiny number of users who need that
    sort of info, when pt_regs was removed.

    But after having gone over, literally, every single interrupt handler in
    the kernel, I can safely say that 99.8% never reference that argument,
    and 0.1% that do already have the same information via another route.

    That leaves only a few drivers that need it without modification, and
    even fewer drivers that need it after modification.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 01/15] ARM minor irq handler cleanups

    Andrew Morton wrote:
    > On Fri, 18 Apr 2008 19:22:45 -0400 (EDT)
    > Jeff Garzik wrote:
    >
    >> Avoid confusion by /not/ passing an unused pointer to
    >> arm_rtc_interrupt()
    >>
    >> This change's main purpose is to prepare for the patchset in
    >> jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    >> never-used 'irq' argument in each interrupt handler.

    >
    > #irq-remove doesn't seem to be included in the #ALL branch which
    > I'm grabbing?


    I certainly welcome the exposure....... but it would be a huge pain for
    you IMO because of the constant breakage.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 01/15] ARM minor irq handler cleanups

    On Fri, 18 Apr 2008 20:21:07 -0400 Jeff Garzik wrote:

    > Andrew Morton wrote:
    > > On Fri, 18 Apr 2008 19:22:45 -0400 (EDT)
    > > Jeff Garzik wrote:
    > >
    > >> Avoid confusion by /not/ passing an unused pointer to
    > >> arm_rtc_interrupt()
    > >>
    > >> This change's main purpose is to prepare for the patchset in
    > >> jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > >> never-used 'irq' argument in each interrupt handler.

    > >
    > > #irq-remove doesn't seem to be included in the #ALL branch which
    > > I'm grabbing?

    >
    > I certainly welcome the exposure....... but it would be a huge pain for
    > you IMO because of the constant breakage.
    >


    wow.

    1084 files changed, 2363 insertions(+), 1934 deletions(-)

    I didn't realise you'd changed all the interrupt handlers too. Good luck
    with that

    Is it a flag day or do we have a migration plan? I'd have thought that we
    could do a request_irq_new(irqreturn_t (*)(void *d)) and keep things
    compatible?





    Actually, that tree applies reasonably sanely to the full -mm lineup.
    There are rejects of course, but they're easily fixed and a lot are due to
    file motion which git will handle anyway,

    The bigger problem is newly-added irq handlers which your patch doesn't
    know about:

    y:/usr/src/25> grep '^+.*request_irq[(]' patches/*.patch | wc -l
    74

    If we had a migration plan (ie: request_irq_new(), above) then this of
    course wouldn't be a problem.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH 05/15] drivers/char: minor irq handler cleanups

    On Fri, Apr 18, 2008 at 07:22:51PM -0400, Jeff Garzik wrote:
    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.


    The changes look sane, (for the drivers that I'm involved with).

    However, you're now adding a second parameter to my interrupt
    routines: "polled" to replace the "never used" irq parameter. (which
    /was/ used to determine wether we were called polled or not...

    On the other hand, most hardware should work if you remove the if
    (!polled).


    You added a "XXX Using free_irq in the interrupt is not wise!". When I
    wrote that code, I didn't know about this. These lines triggered when
    the level-triggered PCI interrupt stuck "active" this would mean that
    NO userspace code would get executed anymore: Hard lock up. Difficult
    to debug. This happend a few times during development when the code
    behind the "if (!polled)": "tell the hardware we've seen the
    interrupt" didn't work. On the other hand, some failures in the field
    have triggered this. So I think it's wise to keep it in. Disabling the
    interrupt on the card is not an option, because that's exactly what
    this is supposed to catch: We're unable to make the card stop
    interrupting the CPU.

    Note that it also doesn't work (i.e. hard lock of the machine) if some
    other driver is using the same interupt.

    Roger.

    --
    ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
    ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
    *-- BitWizard writes Linux device drivers for any device you may have! --*
    Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
    Does it sit on the couch all day? Is it unemployed? Please be specific!
    Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 01/15] ARM minor irq handler cleanups

    Russell King wrote:
    > On Fri, Apr 18, 2008 at 07:22:45PM -0400, Jeff Garzik wrote:
    >> Avoid confusion by /not/ passing an unused pointer to
    >> arm_rtc_interrupt()
    >>
    >> This change's main purpose is to prepare for the patchset in
    >> jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    >> never-used 'irq' argument in each interrupt handler.

    >
    > I don't see how these two things are connected. Yes, it's true that
    > this RTC driver doesn't use 'dev_id' but that's an entirely separate
    > issue to removing the 'int irq' argument.
    >
    > As I see it, this change is just unnecessarily adding to your workload
    > for this patch set.


    The added workload came from confusion created when I reviewed the code

    Therefore I considered it better to have to less confusing version of
    the code in my tree for future reviews, and ideally have the less
    confusing version of the code in upstream as well.

    I can remove the boilerplate paragraph from the patch description, if
    that's your main complaint.

    Jeff



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 01/15] ARM minor irq handler cleanups

    On Fri, Apr 18, 2008 at 07:22:45PM -0400, Jeff Garzik wrote:
    > Avoid confusion by /not/ passing an unused pointer to
    > arm_rtc_interrupt()
    >
    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.


    I don't see how these two things are connected. Yes, it's true that
    this RTC driver doesn't use 'dev_id' but that's an entirely separate
    issue to removing the 'int irq' argument.

    As I see it, this change is just unnecessarily adding to your workload
    for this patch set.

    --
    Russell King
    Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
    maintainer of:
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 04/15] [PPC] minor irq handler cleanups


    On Apr 18, 2008, at 6:22 PM, Jeff Garzik wrote:
    > - whitespace cleanups
    >
    > - remove pointless prototype (uses always follow func implementation)
    >
    > - 'irq' argument is often used purely as a local variable. rename
    > argument to 'dummy' and define 'irq' as local to make this plain.
    >
    > - remove pointless casts from void*
    >
    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.
    >
    > Signed-off-by: Jeff Garzik


    arch/ppc is pretty much left for dead at this point. I'm guessing we
    will end up removing it 2.6.27 if we follow through with our plans of
    killing it this summer.

    Acked-by: Kumar Gala

    - k
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 01/15] ARM minor irq handler cleanups

    On Fri, Apr 18, 2008 at 08:25:37PM -0400, Jeff Garzik wrote:

    > >>This change's main purpose is to prepare for the patchset in
    > >>jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > >>never-used 'irq' argument in each interrupt handler.

    > >
    > >What do you mean? I know at least one of two interrupt handlers
    > >in-tree that use their 'irq' arguments.

    >
    > They can use new function get_irqfunc_irq(), similar to the existing
    > method of getting pt_regs for the tiny number of users who need that
    > sort of info, when pt_regs was removed.


    Well, you said that the 'irq' argument was never-used, I was merely
    saying that I found that not to be the case.


    > But after having gone over, literally, every single interrupt handler in
    > the kernel, I can safely say that 99.8% never reference that argument,
    > and 0.1% that do already have the same information via another route.
    >
    > That leaves only a few drivers that need it without modification, and
    > even fewer drivers that need it after modification.


    Sounds good.

    Very-much-liked-by: Lennert Buytenhek
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH 05/15] drivers/char: minor irq handler cleanups

    On Fri, Apr 18, 2008 at 07:22:51PM -0400, Jeff Garzik wrote:
    > +++ b/drivers/char/cyclades.c
    > if (unlikely(!ISZLOADED(*cinfo))) {
    > #ifdef CY_DEBUG_INTERRUPTS
    > - printk(KERN_DEBUG "cyz_interrupt: board not yet loaded "
    > - "(IRQ%d).\n", irq);
    > + printk(KERN_DEBUG "cyz_interrupt: board not yet loaded\n");


    If you are debugging IRQ funnies you really really want to know which
    IRQ or which port.

    Ack the rest on the base the __foo_interrupt uglies will go away with the
    final change over. A follow up patch to tweak cyclades would be useful and also
    to know from Andrew if these are going in so they don't clash with the coding
    style cleanups also queued.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH 01/15] ARM minor irq handler cleanups

    Andrew Morton wrote:
    > I didn't realise you'd changed all the interrupt handlers too. Good luck
    > with that


    Hey, I did, and last time I checked (months ago, to be honest) it boots
    on x86


    > Is it a flag day or do we have a migration plan? I'd have thought that we
    > could do a request_irq_new(irqreturn_t (*)(void *d)) and keep things
    > compatible?
    >
    >
    >
    >
    >
    > Actually, that tree applies reasonably sanely to the full -mm lineup.
    > There are rejects of course, but they're easily fixed and a lot are due to
    > file motion which git will handle anyway,
    >
    > The bigger problem is newly-added irq handlers which your patch doesn't
    > know about:
    >
    > y:/usr/src/25> grep '^+.*request_irq[(]' patches/*.patch | wc -l
    > 74
    >
    > If we had a migration plan (ie: request_irq_new(), above) then this of
    > course wouldn't be a problem.


    A fair comment...

    My goal has been to get the tree to the point where a flag-day patch
    "make the obvious change to each irq handler" /could/ be applied --
    following the lead of the huge 'pt_regs arg removal' that went in in Oct
    2006.

    Since I knew reaching that point would take time -- I started this
    project in Aug/Sep 2006 -- I simply didn't bother with a migration plan
    at the time. I figured once the tree was prepped, which has taken over
    a year, _then_ I would waste maintainers' time discussing migration.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH 01/15] ARM minor irq handler cleanups

    On Sun, Apr 20, 2008 at 06:17:32PM -0400, Jeff Garzik wrote:
    > Andrew Morton wrote:
    > >If we had a migration plan (ie: request_irq_new(), above) then this of
    > >course wouldn't be a problem.

    >
    > A fair comment...


    Then we'll be stuck with request_irq_new() for the next 10 years or so.

    FWIW (and appologies for hijacking the topic), Jeffs discussion about
    changing the ARM integrator RTC driver has triggered a number of cleanups
    in the ARM tree:

    - converting the ARM integrator PL030 RTC driver to a RTC class driver

    ... which triggered:

    - removal of the ARM dyntick code and the unused generic changes
    (including the s390 and sh bits which look like they've never been
    functional.)

    ... which triggered:

    - attempting to fix a circular include dependency involving linux/irq.h
    and asm-arm/mach/irq.h

    ... which then triggered:

    - allowing PXA platform class to build for more than one PXA platform
    at a time, so I don't have to run 20 (!) separate kernel builds to
    check them all for breakage caused by the elimination of the
    circular dependency.

    ... which also allowed me to find several PXA platform build bugs.

    Thanks Jeff.

    I'm not intending pushing this stuff into mainline for a bit, although
    it will appear in my public tree for others to start looking at and for
    them to be aware of.

    That does mean that, unfortunately, akpm's going to see those changes
    and it might cause Andrew some headaches - sorry about that. You may
    wish to avoid pulling the ARM 'devel' branch until the dust settles.

    (Obviously the appropriate fixes will be head towards Linus at the
    appropriate time.)

    --
    Russell King
    Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
    maintainer of:
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH 01/15] ARM minor irq handler cleanups

    Russell King wrote:
    > On Sun, Apr 20, 2008 at 06:17:32PM -0400, Jeff Garzik wrote:
    >> Andrew Morton wrote:
    >>> If we had a migration plan (ie: request_irq_new(), above) then this of
    >>> course wouldn't be a problem.

    >> A fair comment...

    >
    > Then we'll be stuck with request_irq_new() for the next 10 years or so.


    (un-hijacking topic )

    Another fair comment. I am secretly hoping for the ease of a flag day
    (a la pt_regs) rather than a decade-long transition, but I readily to
    confess to dodging the entire issue by doing all these cleanups first

    Jeff




    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH 05/15] drivers/char: minor irq handler cleanups

    Alan Cox wrote:
    > On Fri, Apr 18, 2008 at 07:22:51PM -0400, Jeff Garzik wrote:
    >> +++ b/drivers/char/cyclades.c
    >> if (unlikely(!ISZLOADED(*cinfo))) {
    >> #ifdef CY_DEBUG_INTERRUPTS
    >> - printk(KERN_DEBUG "cyz_interrupt: board not yet loaded "
    >> - "(IRQ%d).\n", irq);
    >> + printk(KERN_DEBUG "cyz_interrupt: board not yet loaded\n");

    >
    > If you are debugging IRQ funnies you really really want to know which
    > IRQ or which port.
    >
    > Ack the rest on the base the __foo_interrupt uglies will go away with the
    > final change over. A follow up patch to tweak cyclades would be useful and also
    > to know from Andrew if these are going in so they don't clash with the coding
    > style cleanups also queued.


    In the stuff I pushed just now, I took the attitude "if there was
    remotely a peep from anyone, do not send it"

    So the stuff ya'll mentioned shouldn't be in the push at all.

    In particular, I wanted to note the __foo_interrupt stuff will not go
    away when I remove the 'irq' arg from all handlers... we still need to
    indicate two separate callsites (local poll or system irq) to achieve
    the same behavior as exists today.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH 13/15] [X86] standard vm86 irq handler


    * Jeff Garzik wrote:

    > Prefer 'void *dev_id' argument for passing data from request_irq() to
    > each per-irq handler invocation.


    thanks, applied.

    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.


    neat ...

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH 03/15] [BLACKFIN] minor irq handler cleanups

    On Sat, Apr 19, 2008 at 7:22 AM, Jeff Garzik wrote:
    > - time_sched_init() should use standard irq_handler_t
    >
    > - sys_timer0_int_handler() should not take 'regs' third argument
    >
    > - remove pointless cast from void*
    >
    > This change's main purpose is to prepare for the patchset in
    > jgarzik/misc-2.6.git#irq-remove, that explores removal of the
    > never-used 'irq' argument in each interrupt handler.
    >
    > Signed-off-by: Jeff Garzik
    > ---
    > arch/blackfin/kernel/time.c | 5 ++---
    > arch/blackfin/oprofile/timer_int.c | 5 ++---
    > 2 files changed, 4 insertions(+), 6 deletions(-)
    >
    > diff --git a/arch/blackfin/kernel/time.c b/arch/blackfin/kernel/time.c
    > index 9bdc8f9..715b394 100644
    > --- a/arch/blackfin/kernel/time.c
    > +++ b/arch/blackfin/kernel/time.c
    > @@ -39,8 +39,7 @@
    > /* This is an NTP setting */
    > #define TICK_SIZE (tick_nsec / 1000)
    >
    > -static void time_sched_init(irqreturn_t(*timer_routine)
    > - (int, void *));
    > +static void time_sched_init(irq_handler_t timer_routine);
    > static unsigned long gettimeoffset(void);
    >
    > static struct irqaction bfin_timer_irq = {
    > @@ -64,7 +63,7 @@ static struct irqaction bfin_timer_irq = {
    > #define TIME_SCALE 1
    >
    > static void
    > -time_sched_init(irqreturn_t(*timer_routine) (int, void *))
    > +time_sched_init(irq_handler_t timer_routine)
    > {
    > u32 tcount;
    >
    > diff --git a/arch/blackfin/oprofile/timer_int.c b/arch/blackfin/oprofile/timer_int.c
    > index 6c6f860..e2c825a 100644
    > --- a/arch/blackfin/oprofile/timer_int.c
    > +++ b/arch/blackfin/oprofile/timer_int.c
    > @@ -40,10 +40,9 @@ static void disable_sys_timer0()
    > {
    > }
    >
    > -static irqreturn_t sys_timer0_int_handler(int irq, void *dev_id,
    > - struct pt_regs *regs)
    > +static irqreturn_t sys_timer0_int_handler(int irq, void *dev_id)
    > {
    > - oprofile_add_sample(regs, 0);
    > + oprofile_add_sample(get_irq_regs(), 0);
    > return IRQ_HANDLED;
    > }
    >


    Sorry for the delay, it is pretty good for Blackfin.

    Acked-by: Bryan Wu

    -Bryan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH 05/15] drivers/char: minor irq handler cleanups


    On Sat, 2008-04-19 at 08:00 +0200, Rogier Wolff wrote:
    >
    > You added a "XXX Using free_irq in the interrupt is not wise!". When I
    > wrote that code, I didn't know about this. These lines triggered when
    > the level-triggered PCI interrupt stuck "active" this would mean that
    > NO userspace code would get executed anymore: Hard lock up. Difficult
    > to debug. This happend a few times during development when the code
    > behind the "if (!polled)": "tell the hardware we've seen the
    > interrupt" didn't work. On the other hand, some failures in the field
    > have triggered this. So I think it's wise to keep it in. Disabling the
    > interrupt on the card is not an option, because that's exactly what
    > this is supposed to catch: We're unable to make the card stop
    > interrupting the CPU.
    >
    > Note that it also doesn't work (i.e. hard lock of the machine) if some
    > other driver is using the same interupt.


    You should let the kernel generic code deal with the runaway interrupt,
    it should be capable of doing so nowadays pretty reliably.

    free_irq() is definitely not going to be happy when it start messing
    with /proc from an interrupt... It will at least give you a WARN_ON.

    Ben.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast