1. 14 9月, 2016 1 次提交
    • C
      genirq: Expose interrupt information through sysfs · ecb3f394
      Craig Gallek 提交于
      Information about interrupts is exposed via /proc/interrupts, but the
      format of that file has changed over kernel versions and differs across
      architectures. It also has varying column numbers depending on hardware.
      
      That all makes it hard for tools to parse.
      
      To solve this, expose the information through sysfs so each irq attribute
      is in a separate file in a consistent, machine parsable way.
      
      This feature is only available when both CONFIG_SPARSE_IRQ and
      CONFIG_SYSFS are enabled.
      
      Examples:
        /sys/kernel/irq/18/actions:	i801_smbus,ehci_hcd:usb1,uhci_hcd:usb7
        /sys/kernel/irq/18/chip_name:	IR-IO-APIC
        /sys/kernel/irq/18/hwirq:		18
        /sys/kernel/irq/18/name:		fasteoi
        /sys/kernel/irq/18/per_cpu_count:	0,0
        /sys/kernel/irq/18/type:		level
      
        /sys/kernel/irq/25/actions:	ahci0
        /sys/kernel/irq/25/chip_name:	IR-PCI-MSI
        /sys/kernel/irq/25/hwirq:		512000
        /sys/kernel/irq/25/name:		edge
        /sys/kernel/irq/25/per_cpu_count:	29036,0
        /sys/kernel/irq/25/type:		edge
      
      [ tglx: Moved kobject_del() under sparse_irq_lock, massaged code comments
        	and changelog ]
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Cc: David Decotigny <decot@google.com>
      Link: http://lkml.kernel.org/r/1473783291-122873-1-git-send-email-kraigatgoog@gmail.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      ecb3f394
  2. 02 5月, 2016 1 次提交
  3. 14 12月, 2015 1 次提交
    • T
      genirq: Free irq_desc with rcu · 425a5072
      Thomas Gleixner 提交于
      The new VMD device driver needs to iterate over a list of
      "demultiplexing" interrupts. Protecting that list with a lock is not
      possible because the list is also required in code pathes which hold
      irq descriptor lock. Therefor the demultiplexing interrupt handler
      would create a lock inversion scenario if it calls a demux handler
      with the list protection lock held.
      
      A solution for this is to free the irq descriptor via RCU, so the
      list can be walked with rcu read lock held.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Keith Busch <keith.busch@intel.com>
      425a5072
  4. 16 9月, 2015 6 次提交
  5. 15 9月, 2015 1 次提交
  6. 06 8月, 2015 1 次提交
  7. 08 7月, 2015 1 次提交
    • T
      hotplug: Prevent alloc/free of irq descriptors during cpu up/down · a8994181
      Thomas Gleixner 提交于
      When a cpu goes up some architectures (e.g. x86) have to walk the irq
      space to set up the vector space for the cpu. While this needs extra
      protection at the architecture level we can avoid a few race
      conditions by preventing the concurrent allocation/free of irq
      descriptors and the associated data.
      
      When a cpu goes down it moves the interrupts which are targeted to
      this cpu away by reassigning the affinities. While this happens
      interrupts can be allocated and freed, which opens a can of race
      conditions in the code which reassignes the affinities because
      interrupt descriptors might be freed underneath.
      
      Example:
      
      CPU1				CPU2
      cpu_up/down
       irq_desc = irq_to_desc(irq);
      				remove_from_radix_tree(desc);
       raw_spin_lock(&desc->lock);
      				free(desc);
      
      We could protect the irq descriptors with RCU, but that would require
      a full tree change of all accesses to interrupt descriptors. But
      fortunately these kind of race conditions are rather limited to a few
      things like cpu hotplug. The normal setup/teardown is very well
      serialized. So the simpler and obvious solution is:
      
      Prevent allocation and freeing of interrupt descriptors accross cpu
      hotplug.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: xiao jin <jin.xiao@intel.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20150705171102.063519515@linutronix.de
      a8994181
  8. 27 6月, 2015 2 次提交
  9. 25 6月, 2015 1 次提交
  10. 16 6月, 2015 1 次提交
  11. 12 6月, 2015 2 次提交
  12. 05 3月, 2015 1 次提交
    • R
      genirq / PM: Add flag for shared NO_SUSPEND interrupt lines · 17f48034
      Rafael J. Wysocki 提交于
      It currently is required that all users of NO_SUSPEND interrupt
      lines pass the IRQF_NO_SUSPEND flag when requesting the IRQ or the
      WARN_ON_ONCE() in irq_pm_install_action() will trigger.  That is
      done to warn about situations in which unprepared interrupt handlers
      may be run unnecessarily for suspended devices and may attempt to
      access those devices by mistake.  However, it may cause drivers
      that have no technical reasons for using IRQF_NO_SUSPEND to set
      that flag just because they happen to share the interrupt line
      with something like a timer.
      
      Moreover, the generic handling of wakeup interrupts introduced by
      commit 9ce7a258 (genirq: Simplify wakeup mechanism) only works
      for IRQs without any NO_SUSPEND users, so the drivers of wakeup
      devices needing to use shared NO_SUSPEND interrupt lines for
      signaling system wakeup generally have to detect wakeup in their
      interrupt handlers.  Thus if they happen to share an interrupt line
      with a NO_SUSPEND user, they also need to request that their
      interrupt handlers be run after suspend_device_irqs().
      
      In both cases the reason for using IRQF_NO_SUSPEND is not because
      the driver in question has a genuine need to run its interrupt
      handler after suspend_device_irqs(), but because it happens to
      share the line with some other NO_SUSPEND user.  Otherwise, the
      driver would do without IRQF_NO_SUSPEND just fine.
      
      To make it possible to specify that condition explicitly, introduce
      a new IRQ action handler flag for shared IRQs, IRQF_COND_SUSPEND,
      that, when set, will indicate to the IRQ core that the interrupt
      user is generally fine with suspending the IRQ, but it also can
      tolerate handler invocations after suspend_device_irqs() and, in
      particular, it is capable of detecting system wakeup and triggering
      it as appropriate from its interrupt handler.
      
      That will allow us to work around a problem with a shared timer
      interrupt line on at91 platforms.
      
      Link: http://marc.info/?l=linux-kernel&m=142252777602084&w=2
      Link: http://marc.info/?t=142252775300011&r=1&w=2
      Link: https://lkml.org/lkml/2014/12/15/552Reported-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      17f48034
  13. 03 9月, 2014 1 次提交
    • M
      genirq: Add irq_domain-aware core IRQ handler · 76ba59f8
      Marc Zyngier 提交于
      Calling irq_find_mapping from outside a irq_{enter,exit} section is
      unsafe and produces ugly messages if CONFIG_PROVE_RCU is enabled:
      If coming from the idle state, the rcu_read_lock call in irq_find_mapping
      will generate an unpleasant warning:
      
      <quote>
      ===============================
      [ INFO: suspicious RCU usage. ]
      3.16.0-rc1+ #135 Not tainted
      -------------------------------
      include/linux/rcupdate.h:871 rcu_read_lock() used illegally while idle!
      
      other info that might help us debug this:
      
      RCU used illegally from idle CPU!
      rcu_scheduler_active = 1, debug_locks = 0
      RCU used illegally from extended quiescent state!
      1 lock held by swapper/0/0:
       #0:  (rcu_read_lock){......}, at: [<ffffffc00010206c>]
      irq_find_mapping+0x4c/0x198
      </quote>
      
      As this issue is fairly widespread and involves at least three
      different architectures, a possible solution is to add a new
      handle_domain_irq entry point into the generic IRQ code that
      the interrupt controller code can call.
      
      This new function takes an irq_domain, and calls into irq_find_domain
      inside the irq_{enter,exit} block. An additional "lookup" parameter is
      used to allow non-domain architecture code to be replaced by this as well.
      
      Interrupt controllers can then be updated to use the new mechanism.
      
      This code is sitting behind a new CONFIG_HANDLE_DOMAIN_IRQ, as not all
      architectures implement set_irq_regs (yes, mn10300, I'm looking at you...).
      Reported-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Link: https://lkml.kernel.org/r/1409047421-27649-2-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>
      76ba59f8
  14. 01 9月, 2014 1 次提交
  15. 04 5月, 2014 1 次提交
    • T
      genirq: Sanitize spurious interrupt detection of threaded irqs · 1e77d0a1
      Thomas Gleixner 提交于
      Till reported that the spurious interrupt detection of threaded
      interrupts is broken in two ways:
      
      - note_interrupt() is called for each action thread of a shared
        interrupt line. That's wrong as we are only interested whether none
        of the device drivers felt responsible for the interrupt, but by
        calling multiple times for a single interrupt line we account
        IRQ_NONE even if one of the drivers felt responsible.
      
      - note_interrupt() when called from the thread handler is not
        serialized. That leaves the members of irq_desc which are used for
        the spurious detection unprotected.
      
      To solve this we need to defer the spurious detection of a threaded
      interrupt to the next hardware interrupt context where we have
      implicit serialization.
      
      If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
      check whether the previous interrupt requested a deferred check. If
      not, we request a deferred check for the next hardware interrupt and
      return. 
      
      If set, we check whether one of the interrupt threads signaled
      success. Depending on this information we feed the result into the
      spurious detector.
      
      If one primary handler of a shared interrupt returns IRQ_HANDLED we
      disable the deferred check of irq threads on the same line, as we have
      found at least one device driver who cared.
      Reported-by: NTill Straumann <strauman@slac.stanford.edu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAustin Schuh <austin@peloton-tech.com>
      Cc: Oliver Hartkopp <socketcan@hartkopp.net>
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz>
      Cc: Marc Kleine-Budde <mkl@pengutronix.de>
      Cc: linux-can@vger.kernel.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos
      1e77d0a1
  16. 20 12月, 2013 1 次提交
  17. 13 9月, 2013 1 次提交
  18. 01 11月, 2012 1 次提交
    • T
      genirq: Provide means to retrigger parent · 293a7a0a
      Thomas Gleixner 提交于
      Attempts to retrigger nested threaded IRQs currently fail because they
      have no primary handler. In order to support retrigger of nested
      IRQs, the parent IRQ needs to be retriggered.
      
      To fix, when an IRQ needs to be resent, if the interrupt has a parent
      IRQ and runs in the context of the parent IRQ, then resend the parent.
      
      Also, handle_nested_irq() needs to clear the replay flag like the
      other handlers, otherwise check_irq_resend() will set it and it will
      never be cleared.  Without clearing, it results in the first resend
      working fine, but check_irq_resend() returning early on subsequent
      resends because the replay flag is still set.
      
      Problem discovered on ARM/OMAP platforms where a nested IRQ that's
      also a wakeup IRQ happens late in suspend and needed to be retriggered
      during the resume process.
      
      [khilman@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]
      Reported-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1350425269-11489-1-git-send-email-khilman@deeprootsystems.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      293a7a0a
  19. 15 8月, 2012 1 次提交
  20. 19 7月, 2012 1 次提交
  21. 01 11月, 2011 1 次提交
    • P
      irq: don't put module.h into irq.h for tracking irqgen modules. · ec53cf23
      Paul Gortmaker 提交于
      Recent commit "irq: Track the  owner of irq descriptor" in
      commit ID b6873807 placed module.h into linux/irq.h
      but we are trying to limit module.h inclusion to just C files
      that really need it, due to its size and number of children
      includes.  This targets just reversing that include.
      
      Add in the basic "struct module" since that is all we really need
      to ensure things compile.  In theory, b6873807 should have added the
      module.h include to the irqdesc.h header as well, but the implicit
      module.h everywhere presence masked this from showing up.  So give
      it the "struct module" as well.
      
      As for the C files, irqdesc.c is only using THIS_MODULE, so it
      does not need module.h - give it export.h instead.  The C file
      irq/manage.c is now (as of b6873807) using try_module_get and
      module_put and so it needs module.h (which it already has).
      
      Also convert the irq_alloc_descs variants to macros, since all
      they really do is is call the __irq_alloc_descs primitive.
      This avoids including export.h and no debug info is lost.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      ec53cf23
  22. 03 10月, 2011 1 次提交
    • M
      genirq: Add support for per-cpu dev_id interrupts · 31d9d9b6
      Marc Zyngier 提交于
      The ARM GIC interrupt controller offers per CPU interrupts (PPIs),
      which are usually used to connect local timers to each core. Each CPU
      has its own private interface to the GIC, and only sees the PPIs that
      are directly connect to it.
      
      While these timers are separate devices and have a separate interrupt
      line to a core, they all use the same IRQ number.
      
      For these devices, request_irq() is not the right API as it assumes
      that an IRQ number is visible by a number of CPUs (through the
      affinity setting), but makes it very awkward to express that an IRQ
      number can be handled by all CPUs, and yet be a different interrupt
      line on each CPU, requiring a different dev_id cookie to be passed
      back to the handler.
      
      The *_percpu_irq() functions is designed to overcome these
      limitations, by providing a per-cpu dev_id vector:
      
      int request_percpu_irq(unsigned int irq, irq_handler_t handler,
      		   const char *devname, void __percpu *percpu_dev_id);
      void free_percpu_irq(unsigned int, void __percpu *);
      int setup_percpu_irq(unsigned int irq, struct irqaction *new);
      void remove_percpu_irq(unsigned int irq, struct irqaction *act);
      void enable_percpu_irq(unsigned int irq);
      void disable_percpu_irq(unsigned int irq);
      
      The API has a number of limitations:
      - no interrupt sharing
      - no threading
      - common handler across all the CPUs
      
      Once the interrupt is requested using setup_percpu_irq() or
      request_percpu_irq(), it must be enabled by each core that wishes its
      local interrupt to be delivered.
      
      Based on an initial patch by Thomas Gleixner.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1316793788-14500-2-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      31d9d9b6
  23. 28 7月, 2011 1 次提交
  24. 18 5月, 2011 1 次提交
    • T
      genirq: Uninline and sanity check generic_handle_irq() · fe12bc2c
      Thomas Gleixner 提交于
      generic_handle_irq() is missing a NULL pointer check for the result of
      irq_to_desc. This was a not a big problem, but we want to expose it to
      drivers, so we better have sanity checks in place. Add a return value
      as well, which indicates that the irq number was valid and the handler
      was invoked.
      
      Based on the pure code move from Jonathan Cameron.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      fe12bc2c
  25. 23 4月, 2011 2 次提交
  26. 29 3月, 2011 1 次提交
  27. 24 3月, 2011 3 次提交
  28. 11 3月, 2011 1 次提交
  29. 26 2月, 2011 1 次提交
    • T
      genirq: Prepare the handling of shared oneshot interrupts · b5faba21
      Thomas Gleixner 提交于
      For level type interrupts we need to track how many threads are on
      flight to avoid useless interrupt storms when not all thread handlers
      have finished yet. Keep track of the woken threads and only unmask
      when there are no more threads in flight.
      
      Yes, I'm lazy and using a bitfield. But not only because I'm lazy, the
      main reason is that it's way simpler than using a refcount. A refcount
      based solution would need to keep track of various things like
      crashing the irq thread, spurious interrupts coming in,
      disables/enables, free_irq() and some more. The bitfield keeps the
      tracking simple and makes things just work. It's also nicely confined
      to the thread code pathes and does not require additional checks all
      over the place.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.388095876@linutronix.de>
      b5faba21
  30. 19 2月, 2011 1 次提交