29 Mar, 2011

1 commit


19 Feb, 2011

6 commits

  • That's the data structure chip functions get provided. Also allow them
    to signal the core code that they updated the flags in irq_data.state
    by returning IRQ_SET_MASK_OK_NOCOPY. The default is unchanged.

    The type bits should be accessed via:

    val = irqd_get_trigger_type(irqdata);
    and
    irqd_set_trigger_type(irqdata, val);

    Coders who access them directly will be tracked down and slapped with
    stinking trouts.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • Keep status in sync until all users are fixed.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • No users outside of core.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • Handle IRQ_DISABLED consistent.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • Create irq_disable/enable and use them to keep the flags consistent.

    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     
  • Lars-Peter Clausen pointed out:

    I stumbled upon this while looking through the existing archs using
    SPARSE_IRQ. Even with SPARSE_IRQ the NR_IRQS is still the upper
    limit for the number of IRQs.

    Both PXA and MMP set NR_IRQS to IRQ_BOARD_START, with
    IRQ_BOARD_START being the number of IRQs used by the core.

    In various machine files the nr_irqs field of the ARM machine
    defintion struct is then set to "IRQ_BOARD_START + NR_BOARD_IRQS".

    As a result "nr_irqs" will greater then NR_IRQS which then again
    causes the "allocated_irqs" bitmap in the core irq code to be
    accessed beyond its size overwriting unrelated data.

    The core code really misses a sanity check there.

    This went unnoticed so far as by chance the compiler/linker places
    data behind that bitmap which gets initialized later on those affected
    platforms.

    So the obvious fix would be to add a sanity check in early_irq_init()
    and break all affected platforms. Though that check wants to be
    backported to stable as well, which will require to fix all known
    problematic platforms and probably some more yet not known ones as
    well. Lots of churn.

    A way simpler solution is to allocate a slightly larger bitmap and
    avoid the whole churn w/o breaking anything. Add a few warnings when
    an arch returns utter crap.

    Reported-by: Lars-Peter Clausen
    Signed-off-by: Thomas Gleixner
    Cc: stable@kernel.org # .37
    Cc: Haojian Zhuang
    Cc: Eric Miao
    Cc: Peter Zijlstra

    Thomas Gleixner
     

04 Oct, 2010

3 commits


09 Aug, 2009

1 commit


16 Oct, 2008

2 commits

  • add CONFIG_HAVE_SPARSE_IRQ to for use condensed array.
    Get rid of irq_desc[] array assumptions.

    Preallocate 32 irq_desc, and irq_desc() will try to get more.

    ( No change in functionality is expected anywhere, except the odd build
    failure where we missed a code site or where a crossing commit itroduces
    new irq_desc[] usage. )

    v2: according to Eric, change get_irq_desc() to irq_desc()

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     
  • at this point nr_irqs is equal NR_IRQS

    convert a few easy users from NR_IRQS to dynamic nr_irqs.

    v2: according to Eric, we need to take care of arch without generic_hardirqs

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

13 Aug, 2007

1 commit


09 Aug, 2007

1 commit


02 Aug, 2007

1 commit

  • Marcin Slusarz reported a ne2k-pci "hung network interface" regression.

    delayed disable relies on the ability to re-trigger the interrupt in the
    case that a real interrupt happens after the software disable was set.
    In this case we actually disable the interrupt on the hardware level
    _after_ it occurred.

    On enable_irq, we need to re-trigger the interrupt. On i386 this relies
    on a hardware resend mechanism (send_IPI_self()).

    Actually we only need the resend for edge type interrupts. Level type
    interrupts come back once enable_irq() re-enables the interrupt line.

    I assume that the interrupt in question is level triggered because it is
    shared and above the legacy irqs 0-15:

    17: 12 IO-APIC-fasteoi eth1, eth0

    Looking into the IO_APIC code, the resend via send_IPI_self() happens
    unconditionally. So the resend is done for level and edge interrupts.
    This makes the problem more mysterious.

    The code in question lib8390.c does

    disable_irq();
    fiddle_with_the_network_card_hardware()
    enable_irq();

    The fiddle_with_the_network_card_hardware() might cause interrupts,
    which are cleared in the same code path again,

    Marcin found that when he disables the irq line on the hardware level
    (removing the delayed disable) the card is kept alive.

    So the difference is that we can get a resend on enable_irq, when an
    interrupt happens during the time, where we are in the disabled region.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

07 Oct, 2006

1 commit


17 Sep, 2006

1 commit

  • Fix a bug where the IRQ_PENDING flag is never cleared and the ISR is called
    endlessly without an actual interrupt.

    Signed-off-by: Imre Deak
    Acked-by: Thomas Gleixner
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Imre Deak
     

30 Jun, 2006

2 commits