1. 01 Feb, 2018 1 commit
    • Thomas Gleixner's avatar
      genirq: Make legacy autoprobing work again · 1beaeacd
      Thomas Gleixner authored
      Meelis reported the following warning on a quad P3 HP NetServer museum piece:
      
      WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100
      EIP: __irq_startup+0x80/0x100
      irq_startup+0x7e/0x170
      probe_irq_on+0x128/0x2b0
      parport_irq_probe.constprop.18+0x8d/0x1af [parport_pc]
      parport_pc_probe_port+0xf11/0x1260 [parport_pc]
      parport_pc_init+0x78a/0xf10 [parport_pc]
      parport_parse_param.constprop.16+0xf0/0xf0 [parport_pc]
      do_one_initcall+0x45/0x1e0
      
      This is caused by the rewrite of the irq activation/startup sequence which
      missed to convert a callsite in the irq legacy auto probing code.
      
      To fix this irq_activate_and_startup() needs to gain a return value so the
      pending logic can work proper.
      
      Fixes: c942cee4
      
       ("genirq: Separate activation and startup")
      Reported-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarMeelis Roos <mroos@linux.ee>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801301935410.1797@nanos
      1beaeacd
  2. 09 Oct, 2017 1 commit
    • Thomas Gleixner's avatar
      genirq/cpuhotplug: Enforce affinity setting on startup of managed irqs · e43b3b58
      Thomas Gleixner authored
      Managed interrupts can end up in a stale state on CPU hotplug. If the
      interrupt is not targeting a single CPU, i.e. the affinity mask spawns
      multiple CPUs then the following can happen:
      
      After boot:
      
      dstate:   0x01601200
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_AFFINITY_MANAGED
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  0
      
      After offlining CPU 31 - 24
      
      dstate:   0x01a31000
                  IRQD_IRQ_DISABLED
                  IRQD_IRQ_MASKED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_AFFINITY_MANAGED
                  IRQD_MANAGED_SHUTDOWN
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  0
      
      Now CPU 25 gets onlined again, so it should get the effective interrupt
      affinity for this interruopt, but due to the x86 interrupt affinity setter
      restrictions this ends up after restarting the interrupt with:
      
      dstate:   0x01601300
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_SETAFFINITY_PENDING
                  IRQD_AFFINITY_MANAGED
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  24-31
      
      So the interrupt is still affine to CPU 24, which was the last CPU to go
      offline of that affinity set and the move to an online CPU within 24-31,
      in this case 25, is pending. This mechanism is x86/ia64 specific as those
      architectures cannot move interrupts from thread context and do this when
      an interrupt is actually handled. So the move is set to pending.
      
      Whats worse is that offlining CPU 25 again results in:
      
      dstate:   0x01601300
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_SET
                  IRQD_SETAFFINITY_PENDING
                  IRQD_AFFINITY_MANAGED
      node:     0
      affinity: 24-31
      effectiv: 24
      pending:  24-31
      
      This means the interrupt has not been shut down, because the outgoing CPU
      is not in the effective affinity mask, but of course nothing notices that
      the effective affinity mask is pointing at an offline CPU.
      
      In the case of restarting a managed interrupt the move restriction does not
      apply, so the affinity setting can be made unconditional. This needs to be
      done _before_ the interrupt is started up as otherwise the condition for
      moving it from thread context would not longer be fulfilled.
      
      With that change applied onlining CPU 25 after offlining 31-24 results in:
      
      dstate:   0x01600200
                  IRQD_ACTIVATED
                  IRQD_IRQ_STARTED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_MANAGED
      node:     0
      affinity: 24-31
      effectiv: 25
      pending:  
      
      And after offlining CPU 25:
      
      dstate:   0x01a30000
                  IRQD_IRQ_DISABLED
                  IRQD_IRQ_MASKED
                  IRQD_SINGLE_TARGET
                  IRQD_AFFINITY_MANAGED
                  IRQD_MANAGED_SHUTDOWN
      node:     0
      affinity: 24-31
      effectiv: 25
      pending:  
      
      which is the correct and expected result.
      
      Fixes: 761ea388
      
       ("genirq: Handle managed irqs gracefully in irq_startup()")
      Reported-by: default avatarYASUAKI ISHIMATSU <yasu.isimatu@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: axboe@kernel.dk
      Cc: linux-scsi@vger.kernel.org
      Cc: Sumit Saxena <sumit.saxena@broadcom.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: mpe@ellerman.id.au
      Cc: Shivasharan Srikanteshwara <shivasharan.srikanteshwara@broadcom.com>
      Cc: Kashyap Desai <kashyap.desai@broadcom.com>
      Cc: keith.busch@intel.com
      Cc: peterz@infradead.org
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos
      e43b3b58
  3. 25 Sep, 2017 3 commits
  4. 16 Sep, 2017 1 commit
    • Thomas Gleixner's avatar
      genirq: Fix cpumask check in __irq_startup_managed() · 9cb067ef
      Thomas Gleixner authored
      The result of cpumask_any_and() is invalid when result greater or equal
      nr_cpu_ids. The current check is checking for greater only. Fix it.
      
      Fixes: 761ea388
      
       ("genirq: Handle managed irqs gracefully in irq_startup()")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Chen Yu <yu.c.chen@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: stable@vger.kernel.org
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/20170913213152.272283444@linutronix.de
      9cb067ef
  5. 18 Aug, 2017 3 commits
  6. 17 Jul, 2017 1 commit
  7. 04 Jul, 2017 1 commit
  8. 26 Jun, 2017 1 commit
  9. 22 Jun, 2017 4 commits
    • Thomas Gleixner's avatar
      genirq: Handle managed irqs gracefully in irq_startup() · 761ea388
      Thomas Gleixner authored
      
      
      Affinity managed interrupts should keep their assigned affinity accross CPU
      hotplug. To avoid magic hackery in device drivers, the core code shall
      manage them transparently and set these interrupts into a managed shutdown
      state when the last CPU of the assigned affinity mask goes offline. The
      interrupt will be restarted when one of the CPUs in the assigned affinity
      mask comes back online.
      
      Add the necessary logic to irq_startup(). If an interrupt is requested and
      started up, the code checks whether it is affinity managed and if so, it
      checks whether a CPU in the interrupts affinity mask is online. If not, it
      puts the interrupt into managed shutdown state. 
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235447.189851170@linutronix.de
      761ea388
    • Thomas Gleixner's avatar
      genirq: Add force argument to irq_startup() · 4cde9c6b
      Thomas Gleixner authored
      
      
      In order to handle managed interrupts gracefully on irq_startup() so they
      won't lose their assigned affinity, it's necessary to allow startups which
      keep the interrupts in managed shutdown state, if none of the assigend CPUs
      is online. This allows drivers to request interrupts w/o the CPUs being
      online, which avoid online/offline churn in drivers.
      
      Add a force argument which can override that decision and let only
      request_irq() and enable_irq() allow the managed shutdown
      handling. enable_irq() is required, because the interrupt might be
      requested with IRQF_NOAUTOEN and enable_irq() invokes irq_startup() which
      would then wreckage the assignment again. All other callers force startup
      and potentially break the assigned affinity.
      
      No functional change as this only adds the function argument.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235447.112094565@linutronix.de
      4cde9c6b
    • Thomas Gleixner's avatar
      genirq: Split out irq_startup() code · 708d174b
      Thomas Gleixner authored
      
      
      Split out the inner workings of irq_startup() so it can be reused to handle
      managed interrupts gracefully.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235447.033235144@linutronix.de
      708d174b
    • Thomas Gleixner's avatar
      genirq: Move initial affinity setup to irq_startup() · 2e051552
      Thomas Gleixner authored
      
      
      The startup vs. setaffinity ordering of interrupts depends on the
      IRQF_NOAUTOEN flag. Chained interrupts are not getting any affinity
      assignment at all.
      
      A regular interrupt is started up and then the affinity is set. A
      IRQF_NOAUTOEN marked interrupt is not started up, but the affinity is set
      nevertheless.
      
      Move the affinity setup to startup_irq() so the ordering is always the same
      and chained interrupts get the proper default affinity assigned as well.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Link: http://lkml.kernel.org/r/20170619235445.020534783@linutronix.de
      2e051552
  10. 04 Jun, 2017 2 commits
    • Thomas Gleixner's avatar
      genirq: Warn when IRQ_NOAUTOEN is used with shared interrupts · 04c848d3
      Thomas Gleixner authored
      
      
      Shared interrupts do not go well with disabling auto enable:
      
      1) The sharing interrupt might request it while it's still disabled and
         then wait for interrupts forever.
      
      2) The interrupt might have been requested by the driver sharing the line
         before IRQ_NOAUTOEN has been set. So the driver which expects that
         disabled state after calling request_irq() will not get what it wants.
         Even worse, when it calls enable_irq() later, it will trigger the
         unbalanced enable_irq() warning.
      
      Reported-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: dianders@chromium.org
      Cc: jeffy <jeffy.chen@rock-chips.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: tfiga@chromium.org
      Link: http://lkml.kernel.org/r/20170531100212.210682135@linutronix.de
      04c848d3
    • Thomas Gleixner's avatar
      genirq: Handle NOAUTOEN interrupt setup proper · 201d7f47
      Thomas Gleixner authored
      
      
      If an interrupt is marked NOAUTOEN then request_irq() installs the action,
      but does not enable the interrupt via startup_irq().  The interrupt is
      enabled via enable_irq() later from the driver. enable_irq() calls
      irq_enable().
      
      That means that for interrupts which have a irq_startup() callback this
      callback is never invoked. Neither is irq_domain_activate_irq() invoked for
      such interrupts.
      
      If an interrupt depends on irq_startup() or irq_domain_activate_irq() then
      the enable via irq_enable() is not enough.
      
      Add a status flag IRQD_IRQ_STARTED_UP and use this to select the proper
      mechanism in enable_irq(). Use the flag also to avoid pointless calls into
      the low level functions.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: dianders@chromium.org
      Cc: jeffy <jeffy.chen@rock-chips.com>
      Cc: Brian Norris <briannorris@chromium.org>
      Cc: tfiga@chromium.org
      Link: http://lkml.kernel.org/r/20170531100212.130986205@linutronix.de
      201d7f47
  11. 16 May, 2017 2 commits
  12. 11 Mar, 2017 1 commit
  13. 25 Sep, 2016 1 commit
  14. 19 Sep, 2016 1 commit
  15. 06 Sep, 2016 1 commit
  16. 02 Sep, 2016 1 commit
  17. 17 Aug, 2016 1 commit
  18. 18 Jun, 2016 1 commit
    • Keith Busch's avatar
      genirq: Add untracked irq handler · edd14cfe
      Keith Busch authored
      
      
      This adds a software irq handler for controllers that multiplex
      interrupts from multiple devices, but don't know which device generated
      the interrupt. For these devices, the irq handler that demuxes must
      check every action for every software irq using the same h/w irq in order
      to find out which device generated the interrupt. This will inevitably
      trigger spurious interrupt detection if we are noting the irq.
      
      The new irq handler does not track the handling for spurious interrupt
      detection. An irq that uses this also won't get stats tracked since it
      didn't generate the interrupt, nor added to randomness since they are
      not random.
      
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: linux-pci@vger.kernel.org
      Cc: Jon Derrick <jonathan.derrick@intel.com>
      Link: http://lkml.kernel.org/r/1466200821-29159-1-git-send-email-keith.busch@intel.com
      
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      edd14cfe
  19. 13 Jun, 2016 1 commit
  20. 10 Mar, 2016 1 commit
  21. 20 Dec, 2015 1 commit
  22. 16 Nov, 2015 1 commit
  23. 11 Oct, 2015 1 commit
    • Thomas Gleixner's avatar
      genirq: Add flag to force mask in disable_irq[_nosync]() · e9849777
      Thomas Gleixner authored
      
      
      If an irq chip does not implement the irq_disable callback, then we
      use a lazy approach for disabling the interrupt. That means that the
      interrupt is marked disabled, but the interrupt line is not
      immediately masked in the interrupt chip. It only becomes masked if
      the interrupt is raised while it's marked disabled. We use this to avoid
      possibly expensive mask/unmask operations for common case operations.
      
      Unfortunately there are devices which do not allow the interrupt to be
      disabled easily at the device level. They are forced to use
      disable_irq_nosync(). This can result in taking each interrupt twice.
      
      Instead of enforcing the non lazy mode on all interrupts of a irq
      chip, provide a settings flag, which can be set by the driver for that
      particular interrupt line.
      
      Reported-and-tested-by: default avatarDuc Dang <dhdang@apm.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1510092348370.6097@nanos
      e9849777
  24. 09 Oct, 2015 1 commit
    • Mika Westerberg's avatar
      genirq: Allow migration of chained interrupts by installing default action · e509bd7d
      Mika Westerberg authored
      
      
      When a CPU is offlined all interrupts that have an action are migrated to
      other still online CPUs. However, if the interrupt has chained handler
      installed this is not done. Chained handlers are used by GPIO drivers which
      support interrupts, for instance.
      
      When the affinity is not corrected properly we end up in situation where
      most interrupts are not arriving to the online CPUs anymore. For example on
      Intel Braswell system which has SD-card card detection signal connected to
      a GPIO the IO-APIC routing entries look like below after CPU1 is offlined:
      
        pin30, enabled , level, low , V(52), IRR(0), S(0), logical , D(03), M(1)
        pin31, enabled , level, low , V(42), IRR(0), S(0), logical , D(03), M(1)
        pin32, enabled , level, low , V(62), IRR(0), S(0), logical , D(03), M(1)
        pin5b, enabled , level, low , V(72), IRR(0), S(0), logical , D(03), M(1)
      
      The problem here is that the destination mask still contains both CPUs even
      if CPU1 is already offline. This means that the IO-APIC still routes
      interrupts to the other CPU as well.
      
      We solve the problem by providing a default action for chained interrupts.
      This action allows the migration code to correct affinity (as it finds
      desc->action != NULL).
      
      Also make the default action handler to emit a warning if for some reason a
      chained handler ends up calling it.
      
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Link: http://lkml.kernel.org/r/1444039935-30475-1-git-send-email-mika.westerberg@linux.intel.com
      
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      e509bd7d
  25. 22 Sep, 2015 1 commit
  26. 16 Sep, 2015 3 commits
  27. 19 Aug, 2015 2 commits
  28. 29 Jul, 2015 1 commit