1. 20 Feb, 2019 4 commits
    • Paul Burton's avatar
      MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds · dfb35362
      Paul Burton authored
      commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
      
      When generating vdso-o32.lds & vdso-n32.lds for use with programs
      running as compat ABIs under 64b kernels, we previously haven't included
      the compiler flags that are supposedly common to all ABIs - ie. those in
      the ccflags-vdso variable.
      
      This is problematic in cases where we need to provide the -m%-float flag
      in order to ensure that we don't attempt to use a floating point ABI
      that's incompatible with the target CPU & ABI. For example a toolchain
      using current gcc trunk configured --with-fp-32=xx fails to build a
      64r6el_defconfig kernel with the following error:
      
        cc1: error: '-march=mips1' requires '-mfp32'
        make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
      
      Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
      included for the native VDSO .lds & when compiling objects for the
      compat VDSOs. This ensures we consistently provide the -msoft-float flag
      amongst others, avoiding the problem by ensuring we're agnostic to the
      toolchain defaults.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: linux-mips@vger.kernel.org
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej W . Rozycki <macro@linux-mips.org>
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb35362
    • Aaro Koskinen's avatar
      MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled · 91aaa0dd
      Aaro Koskinen authored
      commit dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
      
      Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
      of the MSI irqchip later on, and saves a bit of memory.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
      Cc: stable@vger.kernel.org # v3.3+
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91aaa0dd
    • Vladimir Kondratiev's avatar
      mips: cm: reprime error cause · d93fdf44
      Vladimir Kondratiev authored
      commit 05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
      
      Accordingly to the documentation
      ---cut---
      The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
      fields can be cleared by either a reset or by writing the current
      value of GCR_ERROR_CAUSE.ERR_TYPE to the
      GCR_ERROR_CAUSE.ERR_TYPE register.
      ---cut---
      Do exactly this. Original value of cm_error may be safely written back;
      it clears error cause and keeps other bits untouched.
      
      Fixes: 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors")
      Signed-off-by: default avatarVladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d93fdf44
    • Jiong Wang's avatar
      mips: bpf: fix encoding bug for mm_srlv32_op · cab345f0
      Jiong Wang authored
      [ Upstream commit 17f6c83fb5ebf7db4fcc94a5be4c22d5a7bfe428 ]
      
      For micro-mips, srlv inside POOL32A encoding space should use 0x50
      sub-opcode, NOT 0x90.
      
      Some early version ISA doc describes the encoding as 0x90 for both srlv and
      srav, this looks to me was a typo. I checked Binutils libopcode
      implementation which is using 0x50 for srlv and 0x90 for srav.
      
      v1->v2:
        - Keep mm_srlv32_op sorted by value.
      
      Fixes: f31318fd ("MIPS: uasm: Add srlv uasm instruction")
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarJiong Wang <jiong.wang@netronome.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cab345f0
  2. 26 Jan, 2019 3 commits
    • Maciej W. Rozycki's avatar
      MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur · c890a458
      Maciej W. Rozycki authored
      [ Upstream commit e4849aff1e169b86c561738daf8ff020e9de1011 ]
      
      The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
      DRAM controller that supports memory amounts of up to 16GiB, and due to
      how the address decoder has been wired in the SOC any memory beyond 1GiB
      is actually mapped starting from 4GiB physical up, that is beyond the
      32-bit addressable limit[1].  Consequently if the maximum amount of
      memory has been installed, then it will span up to 19GiB.
      
      Many of the evaluation boards we support that are based on one of these
      SOCs have their memory soldered and the amount present fits in the
      32-bit address range.  The BCM91250A SWARM board however has actual DIMM
      slots and accepts, depending on the peripherals revision of the SOC, up
      to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
      I believe this is also the case with the BCM91250C2 LittleSur board.
      This means that up to either 3GiB or 7GiB of memory requires 64-bit
      addressing to access.
      
      I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
      accepts at least as much memory, although I have no documentation or
      actual hardware available to verify that.
      
      Both systems have PCI slots installed for use by any PCI option boards,
      including ones that only support 32-bit addressing (additionally the
      32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
      addressing to 32-bits), and there is no IOMMU available.  Therefore for
      PCI DMA to work in the presence of memory beyond enable swiotlb for the
      affected systems.
      
      All the other SOC onchip DMA devices use 40-bit addressing and therefore
      can address the whole memory, so only enable swiotlb if PCI support and
      support for DMA beyond 4GiB have been both enabled in the configuration
      of the kernel.
      
      This shows up as follows:
      
      Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
      Board type: SiByte BCM91250A (SWARM)
      Determined physical RAM map:
       memory: 000000000fe7fe00 @ 0000000000000000 (usable)
       memory: 000000001ffffe00 @ 0000000080000000 (usable)
       memory: 000000000ffffe00 @ 00000000c0000000 (usable)
       memory: 0000000087fffe00 @ 0000000100000000 (usable)
      software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)
      
      in the bootstrap log and removes failures like these:
      
      defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
      fddi0: Receive buffer allocation failed
      fddi0: Adapter open failed!
      IP-Config: Failed to open fddi0
      defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
      fddi1: Receive buffer allocation failed
      fddi1: Adapter open failed!
      IP-Config: Failed to open fddi1
      
      when memory beyond 4GiB is handed out to devices that can only do 32-bit
      addressing.
      
      This updates commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
      DMA32.").
      
      References:
      
      [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
          Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
          "Memory Map", pp. 34-38
      
      [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
          Corporation, 18 May 2004, Section 3: "Physical Description",
          "Supported DRAM", p. 23
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Patchwork: https://patchwork.linux-mips.org/patch/21108/
      References: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c890a458
    • YunQiang Su's avatar
      Disable MSI also when pcie-octeon.pcie_disable on · 93e6b265
      YunQiang Su authored
      commit a214720cbf50cd8c3f76bbb9c3f5c283910e9d33 upstream.
      
      Octeon has an boot-time option to disable pcie.
      
      Since MSI depends on PCI-E, we should also disable MSI also with
      this option is on in order to avoid inadvertently accessing PCIe
      registers.
      Signed-off-by: default avatarYunQiang Su <ysu@wavecomp.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: pburton@wavecomp.com
      Cc: linux-mips@vger.kernel.org
      Cc: aaro.koskinen@iki.fi
      Cc: stable@vger.kernel.org # v3.3+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93e6b265
    • Arnd Bergmann's avatar
      mips: fix n32 compat_ipc_parse_version · db58a203
      Arnd Bergmann authored
      commit 5a9372f751b5350e0ce3d2ee91832f1feae2c2e5 upstream.
      
      While reading through the sysvipc implementation, I noticed that the n32
      semctl/shmctl/msgctl system calls behave differently based on whether
      o32 support is enabled or not: Without o32, the IPC_64 flag passed by
      user space is rejected but calls without that flag get IPC_64 behavior.
      
      As far as I can tell, this was inadvertently changed by a cleanup patch
      but never noticed by anyone, possibly nobody has tried using sysvipc
      on n32 after linux-3.19.
      
      Change it back to the old behavior now.
      
      Fixes: 78aaf956 ("MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # 3.19+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db58a203
  3. 13 Jan, 2019 2 commits
  4. 17 Dec, 2018 1 commit
  5. 13 Dec, 2018 2 commits
  6. 21 Nov, 2018 4 commits
  7. 10 Nov, 2018 4 commits
    • Maciej W. Rozycki's avatar
      MIPS: DEC: Fix an int-handler.S CPU_DADDI_WORKAROUNDS regression · fbba23bb
      Maciej W. Rozycki authored
      [ Upstream commit 68fe5568 ]
      
      Fix a commit 3021773c ("MIPS: DEC: Avoid la pseudo-instruction in
      delay slots") regression and remove assembly errors:
      
      arch/mips/dec/int-handler.S: Assembler messages:
      arch/mips/dec/int-handler.S:162: Error: Macro used $at after ".set noat"
      arch/mips/dec/int-handler.S:163: Error: Macro used $at after ".set noat"
      arch/mips/dec/int-handler.S:229: Error: Macro used $at after ".set noat"
      arch/mips/dec/int-handler.S:230: Error: Macro used $at after ".set noat"
      
      triggering with with the CPU_DADDI_WORKAROUNDS option set and the DADDIU
      instruction.  This is because with that option in place the instruction
      becomes a macro, which expands to an LI/DADDU (or actually ADDIU/DADDU)
      sequence that uses $at as a temporary register.
      
      With CPU_DADDI_WORKAROUNDS we only support `-msym32' compilation though,
      and this is already enforced in arch/mips/Makefile, so choose the 32-bit
      expansion variant for the supported configurations and then replace the
      64-bit variant with #error just in case.
      
      Fixes: 3021773c ("MIPS: DEC: Avoid la pseudo-instruction in delay slots")
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # 4.8+
      Patchwork: https://patchwork.linux-mips.org/patch/16893/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fbba23bb
    • Matt Redfearn's avatar
      MIPS: microMIPS: Fix decoding of swsp16 instruction · 0f951e1a
      Matt Redfearn authored
      [ Upstream commit cea8cd49 ]
      
      When the immediate encoded in the instruction is accessed, it is sign
      extended due to being a signed value being assigned to a signed integer.
      The ISA specifies that this operation is an unsigned operation.
      The sign extension leads us to incorrectly decode:
      
      801e9c8e:       cbf1            sw      ra,68(sp)
      
      As having an immediate of 1073741809.
      
      Since the instruction format does not specify signed/unsigned, and this
      is currently the only location to use this instuction format, change it
      to an unsigned immediate.
      
      Fixes: bb9bc468 ("MIPS: Calculate microMIPS ra properly when unwinding the stack")
      Suggested-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Reviewed-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: Miodrag Dinic <miodrag.dinic@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16957/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0f951e1a
    • Matt Redfearn's avatar
      MIPS: Handle non word sized instructions when examining frame · f46b1dc5
      Matt Redfearn authored
      [ Upstream commit 11887ed1 ]
      
      Commit 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      added fairly broken support for handling 16bit microMIPS instructions in
      get_frame_info(). It adjusts the instruction pointer by 16bits in the
      case of a 16bit sp move instruction, but not any other 16bit
      instruction.
      
      Commit b6c7a324 ("MIPS: Fix get_frame_info() handling of microMIPS
      function size") goes some way to fixing get_frame_info() to iterate over
      microMIPS instuctions, but the instruction pointer is still manipulated
      using a postincrement, and is of union mips_instruction type. Since the
      union is sized to the largest member (a word), but microMIPS
      instructions are a mix of halfword and word sizes, the function does not
      always iterate correctly, ending up misaligned with the instruction
      stream and interpreting it incorrectly.
      
      Since the instruction modifying the stack pointer is usually the first
      in the function, that one is usually handled correctly. But the
      instruction which saves the return address to the sp is some variable
      number of instructions into the frame and is frequently missed due to
      not being on a word boundary, leading to incomplete walking of the
      stack.
      
      Fix this by incrementing the instruction pointer based on the size of
      the previously decoded instruction (& remove the hack introduced by
      commit 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      which adjusts the instruction pointer in the case of a 16bit sp move
      instruction, but not any other).
      
      Fixes: 34c2f668 ("MIPS: microMIPS: Add unaligned access support.")
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/16953/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f46b1dc5
    • Maciej W. Rozycki's avatar
      MIPS: Fix FCSR Cause bit handling for correct SIGFPE issue · 1c84d14e
      Maciej W. Rozycki authored
      [ Upstream commit 5a1aca44 ]
      
      Sanitize FCSR Cause bit handling, following a trail of past attempts:
      
      * commit 42495484 ("MIPS: ptrace: Fix FP context restoration FCSR
      regression"),
      
      * commit 443c4403 ("MIPS: Always clear FCSR cause bits after
      emulation"),
      
      * commit 64bedffe ("MIPS: Clear [MSA]FPE CSR.Cause after
      notify_die()"),
      
      * commit b1442d39 ("MIPS: Prevent user from setting FCSR cause
      bits"),
      
      * commit b54d2901517d ("Properly handle branch delay slots in connection
      with signals.").
      
      Specifically do not mask these bits out in ptrace(2) processing and send
      a SIGFPE signal instead whenever a matching pair of an FCSR Cause and
      Enable bit is seen as execution of an affected context is about to
      resume.  Only then clear Cause bits, and even then do not clear any bits
      that are set but masked with the respective Enable bits.  Adjust Cause
      bit clearing throughout code likewise, except within the FPU emulator
      proper where they are set according to IEEE 754 exceptions raised as the
      operation emulated executed.  Do so so that any IEEE 754 exceptions
      subject to their default handling are recorded like with operations
      executed by FPU hardware.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/14460/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1c84d14e
  8. 26 Sep, 2018 4 commits
  9. 19 Sep, 2018 4 commits
  10. 05 Sep, 2018 3 commits
    • Paul Burton's avatar
      MIPS: lib: Provide MIPS64r6 __multi3() for GCC < 7 · bb190ace
      Paul Burton authored
      commit 690d9163bf4b8563a2682e619f938e6a0443947f upstream.
      
      Some versions of GCC suboptimally generate calls to the __multi3()
      intrinsic for MIPS64r6 builds, resulting in link failures due to the
      missing function:
      
          LD      vmlinux.o
          MODPOST vmlinux.o
        kernel/bpf/verifier.o: In function `kmalloc_array':
        include/linux/slab.h:631: undefined reference to `__multi3'
        fs/select.o: In function `kmalloc_array':
        include/linux/slab.h:631: undefined reference to `__multi3'
        ...
      
      We already have a workaround for this in which we provide the
      instrinsic, but we do so selectively for GCC 7 only. Unfortunately the
      issue occurs with older GCC versions too - it has been observed with
      both GCC 5.4.0 & GCC 6.4.0.
      
      MIPSr6 support was introduced in GCC 5, so all major GCC versions prior
      to GCC 8 are affected and we extend our workaround accordingly to all
      MIPS64r6 builds using GCC versions older than GCC 8.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reported-by: default avatarVladimir Kondratiev <vladimir.kondratiev@intel.com>
      Fixes: ebabcf17 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds")
      Patchwork: https://patchwork.linux-mips.org/patch/20297/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # 4.15+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb190ace
    • Maciej W. Rozycki's avatar
      MIPS: Correct the 64-bit DSP accumulator register size · 79ffdc48
      Maciej W. Rozycki authored
      commit f5958b4cf4fc38ed4583ab83fb7c4cd1ab05f47b upstream.
      
      Use the `unsigned long' rather than `__u32' type for DSP accumulator
      registers, like with the regular MIPS multiply/divide accumulator and
      general-purpose registers, as all are 64-bit in 64-bit implementations
      and using a 32-bit data type leads to contents truncation on context
      saving.
      
      Update `arch_ptrace' and `compat_arch_ptrace' accordingly, removing
      casts that are similarly not used with multiply/divide accumulator or
      general-purpose register accesses.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@mips.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: e50c0a8f ("Support the MIPS32 / MIPS64 DSP ASE.")
      Patchwork: https://patchwork.linux-mips.org/patch/19329/
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # 2.6.15+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79ffdc48
    • Rafał Miłecki's avatar
      Revert "MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum" · 7d1a2eef
      Rafał Miłecki authored
      [ Upstream commit d5ea019f8a381f88545bb26993b62ec24a2796b7 ]
      
      This reverts commit 2a027b47dba6 ("MIPS: BCM47XX: Enable 74K Core
      ExternalSync for PCIe erratum").
      
      Enabling ExternalSync caused a regression for BCM4718A1 (used e.g. in
      Netgear E3000 and ASUS RT-N16): it simply hangs during PCIe
      initialization. It's likely that BCM4717A1 is also affected.
      
      I didn't notice that earlier as the only BCM47XX devices with PCIe I
      own are:
      1) BCM4706 with 2 x 14e4:4331
      2) BCM4706 with 14e4:4360 and 14e4:4331
      it appears that BCM4706 is unaffected.
      
      While BCM5300X-ES300-RDS.pdf seems to document that erratum and its
      workarounds (according to quotes provided by Tokunori) it seems not even
      Broadcom follows them.
      
      According to the provided info Broadcom should define CONF7_ES in their
      SDK's mipsinc.h and implement workaround in the si_mips_init(). Checking
      both didn't reveal such code. It *could* mean Broadcom also had some
      problems with the given workaround.
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reported-by: default avatarMichael Marley <michael@michaelmarley.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20032/
      URL: https://bugs.openwrt.org/index.php?do=details&task_id=1688
      Cc: Tokunori Ikegami <ikegami@allied-telesis.co.jp>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d1a2eef
  11. 06 Aug, 2018 1 commit
    • Paul Burton's avatar
      MIPS: Fix off-by-one in pci_resource_to_user() · 97e06612
      Paul Burton authored
      commit 38c0a74fe06da3be133cae3fb7bde6a9438e698b upstream.
      
      The MIPS implementation of pci_resource_to_user() introduced in v3.12 by
      commit 4c2924b7 ("MIPS: PCI: Use pci_resource_to_user to map pci
      memory space properly") incorrectly sets *end to the address of the
      byte after the resource, rather than the last byte of the resource.
      
      This results in userland seeing resources as a byte larger than they
      actually are, for example a 32 byte BAR will be reported by a tool such
      as lspci as being 33 bytes in size:
      
          Region 2: I/O ports at 1000 [disabled] [size=33]
      
      Correct this by subtracting one from the calculated end address,
      reporting the correct address to userland.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reported-by: default avatarRui Wang <rui.wang@windriver.com>
      Fixes: 4c2924b7 ("MIPS: PCI: Use pci_resource_to_user to map pci memory space properly")
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Wolfgang Grandegger <wg@grandegger.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # v3.12+
      Patchwork: https://patchwork.linux-mips.org/patch/19829/Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97e06612
  12. 28 Jul, 2018 1 commit
  13. 22 Jul, 2018 2 commits
    • Paul Burton's avatar
      MIPS: Use async IPIs for arch_trigger_cpumask_backtrace() · 3a7031fd
      Paul Burton authored
      commit b63e132b6433a41cf311e8bc382d33fd2b73b505 upstream.
      
      The current MIPS implementation of arch_trigger_cpumask_backtrace() is
      broken because it attempts to use synchronous IPIs despite the fact that
      it may be run with interrupts disabled.
      
      This means that when arch_trigger_cpumask_backtrace() is invoked, for
      example by the RCU CPU stall watchdog, we may:
      
        - Deadlock due to use of synchronous IPIs with interrupts disabled,
          causing the CPU that's attempting to generate the backtrace output
          to hang itself.
      
        - Not succeed in generating the desired output from remote CPUs.
      
        - Produce warnings about this from smp_call_function_many(), for
          example:
      
          [42760.526910] INFO: rcu_sched detected stalls on CPUs/tasks:
          [42760.535755]  0-...!: (1 GPs behind) idle=ade/140000000000000/0 softirq=526944/526945 fqs=0
          [42760.547874]  1-...!: (0 ticks this GP) idle=e4a/140000000000000/0 softirq=547885/547885 fqs=0
          [42760.559869]  (detected by 2, t=2162 jiffies, g=266689, c=266688, q=33)
          [42760.568927] ------------[ cut here ]------------
          [42760.576146] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:416 smp_call_function_many+0x88/0x20c
          [42760.587839] Modules linked in:
          [42760.593152] CPU: 2 PID: 1216 Comm: sh Not tainted 4.15.4-00373-gee058bb4d0c2 #2
          [42760.603767] Stack : 8e09bd20 8e09bd20 8e09bd20 fffffff0 00000007 00000006 00000000 8e09bca8
          [42760.616937]         95b2b379 95b2b379 807a0080 00000007 81944518 0000018a 00000032 00000000
          [42760.630095]         00000000 00000030 80000000 00000000 806eca74 00000009 8017e2b8 000001a0
          [42760.643169]         00000000 00000002 00000000 8e09baa4 00000008 808b8008 86d69080 8e09bca0
          [42760.656282]         8e09ad50 805e20aa 00000000 00000000 00000000 8017e2b8 00000009 801070ca
          [42760.669424]         ...
          [42760.673919] Call Trace:
          [42760.678672] [<27fde568>] show_stack+0x70/0xf0
          [42760.685417] [<84751641>] dump_stack+0xaa/0xd0
          [42760.692188] [<699d671c>] __warn+0x80/0x92
          [42760.698549] [<68915d41>] warn_slowpath_null+0x28/0x36
          [42760.705912] [<f7c76c1c>] smp_call_function_many+0x88/0x20c
          [42760.713696] [<6bbdfc2a>] arch_trigger_cpumask_backtrace+0x30/0x4a
          [42760.722216] [<f845bd33>] rcu_dump_cpu_stacks+0x6a/0x98
          [42760.729580] [<796e7629>] rcu_check_callbacks+0x672/0x6ac
          [42760.737476] [<059b3b43>] update_process_times+0x18/0x34
          [42760.744981] [<6eb94941>] tick_sched_handle.isra.5+0x26/0x38
          [42760.752793] [<478d3d70>] tick_sched_timer+0x1c/0x50
          [42760.759882] [<e56ea39f>] __hrtimer_run_queues+0xc6/0x226
          [42760.767418] [<e88bbcae>] hrtimer_interrupt+0x88/0x19a
          [42760.775031] [<6765a19e>] gic_compare_interrupt+0x2e/0x3a
          [42760.782761] [<0558bf5f>] handle_percpu_devid_irq+0x78/0x168
          [42760.790795] [<90c11ba2>] generic_handle_irq+0x1e/0x2c
          [42760.798117] [<1b6d462c>] gic_handle_local_int+0x38/0x86
          [42760.805545] [<b2ada1c7>] gic_irq_dispatch+0xa/0x14
          [42760.812534] [<90c11ba2>] generic_handle_irq+0x1e/0x2c
          [42760.820086] [<c7521934>] do_IRQ+0x16/0x20
          [42760.826274] [<9aef3ce6>] plat_irq_dispatch+0x62/0x94
          [42760.833458] [<6a94b53c>] except_vec_vi_end+0x70/0x78
          [42760.840655] [<22284043>] smp_call_function_many+0x1ba/0x20c
          [42760.848501] [<54022b58>] smp_call_function+0x1e/0x2c
          [42760.855693] [<ab9fc705>] flush_tlb_mm+0x2a/0x98
          [42760.862730] [<0844cdd0>] tlb_flush_mmu+0x1c/0x44
          [42760.869628] [<cb259b74>] arch_tlb_finish_mmu+0x26/0x3e
          [42760.877021] [<1aeaaf74>] tlb_finish_mmu+0x18/0x66
          [42760.883907] [<b3fce717>] exit_mmap+0x76/0xea
          [42760.890428] [<c4c8a2f6>] mmput+0x80/0x11a
          [42760.896632] [<a41a08f4>] do_exit+0x1f4/0x80c
          [42760.903158] [<ee01cef6>] do_group_exit+0x20/0x7e
          [42760.909990] [<13fa8d54>] __wake_up_parent+0x0/0x1e
          [42760.917045] [<46cf89d0>] smp_call_function_many+0x1a2/0x20c
          [42760.924893] [<8c21a93b>] syscall_common+0x14/0x1c
          [42760.931765] ---[ end trace 02aa09da9dc52a60 ]---
          [42760.938342] ------------[ cut here ]------------
          [42760.945311] WARNING: CPU: 2 PID: 1216 at kernel/smp.c:291 smp_call_function_single+0xee/0xf8
          ...
      
      This patch switches MIPS' arch_trigger_cpumask_backtrace() to use async
      IPIs & smp_call_function_single_async() in order to resolve this
      problem. We ensure use of the pre-allocated call_single_data_t
      structures is serialized by maintaining a cpumask indicating that
      they're busy, and refusing to attempt to send an IPI when a CPU's bit is
      set in this mask. This should only happen if a CPU hasn't responded to a
      previous backtrace IPI - ie. if it's hung - and we print a warning to
      the console in this case.
      
      I've marked this for stable branches as far back as v4.9, to which it
      applies cleanly. Strictly speaking the faulty MIPS implementation can be
      traced further back to commit 856839b7 ("MIPS: Add
      arch_trigger_all_cpu_backtrace() function") in v3.19, but kernel
      versions v3.19 through v4.8 will require further work to backport due to
      the rework performed in commit 9a01c3ed ("nmi_backtrace: add more
      trigger_*_cpu_backtrace() methods").
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19597/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # v4.9+
      Fixes: 856839b7 ("MIPS: Add arch_trigger_all_cpu_backtrace() function")
      Fixes: 9a01c3ed ("nmi_backtrace: add more trigger_*_cpu_backtrace() methods")
      [ Huacai: backported to 4.4: Restruction since generic NMI solution is unavailable ]
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a7031fd
    • Paul Burton's avatar
      MIPS: Call dump_stack() from show_regs() · 5396b1a6
      Paul Burton authored
      commit 5a267832c2ec47b2dad0fdb291a96bb5b8869315 upstream.
      
      The generic nmi_cpu_backtrace() function calls show_regs() when a struct
      pt_regs is available, and dump_stack() otherwise. If we were to make use
      of the generic nmi_cpu_backtrace() with MIPS' current implementation of
      show_regs() this would mean that we see only register data with no
      accompanying stack information, in contrast with our current
      implementation which calls dump_stack() regardless of whether register
      state is available.
      
      In preparation for making use of the generic nmi_cpu_backtrace() to
      implement arch_trigger_cpumask_backtrace(), have our implementation of
      show_regs() call dump_stack() and drop the explicit dump_stack() call in
      arch_dump_stack() which is invoked by arch_trigger_cpumask_backtrace().
      
      This will allow the output we produce to remain the same after a later
      patch switches to using nmi_cpu_backtrace(). It may mean that we produce
      extra stack output in other uses of show_regs(), but this:
      
        1) Seems harmless.
        2) Is good for consistency between arch_trigger_cpumask_backtrace()
           and other users of show_regs().
        3) Matches the behaviour of the ARM & PowerPC architectures.
      
      Marked for stable back to v4.9 as a prerequisite of the following patch
      "MIPS: Call dump_stack() from show_regs()".
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19596/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5396b1a6
  14. 17 Jul, 2018 1 commit
    • Paul Burton's avatar
      MIPS: Fix ioremap() RAM check · bc20ab94
      Paul Burton authored
      commit 523402fa9101090c91d2033b7ebdfdcf65880488 upstream.
      
      We currently attempt to check whether a physical address range provided
      to __ioremap() may be in use by the page allocator by examining the
      value of PageReserved for each page in the region - lowmem pages not
      marked reserved are presumed to be in use by the page allocator, and
      requests to ioremap them fail.
      
      The way we check this has been broken since commit 92923ca3 ("mm:
      meminit: only set page reserved in the memblock region"), because
      memblock will typically not have any knowledge of non-RAM pages and
      therefore those pages will not have the PageReserved flag set. Thus when
      we attempt to ioremap a region outside of RAM we incorrectly fail
      believing that the region is RAM that may be in use.
      
      In most cases ioremap() on MIPS will take a fast-path to use the
      unmapped kseg1 or xkphys virtual address spaces and never hit this path,
      so the only way to hit it is for a MIPS32 system to attempt to ioremap()
      an address range in lowmem with flags other than _CACHE_UNCACHED.
      Perhaps the most straightforward way to do this is using
      ioremap_uncached_accelerated(), which is how the problem was discovered.
      
      Fix this by making use of walk_system_ram_range() to test the address
      range provided to __ioremap() against only RAM pages, rather than all
      lowmem pages. This means that if we have a lowmem I/O region, which is
      very common for MIPS systems, we're free to ioremap() address ranges
      within it. A nice bonus is that the test is no longer limited to lowmem.
      
      The approach here matches the way x86 performed the same test after
      commit c81c8a1e ("x86, ioremap: Speed up check for RAM pages") until
      x86 moved towards a slightly more complicated check using walk_mem_res()
      for unrelated reasons with commit 0e4c12b4 ("x86/mm, resource: Use
      PAGE_KERNEL protection for ioremap of memory pages").
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reported-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Tested-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Fixes: 92923ca3 ("mm: meminit: only set page reserved in the memblock region")
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # v4.2+
      Patchwork: https://patchwork.linux-mips.org/patch/19786/Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc20ab94
  15. 03 Jul, 2018 3 commits
  16. 06 Jun, 2018 1 commit
    • Maciej W. Rozycki's avatar
      MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests · bedcf2fa
      Maciej W. Rozycki authored
      commit 28e4213dd331e944e7fca1954a946829162ed9d4 upstream.
      
      Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e.
      Status.FR) is not supported as the lone purpose of Config5.FRE is to
      emulate Status.FR=0 handling on FPU hardware that has Status.FR=1
      hardwired[1][2].  Also we do not handle this case elsewhere, and assume
      throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot
      be set both at once for a task, leading to inconsistent behaviour if
      this does happen.
      
      Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting
      PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear.  This corresponds to
      modes allowed by `mips_set_personality_fp'.
      
      References:
      
      [1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32
          Privileged Resource Architecture", Imagination Technologies,
          Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69
          "Config5 Register Field Descriptions", p. 262
      
      [2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64
          Privileged Resource Architecture", Imagination Technologies,
          Document Number: MD00091, Revision 6.03, December 22, 2015, Table
          9.72 "Config5 Register Field Descriptions", p. 288
      
      Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
      Signed-off-by: default avatarMaciej W. Rozycki <macro@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 4.0+
      Patchwork: https://patchwork.linux-mips.org/patch/19327/Signed-off-by: default avatarJames Hogan <jhogan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bedcf2fa