1. 19 2月, 2011 23 次提交
  2. 11 2月, 2011 1 次提交
    • D
      genirq: Call bus_lock/unlock functions in setup_irq() · 986c011d
      David Daney 提交于
      irq_chips that supply .irq_bus_lock/.irq_bus_sync_unlock functions,
      expect that the other chip methods will be called inside of calls to
      the pair.  If this expectation is not met, things tend to not work.
      
      Make setup_irq() call chip_bus_lock()/chip_bus_sync_unlock() too.
      
      For the vast majority of irq_chips, this will be a NOP as most don't
      have these bus lock functions.
      
      [ tglx: No we don't want to call that in __setup_irq(). Way too many
        	error exit pathes. ]
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      LKML-Reference: <1297296265-18680-1-git-send-email-ddaney@caviumnetworks.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      986c011d
  3. 08 2月, 2011 1 次提交
  4. 31 1月, 2011 1 次提交
  5. 23 1月, 2011 1 次提交
    • B
      genirq: Add IRQ affinity notifiers · cd7eab44
      Ben Hutchings 提交于
      When initiating I/O on a multiqueue and multi-IRQ device, we may want
      to select a queue for which the response will be handled on the same
      or a nearby CPU.  This requires a reverse-map of IRQ affinity.  Add a
      notification mechanism to support this.
      
      This is based closely on work by Thomas Gleixner <tglx@linutronix.de>.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Cc: linux-net-drivers@solarflare.com
      Cc: Tom Herbert <therbert@google.com>
      Cc: David Miller <davem@davemloft.net>
      LKML-Reference: <1295470904.11126.84.camel@bwh-desktop>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      cd7eab44
  6. 07 1月, 2011 1 次提交
  7. 23 10月, 2010 1 次提交
  8. 22 10月, 2010 1 次提交
  9. 04 10月, 2010 8 次提交
  10. 29 7月, 2010 1 次提交
    • I
      irq: Add new IRQ flag IRQF_NO_SUSPEND · 685fd0b4
      Ian Campbell 提交于
      A small number of users of IRQF_TIMER are using it for the implied no
      suspend behaviour on interrupts which are not timer interrupts.
      
      Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
      __IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: xen-devel@lists.xensource.com
      Cc: linux-input@vger.kernel.org
      Cc: linuxppc-dev@ozlabs.org
      Cc: devicetree-discuss@lists.ozlabs.org
      LKML-Reference: <1280398595-29708-1-git-send-email-ian.campbell@citrix.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      685fd0b4
  11. 09 6月, 2010 1 次提交
    • T
      genirq: Deal with desc->set_type() changing desc->chip · 46732475
      Thomas Gleixner 提交于
      The set_type() function can change the chip implementation when the
      trigger mode changes. That might result in using an non-initialized
      irq chip when called from __setup_irq() or when called via
      set_irq_type() on an already enabled irq. 
      
      The set_irq_type() function should not be called on an enabled irq,
      but because we forgot to put a check into it, we have a bunch of users
      which grew the habit of doing that and it never blew up as the
      function is serialized via desc->lock against all users of desc->chip
      and they never hit the non-initialized irq chip issue.
      
      The easy fix for the __setup_irq() issue would be to move the
      irq_chip_set_defaults(desc->chip) call after the trigger setting to
      make sure that a chip change is covered.
      
      But as we have already users, which do the type setting after
      request_irq(), the safe fix for now is to call irq_chip_set_defaults()
      from __irq_set_trigger() when desc->set_type() changed the irq chip.
      
      It needs a deeper analysis whether we should refuse to change the chip
      on an already enabled irq, but that'd be a large scale change to fix
      all the existing users. So that's neither stable nor 2.6.35 material.
      Reported-by: NEsben Haabendal <eha@doredevelopment.dk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
      Cc: stable@kernel.org
      46732475
反馈
建议
客服 返回
顶部