1. 06 6月, 2018 1 次提交
    • T
      genirq/affinity: Defer affinity setting if irq chip is busy · 12f47073
      Thomas Gleixner 提交于
      The case that interrupt affinity setting fails with -EBUSY can be handled
      in the kernel completely by using the already available generic pending
      infrastructure.
      
      If a irq_chip::set_affinity() fails with -EBUSY, handle it like the
      interrupts for which irq_chip::set_affinity() can only be invoked from
      interrupt context. Copy the new affinity mask to irq_desc::pending_mask and
      set the affinity pending bit. The next raised interrupt for the affected
      irq will check the pending bit and try to set the new affinity from the
      handler. This avoids that -EBUSY is returned when an affinity change is
      requested from user space and the previous change has not been cleaned
      up. The new affinity will take effect when the next interrupt is raised
      from the device.
      
      Fixes: dccfe314 ("x86/vector: Simplify vector move cleanup")
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NSong Liu <songliubraving@fb.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <liu.song.a23@gmail.com>
      Cc: Dmitry Safonov <0x7f454c46@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: Mike Travis <mike.travis@hpe.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Link: https://lkml.kernel.org/r/20180604162224.819273597@linutronix.de
      12f47073
  2. 20 3月, 2018 3 次提交
  3. 16 2月, 2018 1 次提交
  4. 13 11月, 2017 1 次提交
    • R
      genirq: Fix type of shifting literal 1 in __setup_irq() · ffc661c9
      Rasmus Villemoes 提交于
      If ffz() ever returns a value >= 31 then the following shift is undefined
      behaviour because the literal 1 which gets shifted is treated as signed
      integer.
      
      In practice, the bug is probably harmless, since the first undefined shift
      count is 31 which results - ignoring UB - in (int)(0x80000000). This gets
      sign extended so bit 32-63 will be set as well and all subsequent
      __setup_irq() calls would just end up hitting the -EBUSY branch.
      
      However, a sufficiently aggressive optimizer may use the UB of 1<<31
      to decide that doesn't happen, and hence elide the sign-extension
      code, so that subsequent calls can indeed get ffz > 31.
      
      In any case, the right thing to do is to make the literal 1UL.
      
      [ tglx: For this to happen a single interrupt would have to be shared by 32
        	devices. Hardware like that does not exist and would have way more
        	problems than that. ]
      Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20171030213548.16831-1-linux@rasmusvillemoes.dk
      ffc661c9
  5. 10 11月, 2017 1 次提交
    • M
      genirq: Track whether the trigger type has been set · 4f8413a3
      Marc Zyngier 提交于
      When requesting a shared interrupt, we assume that the firmware
      support code (DT or ACPI) has called irqd_set_trigger_type
      already, so that we can retrieve it and check that the requester
      is being reasonnable.
      
      Unfortunately, we still have non-DT, non-ACPI systems around,
      and these guys won't call irqd_set_trigger_type before requesting
      the interrupt. The consequence is that we fail the request that
      would have worked before.
      
      We can either chase all these use cases (boring), or address it
      in core code (easier). Let's have a per-irq_desc flag that
      indicates whether irqd_set_trigger_type has been called, and
      let's just check it when checking for a shared interrupt.
      If it hasn't been set, just take whatever the interrupt
      requester asks.
      
      Fixes: 382bd4de ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs")
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NPetr Cvek <petrcvekcz@gmail.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      4f8413a3
  6. 29 10月, 2017 1 次提交
    • C
      genirq: Document vcpu_info usage for percpu_devid interrupts · 250a53d6
      Christoffer Dall 提交于
      It is currently unclear how to set the VCPU affinity for a percpu_devid
      interrupt , since the Linux irq_data structure describes the state for
      multiple interrupts, one for each physical CPU on the system.  Since
      each such interrupt can be associated with different VCPUs or none at
      all, associating a single VCPU state with such an interrupt does not
      capture the necessary semantics.
      
      The implementers of irq_set_affinity are the Intel and AMD IOMMUs, and
      the ARM GIC irqchip.  The Intel and AMD callers do not appear to use
      percpu_devid interrupts, and the ARM GIC implementation only checks the
      pointer against NULL vs. non-NULL.
      
      Therefore, simply update the function documentation to explain the
      expected use in the context of percpu_devid interrupts, allowing future
      changes or additions to irqchip implementers to do the right thing.
      Signed-off-by: NChristoffer Dall <cdall@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: kvm@vger.kernel.org
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Eric Auger <eric.auger@redhat.com>
      Cc: kvmarm@lists.cs.columbia.edu
      Cc: linux-arm-kernel@lists.infradead.org
      Link: https://lkml.kernel.org/r/1509093281-15225-13-git-send-email-cdall@linaro.org
      250a53d6
  7. 09 10月, 2017 2 次提交
    • T
      genirq/cpuhotplug: Enforce affinity setting on startup of managed irqs · e43b3b58
      Thomas Gleixner 提交于
      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: NYASUAKI ISHIMATSU <yasu.isimatu@gmail.com>
      Signed-off-by: NThomas 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
    • T
      genirq: Warn when effective affinity is not updated · 19e1d4e9
      Thomas Gleixner 提交于
      Emit a one time warning when the effective affinity mask is enabled in
      Kconfig, but the interrupt chip does not update the mask in its
      irq_set_affinity() callback,
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1710042208400.2406@nanos                                                                                                                                                                                                        
      19e1d4e9
  8. 26 9月, 2017 2 次提交
    • T
      genirq: Separate activation and startup · c942cee4
      Thomas Gleixner 提交于
      Activation of an interrupt and startup are currently a combo
      functionlity. That works so far, but upcoming changes require a strict
      separation because the activation can fail in future.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@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: 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: https://lkml.kernel.org/r/20170913213152.754334077@linutronix.de
      c942cee4
    • T
      genirq/debugfs: Show debug information for all irq descriptors · e0b47794
      Thomas Gleixner 提交于
      Currently the debugfs shows only information about actively used interrupts
      like /proc/irq/ does. That's fine for most cases, but not helpful when
      internals of allocated, but unused interrupt descriptors have to
      debugged. It's also useful to provide information about all descriptors so
      leaks can be debugged in a simpler way.
      
      Move the debugfs registration to the descriptor allocation code.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@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: 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: https://lkml.kernel.org/r/20170913213152.355525908@linutronix.de
      e0b47794
  9. 25 9月, 2017 1 次提交
  10. 23 8月, 2017 1 次提交
  11. 12 7月, 2017 1 次提交
    • T
      genirq: Keep chip buslock across irq_request/release_resources() · 19d39a38
      Thomas Gleixner 提交于
      Moving the irq_request/release_resources() callbacks out of the spinlocked,
      irq disabled and bus locked region, unearthed an interesting abuse of the
      irq_bus_lock/irq_bus_sync_unlock() callbacks.
      
      The OMAP GPIO driver does merily power management inside of them. The
      irq_request_resources() callback of this GPIO irqchip calls a function
      which reads a GPIO register. That read aborts now because the clock of the
      GPIO block is not magically enabled via the irq_bus_lock() callback.
      
      Move the callbacks under the bus lock again to prevent this. In the
      free_irq() path this requires to drop the bus_lock before calling
      synchronize_irq() and reaquiring it before calling the
      irq_release_resources() callback.
      
      The bus lock can't be held because:
      
         1) The data which has been changed between bus_lock/un_lock is cached in
            the irq chip driver private data and needs to go out to the irq chip
            via the slow bus (usually SPI or I2C) before calling
            synchronize_irq().
      
            That's the reason why this bus_lock/unlock magic exists in the first
            place, as you cannot do SPI/I2C transactions while holding desc->lock
            with interrupts disabled.
      
         2) synchronize_irq() will actually deadlock, if there is a handler on
            flight. These chips use threaded handlers for obvious reasons, as
            they allow to do SPI/I2C communication. When the threaded handler
            returns then bus_lock needs to be taken in irq_finalize_oneshot() as
            we need to talk to the actual irq chip once more. After that the
            threaded handler is marked done, which makes synchronize_irq() return.
      
            So if we hold bus_lock accross the synchronize_irq() call, the
            handler cannot mark itself done because it blocks on the bus
            lock. That in turn makes synchronize_irq() wait forever on the
            threaded handler to complete....
      
      Add the missing unlock of desc->request_mutex in the error path of
      __free_irq() and add a bunch of comments to explain the locking and
      protection rules.
      
      Fixes: 46e48e25 ("genirq: Move irq resource handling out of spinlocked region")
      Reported-and-tested-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
      Reported-and-tested-by: NTony Lindgren <tony@atomide.com>
      Reported-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Not-longer-ranted-at-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      19d39a38
  12. 07 7月, 2017 1 次提交
    • D
      genirq: Allow to pass the IRQF_TIMER flag with percpu irq request · c80081b9
      Daniel Lezcano 提交于
      The irq timings infrastructure tracks when interrupts occur in order to
      statistically predict te next interrupt event.
      
      There is no point to track timer interrupts and try to predict them because
      the next expiration time is already known. This can be avoided via the
      IRQF_TIMER flag which is passed by timer drivers in request_irq(). It marks
      the interrupt as timer based which alloes to ignore these interrupts in the
      timings code.
      
      Per CPU interrupts which are requested via request_percpu_+irq() have no
      flag argument, so marking per cpu timer interrupts is not possible and they
      get tracked pointlessly.
      
      Add __request_percpu_irq() as a variant of request_percpu_irq() with a
      flags argument and make request_percpu_irq() an inline wrapper passing
      flags = 0.
      
      The flag parameter is restricted to IRQF_TIMER as all other IRQF_ flags
      make no sense for per cpu interrupts.
      
      The next step is to convert all existing users of request_percpu_irq() and
      then remove the wrapper and the underscores.
      
      [ tglx: Massaged changelog ]
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Cc: nicolas.pitre@linaro.org
      Cc: vincent.guittot@linaro.org
      Cc: rafael@kernel.org
      Link: http://lkml.kernel.org/r/1499344144-3964-1-git-send-email-daniel.lezcano@linaro.org
      c80081b9
  13. 04 7月, 2017 4 次提交
  14. 24 6月, 2017 1 次提交
    • D
      genirq/timings: Add infrastructure to track the interrupt timings · b2d3d61a
      Daniel Lezcano 提交于
      The interrupt framework gives a lot of information about each interrupt. It
      does not keep track of when those interrupts occur though, which is a
      prerequisite for estimating the next interrupt arrival for power management
      purposes.
      
      Add a mechanism to record the timestamp for each interrupt occurrences in a
      per-CPU circular buffer to help with the prediction of the next occurrence
      using a statistical model.
      
      Each CPU can store up to IRQ_TIMINGS_SIZE events <irq, timestamp>, the
      current value of IRQ_TIMINGS_SIZE is 32.
      
      Each event is encoded into a single u64, where the high 48 bits are used
      for the timestamp and the low 16 bits are for the irq number.
      
      A static key is introduced so when the irq prediction is switched off at
      runtime, the overhead is near to zero.
      
      It results in most of the code in internals.h for inline reasons and a very
      few in the new file timings.c. The latter will contain more in the next patch
      which will provide the statistical model for the next event prediction.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Hannes Reinecke <hare@suse.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: "Rafael J . Wysocki" <rafael@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Link: http://lkml.kernel.org/r/1498227072-5980-1-git-send-email-daniel.lezcano@linaro.org
      b2d3d61a
  15. 23 6月, 2017 6 次提交
    • T
      genirq: Add force argument to irq_startup() · 4cde9c6b
      Thomas Gleixner 提交于
      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: NThomas 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
    • C
      genirq: Move pending helpers to internal.h · 137221df
      Christoph Hellwig 提交于
      So that the affinity code can reuse them.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NThomas 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>
      Link: http://lkml.kernel.org/r/20170619235445.109426284@linutronix.de
      137221df
    • T
      genirq: Move initial affinity setup to irq_startup() · 2e051552
      Thomas Gleixner 提交于
      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: NThomas 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
    • T
      genirq: Rename setup_affinity() to irq_setup_affinity() · 43564bd9
      Thomas Gleixner 提交于
      Rename it with a proper irq_ prefix and make it available for other files
      in the core code. Preparatory patch for moving the irq affinity setup
      around.
      Signed-off-by: NThomas 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/20170619235444.928501004@linutronix.de
      43564bd9
    • T
      genirq: Remove mask argument from setup_affinity() · cba4235e
      Thomas Gleixner 提交于
      No point to have this alloc/free dance of cpumasks. Provide a static mask
      for setup_affinity() and protect it proper.
      Signed-off-by: NThomas 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/20170619235444.851571573@linutronix.de
      cba4235e
    • T
      genirq/debugfs: Add proper debugfs interface · 087cdfb6
      Thomas Gleixner 提交于
      Debugging (hierarchical) interupt domains is tedious as there is no
      information about the hierarchy and no information about states of
      interrupts in the various domain levels.
      
      Add a debugfs directory 'irq' and subdirectories 'domains' and 'irqs'.
      
      The domains directory contains the domain files. The content is information
      about the domain. If the domain is part of a hierarchy then the parent
      domains are printed as well.
      
      # ls /sys/kernel/debug/irq/domains/
      default     INTEL-IR-2	    INTEL-IR-MSI-2  IO-APIC-IR-2  PCI-MSI
      DMAR-MSI    INTEL-IR-3	    INTEL-IR-MSI-3  IO-APIC-IR-3  unknown-1
      INTEL-IR-0  INTEL-IR-MSI-0  IO-APIC-IR-0    IO-APIC-IR-4  VECTOR
      INTEL-IR-1  INTEL-IR-MSI-1  IO-APIC-IR-1    PCI-HT
      
      # cat /sys/kernel/debug/irq/domains/VECTOR 
      name:   VECTOR
       size:   0
       mapped: 216
       flags:  0x00000041
      
      # cat /sys/kernel/debug/irq/domains/IO-APIC-IR-0 
      name:   IO-APIC-IR-0
       size:   24
       mapped: 19
       flags:  0x00000041
       parent: INTEL-IR-3
          name:   INTEL-IR-3
           size:   65536
           mapped: 167
           flags:  0x00000041
           parent: VECTOR
              name:   VECTOR
               size:   0
               mapped: 216
               flags:  0x00000041
      
      Unfortunately there is no per cpu information about the VECTOR domain (yet).
      
      The irqs directory contains detailed information about mapped interrupts.
      
      # cat /sys/kernel/debug/irq/irqs/3
      handler:  handle_edge_irq
      status:   0x00004000
      istate:   0x00000000
      ddepth:   1
      wdepth:   0
      dstate:   0x01018000
                  IRQD_IRQ_DISABLED
                  IRQD_SINGLE_TARGET
                  IRQD_MOVE_PCNTXT
      node:     0
      affinity: 0-143
      effectiv: 0
      pending:  
      domain:  IO-APIC-IR-0
       hwirq:   0x3
       chip:    IR-IO-APIC
        flags:   0x10
                   IRQCHIP_SKIP_SET_WAKE
       parent:
          domain:  INTEL-IR-3
           hwirq:   0x20000
           chip:    INTEL-IR
            flags:   0x0
           parent:
              domain:  VECTOR
               hwirq:   0x3
               chip:    APIC
                flags:   0x0
      
      This was developed to simplify the debugging of the managed affinity
      changes.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      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/20170619235444.537566163@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      087cdfb6
  16. 13 6月, 2017 1 次提交
  17. 04 6月, 2017 2 次提交
  18. 19 4月, 2017 2 次提交
  19. 15 4月, 2017 2 次提交
  20. 02 3月, 2017 2 次提交
  21. 28 2月, 2017 1 次提交
  22. 08 11月, 2016 1 次提交
    • T
      genirq: Use irq type from irqdata instead of irqdesc · 7ee7e87d
      Thomas Gleixner 提交于
      The type flags in the irq descriptor are there for historical reasons and
      only updated via irq_modify_status() or irq_set_type(). Both functions also
      update the type flags in irqdata. __setup_irq() is the only left over user
      of the type flags in the irq descriptor.
      
      If __setup_irq() is called with empty irq type flags, then the type flags
      are retrieved from irqdata. If an interrupt is shared, then the type flags
      are compared with the type flags stored in the irq descriptor. 
      
      On x86 the ioapic does not have a irq_set_type() callback because the type
      is defined in the BIOS tables and cannot be changed. The type is stored in
      irqdata at setup time without updating the type data in the irq
      descriptor. As a result the comparison described above fails.
      
      There is no point in updating the irq descriptor flags because the only
      relevant storage is irqdata. Use the type flags from irqdata for both
      retrieval and comparison in __setup_irq() instead.
      
      Aside of that the print out in case of non matching type flags has the old
      and new type flags arguments flipped. Fix that as well.
      
      For correctness sake the flags stored in the irq descriptor should be
      removed, but this is beyond the scope of this bugfix and will be done in a
      later patch.
      
      Fixes: 4b357dae ("genirq: Look-up trigger type if not specified by caller")
      Reported-and-tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1611072020360.3501@nanosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      7ee7e87d
  23. 21 10月, 2016 1 次提交
  24. 06 9月, 2016 1 次提交