1. 20 Aug, 2019 2 commits
    • Marc Zyngier's avatar
      irqchip/gic: Prepare for more than 16 PPIs · 1a60e1e6
      Marc Zyngier authored
      GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs),
      meaning we can't just leave the old 16 hardcoded everywhere.
      We also need to add the infrastructure to discover the number of PPIs
      on a per redistributor basis, although we still pretend there is only
      16 of them for now.
      No functional change.
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
    • Marc Zyngier's avatar
      irqchip/gic: Rework gic_configure_irq to take the full ICFGR base · 13d22e2e
      Marc Zyngier authored
      gic_configure_irq is currently passed the (re)distributor address,
      to which it applies an a fixed offset to get to the configuration
      registers. This offset is constant across all GICs, or rather it was
      until to v3.1...
      An easy way out is for the individual drivers to pass the base
      address of the configuration register for the considered interrupt.
      At the same time, move part of the error handling back to the
      individual drivers, as things are about to change on that front.
      Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
  2. 07 Aug, 2019 1 commit
  3. 19 Jun, 2019 1 commit
  4. 04 Apr, 2019 1 commit
  5. 11 Mar, 2019 1 commit
  6. 18 Dec, 2018 1 commit
    • Ingo Molnar's avatar
      genirq: Fix various typos in comments · c5f48c0a
      Ingo Molnar authored
      Go over the IRQ subsystem source code (including irqchip drivers) and
      fix common typos in comments.
      No change in functionality intended.
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: linux-kernel@vger.kernel.org
  7. 28 Mar, 2018 1 commit
    • Davidlohr Bueso's avatar
      irqchip/gic: Update supports_deactivate static key to modern api · d01d3274
      Davidlohr Bueso authored
      No changes in semantics -- key init is true; replace
      static_key_slow_dec       with   static_branch_disable
      static_key_true           with   static_branch_likely
      The first is because we never actually do any couterpart incs,
      thus there is really no reference counting semantics going on.
      Use the more proper static_branch_disable() construct.
      Also added a '_key' suffix to supports_deactivate, for better
      self documentation.
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  8. 16 Mar, 2018 1 commit
  9. 14 Mar, 2018 1 commit
    • Marc Zyngier's avatar
      irqchip/gic-v2: Reset APRn registers at boot time · c5e1035c
      Marc Zyngier authored
      Booting a crash kernel while in an interrupt handler is likely
      to leave the Active Priority Registers with some state that
      is not relevant to the new kernel, and is likely to lead
      to erratic behaviours such as interrupts not firing as their
      priority is already active.
      As a sanity measure, wipe the APRs clean on startup.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  10. 06 Nov, 2017 1 commit
  11. 02 Nov, 2017 1 commit
    • Marc Zyngier's avatar
      irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface · 0962289b
      Marc Zyngier authored
      There is a lot of broken firmware out there that don't really
      expose the information the kernel requires when it comes with dealing
      with GICv2:
      (1) Firmware that only describes the first 4kB of GICv2
      (2) Firmware that describe 128kB of CPU interface, while
          the usable portion of the address space is between
          60 and 68kB
      So far, we only deal with (2). But we have platforms exhibiting
      behaviour (1), resulting in two sub-cases:
      (a) The GIC is occupying 8kB, as required by the GICv2 architecture
      (b) It is actually spread 128kB, and this is likely to be a version
          of (2)
      This patch tries to work around both (a) and (b) by poking at
      the outside of the described memory region, and try to work out
      what is actually there. This is of course unsafe, and should
      only be enabled if there is no way to otherwise fix the DT provided
      by the firmware (we provide a "irqchip.gicv2_force_probe" option
      to that effect).
      Note that for the time being, we restrict ourselves to GICv2
      implementations provided by ARM, since there I have no knowledge
      of an alternative implementations. This could be relaxed if such
      an implementation comes to light on a broken platform.
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  12. 31 Aug, 2017 1 commit
  13. 18 Aug, 2017 1 commit
  14. 02 Aug, 2017 1 commit
    • Will Deacon's avatar
      irqchip/gic: Ensure we have an ISB between ack and ->handle_irq · 39a06b67
      Will Deacon authored
      Devices that expose their interrupt status registers via system
      registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
      vgic (although unused by Linux), ...) rely on a context synchronising
      operation on the CPU to ensure that the updated status register is
      visible to the CPU when handling the interrupt. This usually happens as
      a result of taking the IRQ exception in the first place, but there are
      two race scenarios where this isn't the case.
      For example, let's say we have two peripherals (X and Y), where Y uses a
      system register for its interrupt status.
      Case 1:
      1. CPU takes an IRQ exception as a result of X raising an interrupt
      2. Y then raises its interrupt line, but the update to its system
         register is not yet visible to the CPU
      3. The GIC decides to expose Y's interrupt number first in the Ack
      4. The CPU runs the IRQ handler for Y, but the status register is stale
      Case 2:
      1. CPU takes an IRQ exception as a result of X raising an interrupt
      2. CPU reads the interrupt number for X from the Ack register and runs
         its IRQ handler
      3. Y raises its interrupt line and the Ack register is updated, but
         again, the update to its system register is not yet visible to the
      4. Since the GIC drivers poll the Ack register, we read Y's interrupt
         number and run its handler without a context synchronisation
         operation, therefore seeing the stale register value.
      In either case, we run the risk of missing an IRQ. This patch solves the
      problem by ensuring that we execute an ISB in the GIC drivers prior
      to invoking the interrupt handler. This is already the case for GICv3
      and EOIMode 1 (the usual case for the host).
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  15. 04 Jul, 2017 1 commit
  16. 25 Dec, 2016 1 commit
  17. 20 Oct, 2016 1 commit
  18. 12 Sep, 2016 2 commits
    • Baoyou Xie's avatar
      irqchip/gic: Mark gic_init_physaddr() static · 89c59cca
      Baoyou Xie authored
      We get 1 warning when building kernel with W=1:
      drivers/irqchip/irq-gic.c:917:13: warning: no previous prototype for 'gic_init_physaddr' [-Wmissing-prototypes]
      In fact, this function is only used in the file in which it is
      declared and don't need a declaration, but can be made static.
      so this patch marks this function with 'static'.
      Signed-off-by: default avatarBaoyou Xie <baoyou.xie@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Marc Zyngier's avatar
      irqchip/gic: Make locking a BL_SWITCHER only feature · 04c8b0f8
      Marc Zyngier authored
      The BL switcher code manipulates the logical/physical CPU mapping,
      forcing a lock to be taken on the IPI path. With an IPI heavy load,
      this single lock becomes contended.
      But when CONFIG_BL_SWITCHER is not enabled, there is no reason
      to take this lock at all since the CPU mapping is immutable.
      This patch allows the lock to be entierely removed when BL_SWITCHER
      is not enabled (which is the case in most configurations), leading
      to a small improvement of "perf bench sched pipe" (measured on
      an 8 core AMD Seattle system):
      Before: 101370 ops/sec
      After:  103680 ops/sec
      Take this opportunity to remove a useless lock being taken when
      handling an interrupt on a secondary GIC.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  19. 17 Aug, 2016 1 commit
  20. 14 Jul, 2016 1 commit
  21. 13 Jun, 2016 4 commits
    • Jon Hunter's avatar
      irqchip/gic: Add platform driver for non-root GICs that require RPM · 9c8edddf
      Jon Hunter authored
      Add a platform driver to support non-root GICs that require runtime
      power-management. Currently, only non-root GICs are supported because
      the functions, smp_cross_call() and set_handle_irq(), that need to
      be called for a root controller are located in the __init section and
      so cannot be called by the platform driver.
      The GIC platform driver re-uses many functions from the existing GIC
      driver including some functions to save and restore the GIC context
      during power transitions. The functions for saving and restoring the
      GIC context are currently only defined if CONFIG_CPU_PM is enabled and
      to ensure that these functions are always defined when the platform
      driver is enabled, a dependency on CONFIG_ARM_GIC_PM (which selects the
      platform driver) has been added.
      In order to re-use the private GIC initialisation code, a new public
      function, gic_of_init_child(), has been added which calls various
      private functions to initialise the GIC. This is different from the
      existing gic_of_init() because it only supports non-root GICs (ie. does
      not call smp_cross_call() is set_handle_irq()) and is not located in
      the __init section (so can be used by platform drivers). Furthermore,
      gic_of_init_child() dynamically allocates memory for the GIC chip data
      which is also different from gic_of_init().
      There is no specific suspend handling for GICs registered as platform
      devices. Non-wakeup interrupts will be disabled by the kernel during
      late suspend, however, this alone will not power down the GIC if
      interrupts have been requested and not freed. Therefore, requestors of
      non-wakeup interrupts will need to free them on entering suspend in
      order to power-down the GIC.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Prepare for adding platform driver · cdbb813d
      Jon Hunter authored
      To support GICs that require runtime power management, it is necessary
      to add a platform driver, so that the probing of the chip can be
      deferred if resources, such as a power-domain, is not yet available.
      To prepare for adding a platform driver:
       1. Drop the __init section from the gic_dist_config() so this can be
          re-used by the platform driver.
       2. Add prototypes for functions required by the platform driver to the
          GIC header file so they can be re-used.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Add helper function for chip initialisation · faea6455
      Jon Hunter authored
      For GICs that require runtime power-management it is necessary to
      populate the 'parent_device' member of the irqchip structure. In
      preparation for supporting such GICs, move the code that initialises
      the irqchip structure for a GIC into its own function called
      gic_init_chip() where the parent device pointer is also set.
      Instead of calling gic_init_chip() from within gic_init_bases(), move
      the calls to outside of this function, so that in the future we can
      avoid having to pass additional parameters to gic_init_bases() in order
      set the parent device pointer or set the name to a specific string.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Isolate early GIC initialisation code · d6ce564c
      Jon Hunter authored
      To re-use the code that initialises the GIC (found in
      __gic_init_bases()), from within a platform driver, it is necessary to
      move the code from the __init section so that it is always present and
      not removed. Unfortunately, it is not possible to simply drop the __init
      from the function declaration for __gic_init_bases() because it contains
      calls to set_smp_cross_call() and set_handle_irq() which are both
      located in the __init section. Fortunately, these calls are only
      required for the root controller and because the initial platform driver
      will only support non-root controllers that can be initialised later in
      the boot process, we can move these calls to another function.
      Move the bulk of the code from __gic_init_bases() to a new function
      called gic_init_bases() which is not located in the __init section and
      can be used by the platform driver. Update __gic_init_bases() to call
      gic_init_bases() and if necessary, set_smp_cross_call() and
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  22. 27 May, 2016 1 commit
    • Arnd Bergmann's avatar
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann authored
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      I was using this definition for testing:
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  23. 11 May, 2016 7 commits
    • Jon Hunter's avatar
      irqchip/gic: Add helper functions for GIC setup and teardown · d6490461
      Jon Hunter authored
      Move the code that sets-up a GIC via device-tree into it's own
      function and add a generic function for GIC teardown that can be used
      for both device-tree and ACPI to unmap the GIC memory.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Store GIC configuration parameters · f673b9b5
      Jon Hunter authored
      Store the GIC configuration parameters in the GIC chip data structure.
      This will allow us to simplify the code by reducing the number of
      parameters passed between functions.
      Update the __gic_init_bases() function so that we only need to pass a
      pointer to the GIC chip data structure and no longer need to pass the
      GIC index in order to look-up the chip data.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Pass GIC pointer to save/restore functions · 6e5b5924
      Jon Hunter authored
      Instead of passing the GIC index to the save/restore functions pass a
      pointer to the GIC chip data. This will allow these save/restore
      functions to be re-used by a platform driver where the GIC chip data
      structure is allocated dynamically and so there is no applicable index
      for identifying the GIC.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Return an error if GIC initialisation fails · dc9722cc
      Jon Hunter authored
      If the GIC initialisation fails, then currently we do not return an error
      or clean-up afterwards. Although for root controllers, this failure may be
      fatal anyway, for secondary controllers, it may not be fatal and so return
      an error on failure and clean-up.
      Update the functions gic_cpu_init() and gic_pm_init() to return an error
      instead of calling BUG() and perform any necessary clean-up.
      For non-banked GIC controllers, make sure that we free any memory
      allocated if we fail to initialise the IRQ domain. Please note that
      free_percpu() only frees memory if the pointer passed to it is not NULL
      and so it is unnecessary to check if both pointers are valid or not.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Remove static irq_chip definition for eoimode1 · c2baa2f3
      Jon Hunter authored
      There are only 3 differences (not including the name) in the definitions
      of the gic_chip and gic_eoimode1_chip structures. Instead of statically
      defining the gic_eoimode1_chip structure, remove it and populate the
      eoimode1 functions dynamically for the appropriate GIC irqchips.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Jon Hunter's avatar
      irqchip/gic: Don't initialise chip if mapping IO space fails · 26acfe74
      Jon Hunter authored
      If we fail to map the address space for the GIC distributor or CPU
      interface, then don't attempt to initialise the chip, just WARN and
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Will Deacon's avatar
      irqchip/gic: Ensure ordering between read of INTACK and shared data · f86c4fbd
      Will Deacon authored
      When an IPI is generated by a CPU, the pattern looks roughly like:
        <write shared data>
        <write to GIC to signal SGI>
      On the receiving CPU we rely on the fact that, once we've taken the
      interrupt, then the freshly written shared data must be visible to us.
      Put another way, the CPU isn't going to speculate taking an interrupt.
      Unfortunately, this assumption turns out to be broken.
      Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
      to read some shared_data. Before CPUx has done anything, a random
      peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
      CPUy then takes the IRQ and starts executing the entry code, heading
      towards gic_handle_irq. Furthermore, let's assume that a bunch of the
      previous interrupts handled by CPUy were SGIs, so the branch predictor
      kicks in and speculates that irqnr will be <16 and we're likely to
      head into handle_IPI. The prefetcher then grabs a speculative copy of
      shared_data which contains a stale value.
      Meanwhile, CPUx gets round to updating shared_data and asking the GIC
      to send an SGI to CPUy. Internally, the GIC decides that the SGI is
      more important than the peripheral interrupt (which hasn't yet been
      ACKed) but doesn't need to do anything to CPUy, because the IRQ line
      is already raised.
      CPUy then reads the ACK register on the GIC, sees the SGI value which
      confirms the branch prediction and we end up with a stale shared_data
      This patch fixes the problem by adding an smp_rmb() to the IPI entry
      code in gic_handle_irq. As it turns out, the combination of a control
      dependency and an ISB instruction from the EOI in the GICv3 driver is
      enough to provide the ordering we need, so we add a comment there
      justifying the absence of an explicit smp_rmb().
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  24. 03 May, 2016 2 commits
  25. 25 Apr, 2016 1 commit
  26. 19 Feb, 2016 1 commit
  27. 11 Feb, 2016 2 commits