1. 24 Jul, 2018 5 commits
  2. 23 Jul, 2018 2 commits
    • Hauke Mehrtens's avatar
      MIPS: lantiq: Use dma_zalloc_coherent() in dma code · 2b5c4913
      Hauke Mehrtens authored
      Instead of using dma_alloc_coherent() and memset() directly use
      dma_zalloc_coherent().
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19962/
      Cc: ralf@linux-mips.org
      Cc: jhogan@kernel.org
      Cc: john@phrozen.org
      Cc: linux-mips@linux-mips.org
      Cc: dev@kresin.me
      2b5c4913
    • Huacai Chen's avatar
      MIPS: Change definition of cpu_relax() for Loongson-3 · a3071886
      Huacai Chen authored
      Linux expects that if a CPU modifies a memory location, then that
      modification will eventually become visible to other CPUs in the system.
      
      Loongson 3 CPUs include a Store Fill Buffer (SFB) which sits between a
      core & its L1 data cache, queueing memory accesses & allowing for faster
      forwarding of data from pending stores to younger loads from the core.
      Unfortunately the SFB prioritizes loads such that a continuous stream of
      loads may cause a pending write to be buffered indefinitely. This is
      problematic if we end up with 2 CPUs which each perform a store that the
      other polls for - one or both CPUs may end up with their stores buffered
      in the SFB, never reaching cache due to the continuous reads from the
      poll loop. Such a deadlock condition has been observed whilst running
      qspinlock code.
      
      This patch changes the definition of cpu_relax() to smp_mb() for
      Loongson-3, forcing a flush of the SFB on SMP systems which will cause
      any pending writes to make it as far as the L1 caches where they will
      become visible to other CPUs. If the kernel is not compiled for SMP
      support, this will expand to a barrier() as before.
      
      This workaround matches that currently implemented for ARM when
      CONFIG_ARM_ERRATA_754327=y, which was introduced by commit 534be1d5
      ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore").
      
      Although the workaround is only required when the Loongson 3 SFB
      functionality is enabled, and we only began explicitly enabling that
      functionality in v4.7 with commit 1e820da3 ("MIPS: Loongson-3:
      Introduce CONFIG_LOONGSON3_ENHANCEMENT"), existing or future firmware
      may enable the SFB which means we may need the workaround backported to
      earlier kernels too.
      
      [paul.burton@mips.com:
        - Reword commit message & comment.
        - Limit stable backport to v3.15+ where we support Loongson 3 CPUs.]
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      References: 534be1d5 ("ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore")
      References: 1e820da3 ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT")
      Patchwork: https://patchwork.linux-mips.org/patch/19830/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: Huacai Chen <chenhuacai@gmail.com>
      Cc: stable@vger.kernel.org # v3.15+
      a3071886
  3. 20 Jul, 2018 1 commit
  4. 19 Jul, 2018 4 commits
    • Maciej W. Rozycki's avatar
      MIPS: Add FP_MODE regset support · 1ae22a0e
      Maciej W. Rozycki authored
      Define an NT_MIPS_FP_MODE core file note and implement a corresponding
      regset holding the state handled by PR_SET_FP_MODE and PR_GET_FP_MODE
      prctl(2) requests.  This lets debug software correctly interpret the
      contents of floating-point general registers both in live debugging and
      in core files, and also switch floating-point modes of a live process.
      
      [paul.burton@mips.com:
        - Changed NT_MIPS_FP_MODE to 0x801 to match first nibble of
          NT_MIPS_DSP, which was also changed to avoid a conflict.]
      Signed-off-by: default avatarMaciej W. Rozycki <macro@mips.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19331/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      1ae22a0e
    • Maciej W. Rozycki's avatar
      MIPS: Add DSP ASE regset support · 44109c60
      Maciej W. Rozycki authored
      Define an NT_MIPS_DSP core file note type and implement a corresponding
      regset holding the DSP ASE register context, following the layout of the
      `mips_dsp_state' structure, except for the DSPControl register stored as
      a 64-bit rather than 32-bit quantity in a 64-bit note.
      
      The lack of DSP ASE register saving to core files can be considered a
      design flaw with commit e50c0a8f ("Support the MIPS32 / MIPS64 DSP
      ASE."), leading to an incomplete state being saved.  Consequently no DSP
      ASE regset has been created with commit 7aeb753b ("MIPS: Implement
      task_user_regset_view."), when regset support was added to the MIPS
      port.
      
      Additionally there is no way for ptrace(2) to correctly access the DSP
      accumulator registers in n32 processes with the existing interfaces.
      This is due to 32-bit truncation of data passed with PTRACE_PEEKUSR and
      PTRACE_POKEUSR requests, which cannot be avoided owing to how the data
      types for ptrace(3) have been defined.  This new NT_MIPS_DSP regset
      fills the missing interface gap.
      
      [paul.burton@mips.com:
        - Change NT_MIPS_DSP to 0x800 to avoid conflict with NT_VMCOREDD
          introduced by commit 2724273e ("vmcore: add API to collect
          hardware dump in second kernel").
        - Drop stable tag. Whilst I agree the lack of this functionality can
          be considered a flaw in earlier DSP ASE support, it's still new
          functionality which doesn't meet up to the requirements set out in
          Documentation/process/stable-kernel-rules.rst.]
      Signed-off-by: default avatarMaciej W. Rozycki <macro@mips.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      References: 7aeb753b ("MIPS: Implement task_user_regset_view.")
      Patchwork: https://patchwork.linux-mips.org/patch/19330/
      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
      44109c60
    • Maciej W. Rozycki's avatar
      MIPS: Correct the 64-bit DSP accumulator register size · f5958b4c
      Maciej W. Rozycki authored
      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+
      f5958b4c
    • Maciej W. Rozycki's avatar
      binfmt_elf: Respect error return from `regset->active' · 2f819db5
      Maciej W. Rozycki authored
      The regset API documented in <linux/regset.h> defines -ENODEV as the
      result of the `->active' handler to be used where the feature requested
      is not available on the hardware found.  However code handling core file
      note generation in `fill_thread_core_info' interpretes any non-zero
      result from the `->active' handler as the regset requested being active.
      Consequently processing continues (and hopefully gracefully fails later
      on) rather than being abandoned right away for the regset requested.
      
      Fix the problem then by making the code proceed only if a positive
      result is returned from the `->active' handler.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@mips.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 4206d3aa ("elf core dump: notes user_regset")
      Patchwork: https://patchwork.linux-mips.org/patch/19332/
      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
      2f819db5
  5. 17 Jul, 2018 2 commits
    • Paul Burton's avatar
      MIPS: loongson64: cs5536: Fix PCI_OHCI_INT_REG reads · cd87668d
      Paul Burton authored
      The PCI_OHCI_INT_REG case in pci_ohci_read_reg() contains the following
      if statement:
      
        if ((lo & 0x00000f00) == CS5536_USB_INTR)
      
      CS5536_USB_INTR expands to the constant 11, which gives us the following
      condition which can never evaluate true:
      
        if ((lo & 0xf00) == 11)
      
      At least when using GCC 8.1.0 this falls foul of the tautoligcal-compare
      warning, and since the code is built with the -Werror flag the build
      fails.
      
      Fix this by shifting lo right by 8 bits in order to match the
      corresponding PCI_OHCI_INT_REG case in pci_ohci_write_reg().
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19861/
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      cd87668d
    • Alexander Sverdlin's avatar
      mips: unify prom_putchar() declarations · 5c93316c
      Alexander Sverdlin authored
      prom_putchar() is used centrally in early printk infrastructure therefore
      at least MIPS should agree on the function return type.
      
      [paul.burton@mips.com:
        - Include linux/types.h in asm/setup.h to gain the bool typedef before
          we start include asm/setup.h elsewhere.
        - Include asm/setup.h in all files that use or define prom_putchar().
        - Also standardise on signed rather than unsigned char argument.]
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19842/
      Cc: linux-mips@linux-mips.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Jonas Gorski <jonas.gorski@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      5c93316c
  6. 12 Jul, 2018 3 commits
    • Joshua Kinard's avatar
      MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h · 4936084c
      Joshua Kinard authored
      This patch reduces down the conditionals in MIPS atomic code that deal
      with a silicon bug in early R10000 cpus that required a workaround of
      a branch-likely instruction following a store-conditional in order to
      to guarantee the whole ll/sc sequence is atomic.  As the only real
      difference is a branch-likely instruction (beqzl) over a standard
      branch (beqz), the conditional is reduced down to a single preprocessor
      check at the top to pick the required instruction.
      
      This requires writing the uses in assembler, thus we discard the
      non-R10000 case that uses a mixture of a C do...while loop with
      embedded assembler that was added back in commit 7837314d ("MIPS:
      Get rid of branches to .subsections.").  A note found in the git log
      for commit 5999eca25c1f ("[MIPS] Improve branch prediction in ll/sc
      atomic operations.") is also addressed.
      
      The macro definition for the branch instruction and the code comment
      derives from a patch sent in earlier by Paul Burton for various cmpxchg
      cleanups.
      
      [paul.burton@mips.com:
        - Minor whitespace fix for checkpatch.]
      Signed-off-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/17736/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: "Maciej W. Rozycki" <macro@mips.com>
      Cc: linux-mips@linux-mips.org
      4936084c
    • Joshua Kinard's avatar
      MIPS: Fix delay slot bug in `atomic*_sub_if_positive' for R10000_LLSC_WAR · a0a5ac3c
      Joshua Kinard authored
      This patch fixes an old bug in MIPS ll/sc atomics, in the
      `atomic_sub_if_positive' and `atomic64_sub_if_positive' functions, for
      the R10000_LLSC_WAR case where the result of the subu/dsubu instruction
      would potentially not be made available to the sc/scd instruction due
      to being in the delay-slot of the branch-likely (beqzl) instruction.
      
      This also removes the need for the `noreorder' directive, allowing GAS
      to use delay slot scheduling as needed.
      
      The same fix is also applied to the standard branch (beqz) case in
      preparation for a follow-up patch that will cleanup/merge the
      R10000_LLSC_WAR and non-R10K sections together.
      Signed-off-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Tested-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Patchwork: https://patchwork.linux-mips.org/patch/17735/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: "Maciej W. Rozycki" <macro@mips.com>
      Cc: linux-mips@linux-mips.org
      a0a5ac3c
    • Thomas Bogendoerfer's avatar
      mips/jazz: provide missing dma_mask/coherent_dma_mask · b5d69129
      Thomas Bogendoerfer authored
      Commit 205e1b7f ("dma-mapping: warn when there is no
      coherent_dma_mask") introduced a warning, if a device is missing a
      coherent_dma_mask. ESP and sonic are using dma mapping functions, so
      they need dma masks.
      
      [paul.burton@mips.com:
        - Wrap commit message.]
      Signed-off-by: default avatarThomas Bogendoerfer <tbogendoerfer@suse.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19828/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      b5d69129
  7. 10 Jul, 2018 2 commits
    • Serge Semin's avatar
      mips: mm: Discard ioremap_uncached_accelerated() method · ddba595b
      Serge Semin authored
      Adaptive ioremap_wc() method is now available as of commit 9748e33e
      ("mips: mm: Create UCA-based ioremap_wc() method"). We can use it to
      obtain UnCached Accelerated (UCA) mappings safely on all MIPS systems,
      and so we don't need the MIPS-specific ioremap_uncached_accelerated()
      any longer. This macro hard-coded the UCA Cache Coherency Attribute
      (CCA) in a manner that isn't safe for kernels that may run on different
      CPUs, and it is also entirely unused so we can trivially remove it.
      
      [paul.burton@mips.com:
        - Reword the commit message a little.
        - Remove CC stable.]
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19790/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: okaya@codeaurora.org
      Cc: chenhc@lemote.com
      Cc: Sergey.Semin@t-platforms.ru
      Cc: linux-kernel@vger.kernel.org
      ddba595b
    • Serge Semin's avatar
      mips: mm: Create UCA-based ioremap_wc() method · 9748e33e
      Serge Semin authored
      Modern MIPS cores (like P5600/6600, M5150/6520, end so on) which
      got L2-cache on chip also can enable a special type Cache-Coherency
      attribute (CCA) named UnCached Accelerated attribute (UCA). In this
      way uncached accelerated accesses are treated the same way as
      non-accelerated uncached accesses, but uncached stores are gathered
      together for more efficient bus utilization. So to speak this CCA
      enables uncached transactions to better utilize bus bandwidth via
      burst transactions.
      
      This is exactly why ioremap_wc() method has been introduced in Linux.
      Alas MIPS-platform code hasn't implemented it so far, instead default
      one has been used which was an alias to ioremap_nocache. In order to
      fix this we added MIPS-specific ioremap_wc() macro substituted by
      generic __ioremap_mode() method call with writecombine CPU-info
      field passed. It shall create real ioremap_wc() method if CPU-cache
      supports UCA feature and fall-back to _CACHE_UNCACHED attribute
      if one doesn't. Additionally platform-specific io.h shall declare
      ARCH_HAS_IOREMAP_WC macro as indication of architectural definition
      of ioremap_wc() (similar to x86/powerpc).
      
      [paul.burton@mips.com:
        - Remove CC stable, this is new functionality.]
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19789/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: okaya@codeaurora.org
      Cc: chenhc@lemote.com
      Cc: Sergey.Semin@t-platforms.ru
      Cc: linux-kernel@vger.kernel.org
      9748e33e
  8. 03 Jul, 2018 6 commits
  9. 28 Jun, 2018 4 commits
    • Geert Uytterhoeven's avatar
      MIPS: AR7: Normalize clk API · 6b5939d2
      Geert Uytterhoeven authored
      Coldfire still provides its own variant of the clk API rather than using
      the generic COMMON_CLK API.  This generally works, but it causes some
      link errors with drivers using the clk_round_rate(), clk_set_rate(),
      clk_set_parent(), or clk_get_parent() functions when a platform lacks
      those interfaces.
      
      This adds empty stub implementations for each of them, and I don't even
      try to do something useful here but instead just print a WARN() message
      to make it obvious what is going on if they ever end up being called.
      
      The drivers that call these won't be used on these platforms (otherwise
      we'd get a link error today), so the added code is harmless bloat and
      will warn about accidental use.
      
      Based on commit bd7fefe1 ("ARM: w90x900: normalize clk API").
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19503/
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-mips@linux-mips.org
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      6b5939d2
    • Paul Burton's avatar
      MIPS: Always use -march=<arch>, not -<arch> shortcuts · 344ebf09
      Paul Burton authored
      The VDSO Makefile filters CFLAGS to select a subset which it uses whilst
      building the VDSO ELF. One of the flags it allows through is the -march=
      flag that selects the architecture/ISA to target.
      
      Unfortunately in cases where CONFIG_CPU_MIPS32_R{1,2}=y and the
      toolchain defaults to building for MIPS64, the main MIPS Makefile ends
      up using the short-form -<arch> flags in cflags-y. This is because the
      calls to cc-option always fail to use the long-form -march=<arch> flag
      due to the lack of an -mabi=<abi> flag in KBUILD_CFLAGS at the point
      where the cc-option function is executed. The resulting GCC invocation
      is something like:
      
        $ mips64-linux-gcc -Werror -march=mips32r2 -c -x c /dev/null -o tmp
        cc1: error: '-march=mips32r2' is not compatible with the selected ABI
      
      These short-form -<arch> flags are dropped by the VDSO Makefile's
      filtering, and so we attempt to build the VDSO without specifying any
      architecture. This results in an attempt to build the VDSO using
      whatever the compiler's default architecture is, regardless of whether
      that is suitable for the kernel configuration.
      
      One encountered build failure resulting from this mismatch is a
      rejection of the sync instruction if the kernel is configured for a
      MIPS32 or MIPS64 r1 or r2 target but the toolchain defaults to an older
      architecture revision such as MIPS1 which did not include the sync
      instruction:
      
          CC      arch/mips/vdso/gettimeofday.o
        /tmp/ccGQKoOj.s: Assembler messages:
        /tmp/ccGQKoOj.s:273: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:329: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:520: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:714: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1009: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1066: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1114: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1279: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1334: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1374: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1459: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1514: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:1814: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:2002: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        /tmp/ccGQKoOj.s:2066: Error: opcode not supported on this processor: mips1 (mips1) `sync'
        make[2]: *** [scripts/Makefile.build:318: arch/mips/vdso/gettimeofday.o] Error 1
        make[1]: *** [scripts/Makefile.build:558: arch/mips/vdso] Error 2
        make[1]: *** Waiting for unfinished jobs....
      
      This can be reproduced for example by attempting to build
      pistachio_defconfig using Arnd's GCC 8.1.0 mips64 toolchain from
      kernel.org:
      
        https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips64-linux.tar.xz
      
      Resolve this problem by using the long-form -march=<arch> in all cases,
      which makes it through the arch/mips/vdso/Makefile's filtering & is thus
      consistently used to build both the kernel proper & the VDSO.
      
      The use of cc-option to prefer the long-form & fall back to the
      short-form flags makes no sense since the short-form is just an
      abbreviation for the also-supported long-form in all GCC versions that
      we support building with. This means there is no case in which we have
      to use the short-form -<arch> flags, so we can simply remove them.
      
      The manual redefinition of _MIPS_ISA is removed naturally along with the
      use of the short-form flags that it accompanied, and whilst here we
      remove the separate assembler ISA selection. I suspect that both of
      these were only required due to the mips32 vs mips2 mismatch that was
      introduced by commit 59b3e8e9 ("[MIPS] Makefile crapectomy.") and
      fixed but not cleaned up by commit 9200c0b2 ("[MIPS] Fix Makefile
      bugs for MIPS32/MIPS64 R1 and R2.").
      
      I've marked this for backport as far as v4.4 where the MIPS VDSO was
      introduced. In earlier kernels there should be no ill effect to using
      the short-form flags.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org # v4.4+
      Reviewed-by: default avatarJames Hogan <jhogan@kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/19579/
      344ebf09
    • Joe Perches's avatar
      MIPS: ath25: Convert random_ether_addr to eth_random_addr · 8e5c88bf
      Joe Perches authored
      random_ether_addr is a #define for eth_random_addr which is
      generally preferred in kernel code by ~3:1
      
      Convert the uses of random_ether_addr to enable removing the #define
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19600/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      8e5c88bf
    • Paul Burton's avatar
      MIPS: Annotate cpu_wait implementations with __cpuidle · 97c8580e
      Paul Burton authored
      Annotate cpu_wait implementations using the __cpuidle macro which
      places these functions in the .cpuidle.text section. This allows
      cpu_in_idle() to return true for PC values which fall within these
      functions, allowing nmi_backtrace() to produce cleaner output for CPUs
      running idle functions. For example:
      
        # echo l >/proc/sysrq-trigger
        [   38.587170] sysrq: SysRq : Show backtrace of all active CPUs
        [   38.593657] NMI backtrace for cpu 1
        [   38.597611] CPU: 1 PID: 161 Comm: sh Not tainted 4.18.0-rc1+ #27
        [   38.604306] Stack : 00000000 00000004 00000006 80486724 00000000 00000000 00000000 00000000
        [   38.613647]         80e17eda 00000034 00000000 00000000 80d20000 80b67e98 8e559c90 0ffe1e88
        [   38.622986]         00000000 00000000 80e70000 00000000 8f61db18 38312e34 722d302e 202b3163
        [   38.632324]         8e559d3c 8e559adc 00000001 6b636162 80d20000 80000000 00000000 80d1cfa4
        [   38.641664]         00000001 80d20000 80d19520 00000000 00000003 80836724 00000004 80e10004
        [   38.650993]         ...
        [   38.653724] Call Trace:
        [   38.656499] [<8040cdd0>] show_stack+0xa0/0x144
        [   38.661475] [<80b67e98>] dump_stack+0xe8/0x120
        [   38.666455] [<80b6f6d4>] nmi_cpu_backtrace+0x1b4/0x1cc
        [   38.672189] [<80b6f81c>] nmi_trigger_cpumask_backtrace+0x130/0x1e4
        [   38.679081] [<808295d8>] __handle_sysrq+0xc0/0x180
        [   38.684421] [<80829b84>] write_sysrq_trigger+0x50/0x64
        [   38.690176] [<8061c984>] proc_reg_write+0xd0/0xfc
        [   38.695447] [<805aac1c>] __vfs_write+0x54/0x194
        [   38.700500] [<805aaf24>] vfs_write+0xe0/0x18c
        [   38.705360] [<805ab190>] ksys_write+0x7c/0xf0
        [   38.710238] [<80416018>] syscall_common+0x34/0x58
        [   38.715558] Sending NMI from CPU 1 to CPUs 0,2-3:
        [   38.720916] NMI backtrace for cpu 0 skipped: idling at r4k_wait_irqoff+0x2c/0x34
        [   38.729186] NMI backtrace for cpu 3 skipped: idling at r4k_wait_irqoff+0x2c/0x34
        [   38.737449] NMI backtrace for cpu 2 skipped: idling at r4k_wait_irqoff+0x2c/0x34
      
      Without this we get register value & backtrace output from all CPUs,
      which is generally useless for those running the idle function & serves
      only to overwhelm & obfuscate the meaningful output from non-idle CPUs.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      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
      Patchwork: https://patchwork.linux-mips.org/patch/19598/
      97c8580e
  10. 24 Jun, 2018 11 commits
    • Rickard Strandqvist's avatar
      arch: mips: mm: page: Remove unused function · 829caee7
      Rickard Strandqvist authored
      Remove the function sb1_dma_init() that is not used anywhere.
      
      This was partially found by using a static code analysis program called cppcheck.
      Signed-off-by: default avatarRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Patchwork: https://patchwork.linux-mips.org/patch/8873/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: John Crispin <blogic@openwrt.org>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      829caee7
    • Rickard Strandqvist's avatar
      arch: mips: pci: pci-ip27.c: Remove unused function · ff404a93
      Rickard Strandqvist authored
      Remove the function pci_enable_swapping() that is not used anywhere.
      
      This was partially found by using a static code analysis program called cppcheck.
      Signed-off-by: default avatarRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Patchwork: https://patchwork.linux-mips.org/patch/8867/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: John Crispin <blogic@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      ff404a93
    • Paul Burton's avatar
      MIPS: Malta: Use PIIX4 poweroff driver to power down · dd129c63
      Paul Burton authored
      Remove the platform code used to power down the system, instead relying
      upon the new PIIX4 poweroff driver. This reduces the amount of platform
      code required for the Malta board in preparation for allowing it to be
      part of a more generic kernel.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/14282/
      dd129c63
    • Paul Burton's avatar
      MIPS: Malta: Cleanup DMA coherence #ifdefs · a07539c0
      Paul Burton authored
      DMA coherence is not user-selectable in Kconfig, and Malta selects
      CONFIG_DMA_MAYBE_COHERENT which in turn selects CONFIG_DMA_NONCOHERENT.
      Remove #ifdefs whose conditions can therefore never be true for Malta.
      
      This removes a significant amount of code from bonito_quirks_setup(),
      but the code is duplicated in plat_enable_iocoherency() anyway so we
      lose nothing but duplication.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/14188/
      a07539c0
    • Paul Burton's avatar
      MIPS: Set MIPS_IC_SNOOPS_REMOTE for systems with CM · d1c5872c
      Paul Burton authored
      In systems that include a MIPS Coherency Manager, the icache always
      fills from a cache which is coherent across all CPUs. In I6400 & I6500
      systems the icache fills from the dcache which is coherent across all
      CPUs. In all other CM-based systems the icache fills from the L2 cache
      which is shared between all cores.
      
      This means that an icache will always see stores from remote CPUs
      without needing to write them back any further than that L2, which is
      what the cpu_icache_snoops_remote_store feature is used to test. In
      order for it to return 1 without needing a per-platform override (which
      is what Malta has relied upon so far) set the MIPS_IC_SNOOPS_REMOTE flag
      when a CM is present.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16200/
      d1c5872c
    • Joshua Kinard's avatar
      MIPS: Use !pci_is_root_bus(bus) in ops-bridge.c · 8fd2d6ea
      Joshua Kinard authored
      This is a manual cherrypick of commit c7ddc3d137b7 from Alastair
      Bridgewater's IP35 tree that replaces two cases of
      "if (bus->number > 0)" with a more correct "if (!pci_is_root_bus(bus))"
      in arch/mips/pci/ops-bridge.c.
      
      Cc: linux-mips@linux-mips.org
      Cc: Alastair Bridgewater <alastair.bridgewater@gmail.com>
      Suggested-by: default avatarAlastair Bridgewater <alastair.bridgewater@gmail.com>
      Signed-off-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Patchwork: https://patchwork.linux-mips.org/patch/17501/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Linux/MIPS <linux-mips@linux-mips.org>
      8fd2d6ea
    • Paul Burton's avatar
      MIPS: Schedule on CPUs we need to lose FPU for a mode switch · 8c8d953c
      Paul Burton authored
      Commit 6b832257 ("MIPS: Force CPUs to lose FP context during mode
      switches") ensures that we react to PR_SET_FP_MODE prctl syscalls
      quickly by broadcasting an IPI in order to cause CPUs to lose FPU access
      when necessary. Whilst it achieves that, unfortunately it causes all
      sorts of strange race conditions because:
      
       1) The IPI may arrive at a point where the FPU is in the process of
          being enabled, but that process is not yet complete leading to a
          state we aren't prepared to handle. For example:
      
          [  370.215903] do_cpu invoked from kernel context![#1]:
          [  370.221064] CPU: 0 PID: 963 Comm: fp-prctl Not tainted 4.9.0-rc5-00323-g210db32-dirty #226
          [  370.229420] task: a8000000fd672e00 task.stack: a8000000fd630000
          [  370.235399] $ 0   : 0000000000000000 0000000000000001 0000000000000001 a8000000fd630000
          [  370.243882] $ 4   : a8000000fd672e00 0000000000000000 0000000000000453 0000000000000000
          [  370.252317] $ 8   : 0000000000000000 a8000000fd637c28 1000000000000000 0000000000000010
          [  370.260753] $12   : 00000000140084e0 ffffffff80109c00 0000000000000000 0000000000000002
          [  370.269179] $16   : ffffffff8092f080 a8000000fd672e00 ffffffff80107fe8 a8000000fd485000
          [  370.277612] $20   : ffffffff8084d328 ffffffff80940000 0000000000000009 ffffffff80930000
          [  370.286038] $24   : 0000000000000000 900000001612048c
          [  370.294476] $28   : a8000000fd630000 a8000000fd637ac0 ffffffff80937300 ffffffff8010807c
          [  370.302909] Hi    : 0000000000000000
          [  370.306595] Lo    : 0000000000000200
          [  370.310376] epc   : ffffffff80115d38 _save_fp+0x10/0xa0
          [  370.315784] ra    : ffffffff8010807c prepare_for_fp_mode_switch+0x94/0x1b0
          [  370.322707] Status: 140084e2 KX SX UX KERNEL EXL
          [  370.327980] Cause : 1080002c (ExcCode 0b)
          [  370.332091] PrId  : 0001a428 (MIPS P6600)
          [  370.336179] Modules linked in:
          [  370.339486] Process fp-prctl (pid: 963, threadinfo=a8000000fd630000, task=a8000000fd672e00, tls=00000000756e67d0)
          [  370.349724] Stack : 0000000000000000 a8000000fd557dc0 0000000000000000 ffffffff801ca8e0
          [  370.358161]         0000000000000000 a8000000fd637b9c 0000000000000009 ffffffff80923780
          [  370.366575]         ffffffff80850000 ffffffff8011610c 00000000000000b8 ffffffff801a5084
          [  370.374989]         ffffffff8084a370 ffffffff8084a388 ffffffff80923780 ffffffff80923828
          [  370.383395]         0000000000010000 ffffffff809237a8 0000000000020000 ffffffff80a40000
          [  370.391817]         000000000000007c 00000000004a0000 00000000756dedd0 ffffffff801a5188
          [  370.400230]         a800000002014900 0000000000000001 ffffffff80923780 0000000080923828
          [  370.408644]         ffffffff80923780 ffffffff80923780 ffffffff80923828 ffffffff801a521c
          [  370.417066]         ffffffff80923780 ffffffff80923828 0000000000010000 ffffffff801a8f84
          [  370.425472]         ffffffff80a40000 a8000000fd637c20 ffffffff80a39240 0000000000000001
          [  370.433885]         ...
          [  370.436562] Call Trace:
          [  370.439222] [<ffffffff80115d38>] _save_fp+0x10/0xa0
          [  370.444305] [<ffffffff8010807c>] prepare_for_fp_mode_switch+0x94/0x1b0
          [  370.451035] [<ffffffff801ca8e0>] flush_smp_call_function_queue+0xf8/0x230
          [  370.457991] [<ffffffff8011610c>] ipi_call_interrupt+0xc/0x20
          [  370.463814] [<ffffffff801a5084>] __handle_irq_event_percpu+0xc4/0x1a8
          [  370.470404] [<ffffffff801a5188>] handle_irq_event_percpu+0x20/0x68
          [  370.476734] [<ffffffff801a521c>] handle_irq_event+0x4c/0x88
          [  370.482486] [<ffffffff801a8f84>] handle_edge_irq+0x12c/0x210
          [  370.488316] [<ffffffff801a47a0>] generic_handle_irq+0x38/0x48
          [  370.494280] [<ffffffff804a2dbc>] gic_handle_shared_int+0x194/0x268
          [  370.500616] [<ffffffff801a47a0>] generic_handle_irq+0x38/0x48
          [  370.506529] [<ffffffff80107e60>] do_IRQ+0x18/0x28
          [  370.511445] [<ffffffff804a1524>] plat_irq_dispatch+0xc4/0x140
          [  370.517339] [<ffffffff80106230>] ret_from_irq+0x0/0x4
          [  370.522583] [<ffffffff8010fad4>] do_ri+0x4fc/0x7e8
          [  370.527546] [<ffffffff80106220>] ret_from_exception+0x0/0x10
      
       2) The IPI may arrive during kernel use of the FPU, since we generally
          only disable preemption around use of the FPU & leave interrupts
          enabled. This can lead to us unexpectedly losing access to the FPU
          in places where it previously had not been possible. For example:
      
          do_cpu invoked from kernel context![#2]:
          CPU: 2 PID: 7338 Comm: fp-prctl Tainted: G      D         4.7.0-00424-g49b0c82
          #2
          task: 838e4000 ti: 88d38000 task.ti: 88d38000
          $ 0   : 00000000 00000001 ffffffff 88d3fef8
          $ 4   : 838e4000 88d38004 00000000 00000001
          $ 8   : 3400fc01 801f8020 808e9100 24000000
          $12   : dbffffff 807b69d8 807b0000 00000000
          $16   : 00000000 80786150 00400fc4 809c0398
          $20   : 809c0338 0040273c 88d3ff28 808e9d30
          $24   : 808e9d30 00400fb4
          $28   : 88d38000 88d3fe88 00000000 8011a2ac
          Hi    : 0040273c
          Lo    : 88d3ff28
          epc   : 80114178 _restore_fp+0x10/0xa0
          ra    : 8011a2ac mipsr2_decoder+0xd5c/0x1660
          Status: 1400fc03    KERNEL EXL IE
          Cause : 1080002c (ExcCode 0b)
          PrId  : 0001a920 (MIPS I6400)
          Modules linked in:
          Process fp-prctl (pid: 7338, threadinfo=88d38000, task=838e4000, tls=766527d0)
          Stack : 00000000 00000000 00000000 88d3fe98 00000000 00000000 809c0398 809c0338
                808e9100 00000000 88d3ff28 00400fc4 00400fc4 0040273c 7fb69e18 004a0000
                004a0000 004a0000 7664add0 8010de18 00000000 00000000 88d3fef8 88d3ff28
                808e9100 00000000 766527d0 8010e534 000c0000 85755000 8181d580 00000000
                00000000 00000000 004a0000 00000000 766527d0 7fb69e18 004a0000 80105c20
                ...
          Call Trace:
          [<80114178>] _restore_fp+0x10/0xa0
          [<8011a2ac>] mipsr2_decoder+0xd5c/0x1660
          [<8010de18>] do_ri+0x90/0x6b8
          [<80105c20>] ret_from_exception+0x0/0x10
      
      At first glance a simple fix may seem to be to disable interrupts around
      kernel use of the FPU rather than merely preemption, however this would
      introduce further overhead outside of the mode switch path & doesn't
      solve the third problem:
      
       3) The IPI may arrive whilst the kernel is running code that will lead
          to a preempt_disable() call & FPU usage soon. If this happens then
          the IPI will be serviced & we'll proceed to enable an FPU whilst the
          mode switch is in progress, leading to strange & inconsistent
          behaviour.
      
      Further to all of this is a separate but related problem:
      
       4) There are various paths through which we may enable the FPU without
          the user having triggered a coprocessor 1 disabled exception. These
          paths are those in which we emulate instructions & then enable the
          FPU with the expectation that the user might execute an FP
          instruction shortly afterwards. However these paths have not
          previously checked whether an FP mode switch is underway for the
          task, and therefore could enable the FPU whilst such a mode switch
          is in progress leading to strange & inconsistent behaviour for user
          code.
      
      This patch fixes all of the above by taking a step back & re-examining
      our approach to FP mode switches. Up until now we have taken these basic
      steps:
      
       a) Prevent any threads that are part of the affected process from being
          able to obtain ownership of the FPU.
      
       b) Cause any threads that are part of the affected process and already
          have ownership of an FPU to lose it.
      
       c) Set the thread flags for each thread that is part of the affected
          process to reflect the new FP mode.
      
       d) Allow threads to obtain ownership of the FPU again.
      
      This approach is however more complex than necessary. All that we really
      require is that the mode switch has occurred for all threads that are
      part of the affected process before mips_set_process_fp_mode(), and thus
      the PR_SET_FP_MODE prctl() syscall, returns. This doesn't require that
      we stop threads from owning or using an FPU whilst a mode switch occurs,
      only that we force them to relinquish it after the mode switch has
      occurred such that they next own an FPU with the correct mode
      configured. Our basic steps therefore simplify to:
      
       A) Set the thread flags for each thread that is part of the affected
          process to reflect the new FP mode.
      
       B) Cause any threads that are part of the affected process and already
          have ownership of an FPU to lose it.
      
      We implement B) by forcing each CPU which might be running a thread
      which is part of the affected process to schedule a no-op function,
      which causes the affected thread to lose its FPU ownership when it is
      descheduled.
      
      The end result is simpler FP mode switching with less overhead in the
      FPU enable path (ie. enable_restore_fp_context()) and fewer moving
      parts.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
      Fixes: 6b832257 ("MIPS: Force CPUs to lose FP context during mode switches")
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: stable <stable@vger.kernel.org> # v4.0+
      8c8d953c
    • Rob Herring's avatar
      MIPS: lantiq: remove unnecessary of_platform_default_populate call · 9667bb03
      Rob Herring authored
      The DT core will call of_platform_default_populate, so it is not necessary
      for arch specific code to call it unless there are custom match entries,
      auxdata or parent device. Neither of those apply here, so remove the call.
      
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/19592/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-kernel@vger.kernel.org
      9667bb03
    • Rob Herring's avatar
      MIPS: generic: remove unnecessary of_platform_populate call · 6a7ec6c5
      Rob Herring authored
      The DT core will call of_platform_populate, so it is not necessary for
      arch specific code to call it unless there are custom match entries,
      auxdata or parent device. Neither of those apply here, so remove the call.
      
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/19591/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-kernel@vger.kernel.org
      6a7ec6c5
    • Rob Herring's avatar
      MIPS: bmips: remove unnecessary call to register "simple-bus" · 0279455f
      Rob Herring authored
      The DT core will register "simple-bus" by default, so it is not necessary
      for arch specific code to do so unless there are custom match entries,
      auxdata or parent device. Neither of those apply here, so remove the call.
      
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/19590/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-kernel@vger.kernel.org
      0279455f
    • Rob Herring's avatar
      MIPS: netlogic: remove unnecessary of_platform_bus_probe call · 40c911ed
      Rob Herring authored
      The DT core code will probe "simple-bus" by default, so remove
      the Netlogic specific call. The probing of simple-bus happens at
      arch_initcall_sync, so the call being removed here is already a nop.
      
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/19589/Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: linux-kernel@vger.kernel.org
      40c911ed