1. 04 9月, 2017 10 次提交
  2. 30 8月, 2017 4 次提交
    • P
      MIPS: GIC: Introduce asm/mips-gic.h with accessor functions · 582e2b4a
      Paul Burton 提交于
      This patch introduces a new header providing accessor functions for the
      MIPS Global Interrupt Controller (GIC) mirroring those provided for the
      other 2 components of the MIPS Coherent Processing System (CPS) - the
      Coherence Manager (CM) & Cluster Power Controller (CPC).
      
      This header makes use of the new standardised CPS accessor macros where
      possible, but does require some custom accessors for cases where we have
      either a bit or a register per interrupt.
      
      A major advantage of this over the existing
      include/linux/irqchip/mips-gic.h definitions is that code performing
      accesses can become much simpler, for example this:
      
        gic_update_bits(GIC_REG(SHARED, GIC_SH_SET_TRIGGER) +
                        GIC_INTR_OFS(intr), 1ul << GIC_INTR_BIT(intr),
                        (unsigned long)trig << GIC_INTR_BIT(intr));
      
      ...can become simply:
      
        change_gic_trig(intr, trig);
      
      The accessors handle 32 vs 64 bit in the same way as for CM & CPC code,
      which means that GIC code will also not need to worry about the access
      size in most cases. They are also accessible outside of
      drivers/irqchip/irq-mips-gic.c which will allow for simplification in
      the use of the non-interrupt portions of the GIC (eg. counters) which
      currently require the interrupt controller driver to expose helper
      functions for access.
      
      This patch doesn't change any existing code over to use the new
      accessors yet, since a wholesale change would be invasive & difficult to
      review. Instead follow-on patches will convert code piecemeal to use
      this new header. The one change to existing code is to rename gic_base
      to mips_gic_base & make it global, in order to fit in with the naming
      expected by the standardised CPS accessor macros.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17020/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      582e2b4a
    • J
      irqchip: mips-gic: SYNC after enabling GIC region · a0ffec3d
      James Hogan 提交于
      A SYNC is required between enabling the GIC region and actually trying
      to use it, even if the first access is a read, otherwise its possible
      depending on the timing (and in my case depending on the precise
      alignment of certain kernel code) to hit CM bus errors on that first
      access.
      
      Add the SYNC straight after setting the GIC base.
      
      [paul.burton@imgtec.com:
        Changes later in this series increase our likelihood of hitting this
        by reducing the amount of code that runs between enabling the GIC &
        accessing it.]
      
      Fixes: a7057270 ("irqchip: mips-gic: Add device-tree support")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17019/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a0ffec3d
    • P
      MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers · e83f7e02
      Paul Burton 提交于
      With Coherence Manager (CM) 3.5 information about the topology of the
      system, which has previously only been available through & accessed from
      the CM, is now also provided by the Cluster Power Controller (CPC). This
      includes a new CPC_CONFIG register mirroring GCR_CONFIG, and similarly a
      new CPC_Cx_CONFIG register mirroring GCR_Cx_CONFIG.
      
      In preparation for adjusting functions such as mips_cm_numcores(), which
      have previously only needed to access the CM, to also access the CPC
      this patch modifies the way we use the various CPS headers. Rather than
      having users include asm/mips-cm.h or asm/mips-cpc.h individually we
      instead have users include asm/mips-cps.h which in turn includes
      asm/mips-cm.h & asm/mips-cpc.h. This means that users will gain access
      to both CM & CPC registers by including one header, and most importantly
      it makes asm/mips-cps.h an ideal location for helper functions which
      need to access the various components of the CPS.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17015/
      Patchwork: https://patchwork.linux-mips.org/patch/17217/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e83f7e02
    • P
      MIPS: Unify checks for sibling CPUs · fe7a38c6
      Paul Burton 提交于
      Up until now we have open-coded checks for whether CPUs are siblings,
      with slight variations on whether we consider the package ID or not.
      
      This will only get more complex when we introduce cluster support, so in
      preparation for that this patch introduces a cpus_are_siblings()
      function which can be used to check whether or not 2 CPUs are siblings
      in a consistent manner.
      
      By checking globalnumber with the VP ID masked out this also has the
      neat side effect of being ready for multi-cluster systems already.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17011/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      fe7a38c6
  3. 29 8月, 2017 1 次提交
    • P
      MIPS: CM: Use BIT/GENMASK for register fields, order & drop shifts · 93c5bba5
      Paul Burton 提交于
      There's no reason for us not to use BIT() & GENMASK() in asm/mips-cm.h
      when declaring macros corresponding to register fields. This patch
      modifies our definitions to do so.
      
      The *_SHF definitions are removed entirely - they duplicate information
      found in the masks, are infrequently used & can be replaced with use of
      __ffs() where needed.
      
      The *_MSK definitions then lose their _MSK suffix which is now somewhat
      redundant, and users are modified to match.
      
      The field definitions are moved to follow the appropriate register's
      accessor functions, which helps to keep the field definitions in order &
      to find the appropriate fields for a given register. Whilst here a
      comment is added describing each register & including its name, which is
      helpful both for linking the register back to hardware documentation &
      for grepping purposes.
      
      This also cleans up a couple of issues that became obvious as a result
      of making the changes described above:
      
        - We previously had definitions for GCR_Cx_RESET_EXT_BASE & a phony
          copy of that named GCR_RESET_EXT_BASE - a register which does not
          exist. The bad definitions were added by commit 497e803e ("MIPS:
          smp-cps: Ensure secondary cores start with EVA disabled") and made
          use of from boot_core(), which is now modified to use the
          GCR_Cx_RESET_EXT_BASE definitions.
      
        - We had a typo in CM_GCR_ERROR_CAUSE_ERRINGO_MSK - we now correctly
          define this as inFo rather than inGo.
      
      Now that we don't duplicate field information between _SHF & _MSK
      definitions, and keep the fields next to the register accessors, it will
      be much easier to spot & prevent any similar oddities being introduced
      in the future.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Acked-by: Thomas Gleixner <tglx@linutronix.de
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17001/
      Patchwork: https://patchwork.linux-mips.org/patch/17216/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      93c5bba5
  4. 10 8月, 2017 2 次提交
    • L
      irqchip/gic-v3-its-platform-msi: Fix msi-parent parsing loop · a0088737
      Lorenzo Pieralisi 提交于
      While parsing the msi-parent property to chase up the IRQ domain
      a given device belongs to, the index into the msi-parent tuple should
      be incremented to ensure all properties entries are taken into account.
      
      Current code missed the index update so the parsing loop does not work
      in case multiple msi-parent phandles are present and may turn into
      an infinite loop in of_pmsi_get_dev_id() if phandle at index 0 does
      not correspond to the domain we are actually looking-up.
      
      Fix the code by updating the phandle index at each iteration in
      of_pmsi_get_dev_id().
      
      Fixes: deac7fc1 ("irqchip/gic-v3-its: Parse new version of msi-parent property")
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      a0088737
    • H
      irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES · fdf6e7a8
      Hanjun Guo 提交于
      When enabling ITS NUMA support on D05, I got the boot log:
      
      [    0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0
      [    0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1
      [    0.000000] SRAT: ITS affinity exceeding max count[4]
      
      This is wrong on D05 as we have 8 ITSs with 4 NUMA nodes.
      
      So dynamically alloc the memory needed instead of using
      its_srat_maps[MAX_NUMNODES], which count the number of
      ITS entry(ies) in SRAT and alloc its_srat_maps as needed,
      then build the mapping of numa node to ITS ID. Of course,
      its_srat_maps will be freed after ITS probing because
      we don't need that after boot.
      
      After doing this, I got what I wanted:
      
      [    0.000000] SRAT: PXM 0 -> ITS 0 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 1 -> Node 0
      [    0.000000] SRAT: PXM 0 -> ITS 2 -> Node 0
      [    0.000000] SRAT: PXM 1 -> ITS 3 -> Node 1
      [    0.000000] SRAT: PXM 2 -> ITS 4 -> Node 2
      [    0.000000] SRAT: PXM 2 -> ITS 5 -> Node 2
      [    0.000000] SRAT: PXM 2 -> ITS 6 -> Node 2
      [    0.000000] SRAT: PXM 3 -> ITS 7 -> Node 3
      
      Fixes: dbd2b826 ("irqchip/gic-v3-its: Add ACPI NUMA node mapping")
      Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
      Cc: John Garry <john.garry@huawei.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      fdf6e7a8
  5. 07 8月, 2017 1 次提交
  6. 02 8月, 2017 2 次提交
    • W
      irqchip/gic: Ensure we have an ISB between ack and ->handle_irq · 39a06b67
      Will Deacon 提交于
      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
         register
      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
         CPU.
      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: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      39a06b67
    • R
      irqchip/gic-v3-its: Remove ACPICA version check for ACPI NUMA · d1ce263f
      Robert Richter 提交于
      The version check was added due to dependency to
      
       a618c7f8 ACPICA: Add support for new SRAT subtable
      
      Now, that this code is in the kernel, remove the check. This is esp.
      useful to enable backports.
      Signed-off-by: NRobert Richter <rrichter@cavium.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      d1ce263f
  7. 19 7月, 2017 3 次提交
  8. 18 7月, 2017 1 次提交
  9. 04 7月, 2017 6 次提交
  10. 30 6月, 2017 3 次提交
    • P
      irqchip/or1k-pic: Fix interrupt acknowledgement · ca387019
      Pedro H. Penna 提交于
      Usually, hardware implicitly acknowledges interrupts when
      reading them. However, if this is not the case, the IRQ
      gets fired over and over again in the current implementation.
      
      This patch uses the right mask acknowledge function to handle the
      aforementioned situation on or1k processors that interact with
      such kind of hardware.
      Acked-by: NStafford Horne <shorne@gmail.com>
      Signed-off-by: NPedro H. Penna <pedrohenriquepenna@gmail.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      ca387019
    • D
      irqchip/irq-mvebu-gicp: Allocate enough memory for spi_bitmap · 478a2db8
      Dan Carpenter 提交于
      BITS_TO_LONGS() gives us the number of longs we need, but we want to
      allocate the number of bytes.
      
      Fixes: a68a63cb ("irqchip/irq-mvebu-gicp: Add new driver for Marvell GICP")
      Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      478a2db8
    • S
      irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity · 866d7c1b
      Suzuki K Poulose 提交于
      The GICv3 driver doesn't check if the target CPU for gic_set_affinity
      is valid before going ahead and making the changes. This triggers the
      following splat with KASAN:
      
      [  141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140
      [  141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0
      [  141.189958]
      [  141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7
      [  141.190458] Hardware name: Foundation-v8A (DT)
      [  141.190658] Call trace:
      [  141.190908] [<ffff200008089d70>] dump_backtrace+0x0/0x328
      [  141.191224] [<ffff20000808a1b4>] show_stack+0x14/0x20
      [  141.191507] [<ffff200008504c3c>] dump_stack+0xa4/0xc8
      [  141.191858] [<ffff20000826c19c>] print_address_description+0x13c/0x250
      [  141.192219] [<ffff20000826c5c8>] kasan_report+0x210/0x300
      [  141.192547] [<ffff20000826ad54>] __asan_load8+0x84/0x98
      [  141.192874] [<ffff20000854eeec>] gic_set_affinity+0x8c/0x140
      [  141.193158] [<ffff200008148b14>] irq_do_set_affinity+0x54/0xb8
      [  141.193473] [<ffff200008148d2c>] irq_set_affinity_locked+0x64/0xf0
      [  141.193828] [<ffff200008148e00>] __irq_set_affinity+0x48/0x78
      [  141.194158] [<ffff200008bc48a4>] arm_perf_starting_cpu+0x104/0x150
      [  141.194513] [<ffff2000080d73bc>] cpuhp_invoke_callback+0x17c/0x1f8
      [  141.194783] [<ffff2000080d94ec>] notify_cpu_starting+0x8c/0xb8
      [  141.195130] [<ffff2000080911ec>] secondary_start_kernel+0x15c/0x200
      [  141.195390] [<0000000080db81b4>] 0x80db81b4
      [  141.195603]
      [  141.195685] The buggy address belongs to the variable:
      [  141.196012]  __cpu_logical_map+0x200/0x220
      [  141.196176]
      [  141.196315] Memory state around the buggy address:
      [  141.196586]  ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  141.196913]  ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
      [  141.197487]                                ^
      [  141.197758]  ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
      [  141.198060]  ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [  141.198358] ==================================================================
      [  141.198609] Disabling lock debugging due to kernel taint
      [  141.198961] CPU1: Booted secondary processor [410fd051]
      
      This patch adds the check to make sure the cpu is valid.
      
      Fixes: commit 021f6537 ("irqchip: gic-v3: Initial support for GICv3")
      Cc: stable@vger.kernel.org
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      866d7c1b
  11. 23 6月, 2017 7 次提交