1. 21 Aug, 2018 2 commits
    • Paul Burton's avatar
      MIPS: Workaround GCC __builtin_unreachable reordering bug · 906d441f
      Paul Burton authored
      Some versions of GCC for the MIPS architecture suffer from a bug which
      can lead to instructions from beyond an unreachable statement being
      incorrectly reordered into earlier branch delay slots if the unreachable
      statement is the only content of a case in a switch statement. This can
      lead to seemingly random behaviour, such as invalid memory accesses from
      incorrectly reordered loads or stores, and link failures on microMIPS
      builds.
      
      See this potential GCC fix for details:
      
          https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
      
      Runtime problems resulting from this bug were initially observed using a
      maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
      SDK 2015.06-05 toolchain), with the result being an address exception
      taken after log messages about the L1 caches (during probe of the L2
      cache):
      
          Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
          VPE topology {2,2} total 4
          Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
          Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
          <AdEL exception here>
      
      This is early enough that the kernel exception vectors are not in use,
      so any further output depends upon the bootloader. This is reproducible
      in QEMU where no further output occurs - ie. the system hangs here.
      Given the nature of the bug it may potentially be hit with differing
      symptoms. The bug is known to affect GCC versions as recent as 7.3, and
      it is unclear whether GCC 8 fixed it or just happens not to encounter
      the bug in the testcase found at the link above due to differing
      optimizations.
      
      This bug can be worked around by placing a volatile asm statement, which
      GCC is prevented from reordering past, prior to the
      __builtin_unreachable call.
      
      That was actually done already for other reasons by commit 173a3efd
      ("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
      microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
      allows for interlinking with regular MIPS32 code by repurposing bit 0 of
      the program counter as an ISA mode bit. To switch modes one changes the
      value of this bit in the PC. However typical branch instructions encode
      their offsets as multiples of 2-byte instruction halfwords, which means
      they cannot change ISA mode - this must be done using either an indirect
      branch (a jump-register in MIPS terminology) or a dedicated jalx
      instruction. In order to ensure that regular branches don't attempt to
      target code in a different ISA which they can't actually switch to, the
      linker will check that branch targets are code in the same ISA as the
      branch.
      
      Unfortunately our empty asm volatile statements don't qualify as code,
      and the link for microMIPS builds fails with errors such as:
      
          arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
          arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode
      
      Resolve this by adding a .insn directive within the asm statement which
      declares that what comes next is code. This may or may not be true,
      since we don't really know what comes next, but as this code is in an
      unreachable path anyway that doesn't matter since we won't execute it.
      
      We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
      order to have this included by linux/compiler_types.h after
      linux/compiler-gcc.h. This will result in asm/compiler.h being included
      in all C compilations via the -include linux/compiler_types.h argument
      in c_flags, which should be harmless.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: 173a3efd ("bug.h: work around GCC PR82365 in BUG()")
      Patchwork: https://patchwork.linux-mips.org/patch/20270/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-mips@linux-mips.org
      906d441f
    • Paul Burton's avatar
      compiler.h: Allow arch-specific asm/compiler.h · 04f264d3
      Paul Burton authored
      We have a need to override the definition of
      barrier_before_unreachable() for MIPS, which means we either need to add
      architecture-specific code into linux/compiler-gcc.h or we need to allow
      the architecture to provide a header that can define the macro before
      the generic definition. The latter seems like the better approach.
      
      A straightforward approach to the per-arch header is to make use of
      asm-generic to provide a default empty header & adjust architectures
      which don't need anything specific to make use of that by adding the
      header to generic-y. Unfortunately this doesn't work so well due to
      commit 28128c61 ("kconfig.h: Include compiler types to avoid missed
      struct attributes") which caused linux/compiler_types.h to be included
      in the compilation of every C file via the -include linux/kconfig.h flag
      in c_flags.
      
      Because the -include flag is present for all C files we compile, we need
      the architecture-provided header to be present before any C files are
      compiled. If any C files can be compiled prior to the asm-generic header
      wrappers being generated then we hit a build failure due to missing
      header. Such cases do exist - one pointed out by the kbuild test robot
      is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
      of the archprepare target [1].
      
      This leaves us with a few options:
      
        1) Use generic-y & fix any build failures we find by enforcing
           ordering such that the asm-generic target occurs before any C
           compilation, such that linux/compiler_types.h can always include
           the generated asm-generic wrapper which in turn includes the empty
           asm-generic header. This would rely on us finding all the
           problematic cases - I don't know for sure that the ia64 issue is
           the only one.
      
        2) Add an actual empty header to each architecture, so that we don't
           need the generated asm-generic wrapper. This seems messy.
      
        3) Give up & add #ifdef CONFIG_MIPS or similar to
           linux/compiler_types.h. This seems messy too.
      
        4) Include the arch header only when it's actually needed, removing
           the need for the asm-generic wrapper for all other architectures.
      
      This patch allows us to use approach 4, by including an asm/compiler.h
      header from linux/compiler_types.h after the inclusion of the
      compiler-specific linux/compiler-*.h header(s). We do this
      conditionally, only when CONFIG_HAVE_ARCH_COMPILER_H is selected, in
      order to avoid the need for asm-generic wrappers & the associated build
      ordering issue described above. The asm/compiler.h header is included
      after the generic linux/compiler-*.h header(s) for consistency with the
      way linux/compiler-intel.h & linux/compiler-clang.h are included after
      the linux/compiler-gcc.h header that they override.
      
      [1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.htmlSigned-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20269/
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kbuild@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      04f264d3
  2. 17 Aug, 2018 1 commit
    • Paul Burton's avatar
      MIPS: Avoid move psuedo-instruction whilst using MIPS_ISA_LEVEL · cfd54de3
      Paul Burton authored
      MIPS_ISA_LEVEL is always defined as the 64 bit ISA that is a compatible
      superset of the ISA that the kernel build is targeting, and is used to
      allow us to emit instructions that we may detect support for at runtime.
      
      When we use a .set MIPS_ISA_LEVEL directive & are building a 32-bit
      kernel, we therefore are temporarily allowing the assembler to generate
      MIPS64 instructions. Using the move pseudo-instruction whilst this is
      the case is problematic because the assembler is likely to emit a daddu
      instruction which will generate a reserved instruction exception when
      executed on a MIPS32 machine.
      
      Unfortunately the combination of commit a0a5ac3c ("MIPS: Fix delay
      slot bug in `atomic*_sub_if_positive' for R10000_LLSC_WAR") and commit
      4936084c ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h") causes
      us to do exactly this in atomic_sub_if_positive(), and the result is
      MIPS64 daddu instructions in 32-bit kernels.
      
      Fix this by using .set mips0 to restore the default ISA after the ll
      instruction, and use .set MIPS_ISA_LEVEL again prior to the sc. This
      ensures everything but the ll & sc are assembled using the default ISA
      for the kernel build & the move pseudo-instruction is emitted as a
      MIPS32 addu instruction.
      
      We appear to have another pre-existing instance of the same issue in our
      atomic_fetch_*_relaxed() functions, and fix that up too by moving our
      .set move0 such that it occurs prior to use of the move
      pseudo-instruction.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: a0a5ac3c ("MIPS: Fix delay slot bug in `atomic*_sub_if_positive' for R10000_LLSC_WAR")
      Fixes: 4936084c ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
      Patchwork: https://patchwork.linux-mips.org/patch/20253/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      cfd54de3
  3. 11 Aug, 2018 2 commits
    • Paul Burton's avatar
      MIPS: Consistently declare TLB functions · 4bcb4ad6
      Paul Burton authored
      Since at least the beginning of the git era we've declared our TLB
      exception handling functions inconsistently. They're actually functions,
      but we declare them as arrays of u32 where each u32 is an encoded
      instruction. This has always been the case for arch/mips/mm/tlbex.c, and
      has also been true for arch/mips/kernel/traps.c since commit
      86a1708a ("MIPS: Make tlb exception handler definitions and
      declarations match.") which aimed for consistency but did so by
      consistently making the our C code inconsistent with our assembly.
      
      This is all usually harmless, but when using GCC 7 or newer to build a
      kernel targeting microMIPS (ie. CONFIG_CPU_MICROMIPS=y) it becomes
      problematic. With microMIPS bit 0 of the program counter indicates the
      ISA mode. When bit 0 is zero instructions are decoded using the standard
      MIPS32 or MIPS64 ISA. When bit 0 is one instructions are decoded using
      microMIPS. This means that function pointers become odd - their least
      significant bit is one for microMIPS code. We work around this in cases
      where we need to access code using loads & stores with our
      msk_isa16_mode() macro which simply clears bit 0 of the value it is
      given:
      
        #define msk_isa16_mode(x) ((x) & ~0x1)
      
      For example we do this for our TLB load handler in
      build_r4000_tlb_load_handler():
      
        u32 *p = (u32 *)msk_isa16_mode((ulong)handle_tlbl);
      
      We then write code to p, expecting it to be suitably aligned (our LEAF
      macro aligns functions on 4 byte boundaries, so (ulong)handle_tlbl will
      give a value one greater than a multiple of 4 - ie. the start of a
      function on a 4 byte boundary, with the ISA mode bit 0 set).
      
      This worked fine up to GCC 6, but GCC 7 & onwards is smart enough to
      presume that handle_tlbl which we declared as an array of u32s must be
      aligned sufficiently that bit 0 of its address will never be set, and as
      a result optimize out msk_isa16_mode(). This leads to p having an
      address with bit 0 set, and when we go on to attempt to store code at
      that address we take an address error exception due to the unaligned
      memory access.
      
      This leads to an exception prior to the kernel having configured its own
      exception handlers, so we jump to whatever handlers the bootloader
      configured. In the case of QEMU this results in a silent hang, since it
      has no useful general exception vector.
      
      Fix this by consistently declaring our TLB-related functions as
      functions. For handle_tlbl(), handle_tlbs() & handle_tlbm() we do this
      in asm/tlbex.h & we make use of the existing declaration of
      tlbmiss_handler_setup_pgd() in asm/mmu_context.h. Our TLB handler
      generation code in arch/mips/mm/tlbex.c is adjusted to deal with these
      definitions, in most cases simply by casting the function pointers to
      u32 pointers.
      
      This allows us to include asm/mmu_context.h in arch/mips/mm/tlbex.c to
      get the definitions of tlbmiss_handler_setup_pgd & pgd_current, removing
      some needless duplication. Consistently using msk_isa16_mode() on
      function pointers means we no longer need the
      tlbmiss_handler_setup_pgd_start symbol so that is removed entirely.
      
      Now that we're declaring our functions as functions GCC stops optimizing
      out msk_isa16_mode() & a microMIPS kernel built with either GCC 7.3.0 or
      8.1.0 boots successfully.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      4bcb4ad6
    • Paul Burton's avatar
      MIPS: Export tlbmiss_handler_setup_pgd near its definition · b29fea36
      Paul Burton authored
      We export tlbmiss_handler_setup_pgd in arch/mips/mm/tlbex.c close to a
      declaration of it, rather than close to its definition as is standard.
      
      We've supported exporting symbols in assembly code since commit
      22823ab4 ("EXPORT_SYMBOL() for asm"), so move the export to follow
      the function's (stub) definition.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      b29fea36
  4. 09 Aug, 2018 1 commit
  5. 08 Aug, 2018 1 commit
    • Paul Burton's avatar
      MIPS: netlogic: xlr: Remove erroneous check in nlm_fmn_send() · 02eec6c9
      Paul Burton authored
      In nlm_fmn_send() we have a loop which attempts to send a message
      multiple times in order to handle the transient failure condition of a
      lack of available credit. When examining the status register to detect
      the failure we check for a condition that can never be true, which falls
      foul of gcc 8's -Wtautological-compare:
      
        In file included from arch/mips/netlogic/common/irq.c:65:
        ./arch/mips/include/asm/netlogic/xlr/fmn.h: In function 'nlm_fmn_send':
        ./arch/mips/include/asm/netlogic/xlr/fmn.h:304:22: error: bitwise
          comparison always evaluates to false [-Werror=tautological-compare]
           if ((status & 0x2) == 1)
                              ^~
      
      If the path taken if this condition were true all we do is print a
      message to the kernel console. Since failures seem somewhat expected
      here (making the console message questionable anyway) and the condition
      has clearly never evaluated true we simply remove it, rather than
      attempting to fix it to check status correctly.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20174/
      Cc: Ganesan Ramalingam <ganesanr@broadcom.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Jayachandran C <jnair@caviumnetworks.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      02eec6c9
  6. 07 Aug, 2018 5 commits
    • Paul Burton's avatar
      MIPS: VDSO: Force link endianness · 2f002567
      Paul Burton authored
      When building the VDSO with clang it appears to invoke ld without
      specifying endianness, even though clang itself was provided with a -EB
      or -EL flag. This results in the build failing due to a mismatch between
      the objects that are the input to ld, and the output it is attempting to
      create:
      
        VDSO    arch/mips/vdso/vdso.so.dbg.raw
        mips-linux-ld: arch/mips/vdso/elf.o: compiled for a big endian system
          and target is little endian
        mips-linux-ld: arch/mips/vdso/elf.o: endianness incompatible with that
          of the selected emulation
        mips-linux-ld: failed to merge target specific data of file
          arch/mips/vdso/elf.o
        ...
      
      Work around this problem by explicitly specifying the link endianness
      using -Wl,-EB or -Wl,-EL when -EB or -EL are part of KBUILD_CFLAGS. This
      resolves the build failure when using clang, and doesn't have any
      negative effect on gcc.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      2f002567
    • Paul Burton's avatar
      MIPS: Always specify -EB or -EL when using clang · c6d6f4c5
      Paul Burton authored
      When building using clang, always specify -EB or -EL in order to ensure
      we target the desired endianness.
      
      Since clang cross compiles using a single compiler build with multiple
      targets, our -dumpmachine tests which don't specify clang's --target
      argument check output based upon the build machine rather than the
      machine our build will target. This means our detection of whether to
      specify -EB fails miserably & we never do. Providing the endianness flag
      unconditionally for clang resolves this issue & simplifies the clang
      path somewhat.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      c6d6f4c5
    • Paul Burton's avatar
      MIPS: Use dins to simplify __write_64bit_c0_split() · 36dc5b20
      Paul Burton authored
      The code in __write_64bit_c0_split() is used by MIPS32 kernels running
      on MIPS64 CPUs to write a 64-bit value to a 64-bit coprocessor 0
      register using a single 64-bit dmtc0 instruction. It does this by
      combining the 2x 32-bit registers used to hold the 64-bit value into a
      single register, which in the existing code involves three steps:
      
        1) Zero extend register A which holds bits 31:0 of our data, since it
           may have previously held a sign-extended value.
      
        2) Shift register B which holds bits 63:32 of our data in bits 31:0
           left by 32 bits, such that the bits forming our data are in the
           position they'll be in the final 64-bit value & bits 31:0 of the
           register are zero.
      
        3) Or the two registers together to form the 64-bit value in one
           64-bit register.
      
      From MIPS r2 onwards we have a dins instruction which can effectively
      perform all 3 of those steps using a single instruction.
      
      Add a path for MIPS r2 & beyond which uses dins to take bits 31:0 from
      register B & insert them into bits 63:32 of register A, giving us our
      full 64-bit value in register A with one instruction.
      
      Since we know that MIPS r2 & above support the sel field for the dmtc0
      instruction, we don't bother special casing sel==0. Omiting the sel
      field would assemble to exactly the same instruction as when we
      explicitly specify that it equals zero.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      36dc5b20
    • Paul Burton's avatar
      MIPS: Use read-write output operand in __write_64bit_c0_split() · 08eeb44b
      Paul Burton authored
      Commit c22c8043 ("MIPS: Fix input modify in
      __write_64bit_c0_split()") modified __write_64bit_c0_split() constraints
      such that we have both an input & an output which we hope to assign to
      the same registers, and modify the output rather than incorrectly
      clobbering an input.
      
      The way in which we use both an output & an input parameter with the
      input constrained to share the output registers is a little convoluted &
      also problematic for clang, which complains if the input & output values
      have different widths. For example:
      
        In file included from kernel/fork.c:98:
        ./arch/mips/include/asm/mmu_context.h:149:19: error: unsupported
          inline asm: input with type 'unsigned long' matching output with
          type 'unsigned long long'
                write_c0_entryhi(cpu_asid(cpu, next));
                ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
        ./arch/mips/include/asm/mmu_context.h:93:2: note: expanded from macro
          'cpu_asid'
                (cpu_context((cpu), (mm)) & cpu_asid_mask(&cpu_data[cpu]))
                ^
        ./arch/mips/include/asm/mipsregs.h:1617:65: note: expanded from macro
          'write_c0_entryhi'
        #define write_c0_entryhi(val)   __write_ulong_c0_register($10, 0, val)
                                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
        ./arch/mips/include/asm/mipsregs.h:1430:39: note: expanded from macro
          '__write_ulong_c0_register'
                        __write_64bit_c0_register(reg, sel, val);               \
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
        ./arch/mips/include/asm/mipsregs.h:1400:41: note: expanded from macro
          '__write_64bit_c0_register'
                        __write_64bit_c0_split(register, sel, value);           \
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
        ./arch/mips/include/asm/mipsregs.h:1498:13: note: expanded from macro
          '__write_64bit_c0_split'
                                : "r,0" (val));                                 \
                                         ^~~
      
      We can both fix this build failure & simplify the code somewhat by
      assigning the __tmp variable with the input value in C prior to our
      inline assembly, and then using a single read-write output operand (ie.
      a constraint beginning with +) to provide this value to our assembly.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      08eeb44b
    • Paul Burton's avatar
      MIPS: Avoid using array as parameter to write_c0_kpgd() · b023a939
      Paul Burton authored
      Passing an array (swapper_pg_dir) as the argument to write_c0_kpgd() in
      setup_pw() will become problematic if we modify __write_64bit_c0_split()
      to cast its val argument to unsigned long long, because for 32-bit
      kernel builds the size of a pointer will differ from the size of an
      unsigned long long. This would fall foul of gcc's pointer-to-int-cast
      diagnostic.
      
      Cast the value to a long, which should be the same width as the pointer
      that we ultimately want & will be sign extended if required to the
      unsigned long long that __write_64bit_c0_split() ultimately needs.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      b023a939
  7. 06 Aug, 2018 3 commits
    • Paul Burton's avatar
      MIPS: vdso: Allow clang's --target flag in VDSO cflags · ee67855e
      Paul Burton authored
      The MIPS VDSO code filters out a subset of known-good flags from
      KBUILD_CFLAGS to use when building VDSO libraries. When we build using
      clang we need to allow the --target flag through, otherwise we'll
      generally attempt to build the VDSO for the architecture of the build
      machine rather than for MIPS.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20154/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      ee67855e
    • Paul Burton's avatar
      MIPS: genvdso: Remove GOT checks · 4467f7ad
      Paul Burton authored
      Our genvdso tool performs some rather paranoid checking that the VDSO
      library isn't attempting to make use of a GOT by constraining the number
      of entries that the GOT is allowed to contain to the minimum 2 entries
      that are always generated by binutils.
      
      Unfortunately lld prior to revision 334390 generates a third entry,
      which is unused & thus harmless but falls foul of genvdso's checks &
      causes the build to fail.
      
      Since we already check that the VDSO contains no relocations it seems
      reasonable to presume that it also doesn't contain use of a GOT, which
      would involve relocations. Thus rather than attempting to work around
      this issue by allowing 3 GOT entries when using lld, simply remove the
      GOT checks which seem overly paranoid.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20152/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      4467f7ad
    • Robert P. J. Day's avatar
      MIPS: Remove obsolete MIPS checks for DST node "chosen@0" · 7dc084d6
      Robert P. J. Day authored
      As there is precious little left in any DTS files referring to the
      node "/chosen@0" as opposed to "/chosen", remove the two checks for
      the former node name.
      
      [paul.burton@mips.com:
        The modified yamon-dt code only operates on
        arch/mips/boot/dts/mti/sead3.dts right now, and that uses chosen
        rather than chosen@0 anyway, so this should have no behavioural
        effect.]
      Signed-off-by: default avatarRobert P. J. Day <rpjday@crashcourse.ca>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20131/
      Cc: linux-mips@linux-mips.org
      7dc084d6
  8. 02 Aug, 2018 1 commit
    • Paul Burton's avatar
      MIPS: generic: Remove input symbols from defconfig · ca75e2fc
      Paul Burton authored
      generic_defconfig explicitly disables CONFIG_INPUT_MOUSEDEV,
      CONFIG_INPUT_KEYBOARD & CONFIG_INPUT_MOUSE which results in warnings
      when merging board config fragments if any of them require these
      options. This is the case for the ranchu board, which means we've had
      the following warning when configuring for generic platform targets
      since commit f2d0b0d5 ("MIPS: ranchu: Add Ranchu as a new
      generic-based board"):
      
        $ make ARCH=mips 32r2el_defconfig
        Using ./arch/mips/configs/generic_defconfig as base
        Merging arch/mips/configs/generic/32r2.config
        Merging arch/mips/configs/generic/el.config
        Merging ./arch/mips/configs/generic/board-sead-3.config
        Merging ./arch/mips/configs/generic/board-ranchu.config
        Value of CONFIG_INPUT_KEYBOARD is redefined by fragment ./arch/mips/configs/generic/board-ranchu.config:
        Previous value: # CONFIG_INPUT_KEYBOARD is not set
        New value: CONFIG_INPUT_KEYBOARD=y
      
        Merging ./arch/mips/configs/generic/board-ni169445.config
        Merging ./arch/mips/configs/generic/board-boston.config
        Merging ./arch/mips/configs/generic/board-ocelot.config
        Merging ./arch/mips/configs/generic/board-xilfpga.config
        scripts/kconfig/conf  --olddefconfig Kconfig
        #
        # configuration written to .config
        #
      
      Resolve this by removing mention of the CONFIG_INPUT_* Kconfig symbols
      from generic_defconfig, allowing them to take their default values &
      allowing board config fragments to enable them without warnings.
      
      This may be problematic if CONFIG_ARCH_MIGHT_HAVE_PC_SERIO is ever
      enabled for CONFIG_MIPS_GENERIC=y configurations, but for now that isn't
      the case so we can worry about that if & when it happens.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20109/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      ca75e2fc
  9. 01 Aug, 2018 3 commits
    • Paul Burton's avatar
      MIPS: Delete unused code in linux32.c · 48ae93fd
      Paul Burton authored
      The A() & AA() macros have been unused since commit 05e43966
      ("[MIPS] Use SYSVIPC_COMPAT to fix various problems on N32"), which
      switched to the more standard compat_ptr().
      
      RLIM_INFINITY32, RESOURCE32() & struct rlimit32 have been present but
      unused since the beginning of the git era.
      
      Remove the dead code.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20108/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      48ae93fd
    • Paul Burton's avatar
      MIPS: Remove unused sys_32_mmap2 · 3a1c0fc5
      Paul Burton authored
      The sys_32_mmap2 function has been unused since we started using syscall
      wrappers in commit dbda6ac0 ("MIPS: CVE-2009-0029: Enable syscall
      wrappers."), and is indeed identical to the sys_mips_mmap2 function that
      replaced it in sys32_call_table.
      
      Remove the dead code.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20107/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      3a1c0fc5
    • Paul Burton's avatar
      MIPS: Remove nabi_no_regargs · 96a68b14
      Paul Burton authored
      Our sigreturn functions make use of a macro named nabi_no_regargs to
      declare 8 dummy arguments to a function, forcing the compiler to expect
      a pt_regs structure on the stack rather than in argument registers. This
      is an ugly hack which unnecessarily causes these sigreturn functions to
      need to care about the calling convention of the ABI the kernel is built
      for. Although this is abstracted via nabi_no_regargs, it's still ugly &
      unnecessary.
      
      Remove nabi_no_regargs & the struct pt_regs argument from sigreturn
      functions, and instead use current_pt_regs() to find the struct pt_regs
      on the stack, which works cleanly regardless of ABI.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20106/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      96a68b14
  10. 31 Jul, 2018 4 commits
  11. 30 Jul, 2018 5 commits
    • Quentin Schulz's avatar
      MIPS: mscc: ocelot: add interrupt controller properties to GPIO controller · 6386889a
      Quentin Schulz authored
      The GPIO controller also serves as an interrupt controller for events
      on the GPIO it handles.
      
      An interrupt occurs whenever a GPIO line has changed.
      Signed-off-by: default avatarQuentin Schulz <quentin.schulz@bootlin.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20015/
      Cc: robh+dt@kernel.org
      Cc: mark.rutland@arm.com
      Cc: ralf@linux-mips.org
      Cc: jhogan@kernel.org
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: thomas.petazzoni@bootlin.com
      6386889a
    • Paul Burton's avatar
      MIPS: generic: Select MIPS_AUTO_PFN_OFFSET · 0211d49e
      Paul Burton authored
      Enable CONFIG_MIPS_AUTO_PFN_OFFSET for the generic platform, allowing
      it to avoid wasted book-keeping for pages with addresses lower than the
      physical base address of memory.
      
      This has a minimal impact on kernel text size, with 64r6el_defconfig
      gaining 0.1% in size as reported by bloat-o-meter:
      
        add/remove: 4/1 grow/shrink: 345/13 up/down: 9017/-392 (8625)
        Function                                     old     new   delta
        pcpu_setup_first_chunk                      1444    1780    +336
        pcpu_alloc_first_chunk                       864    1136    +272
        start_kernel                                1064    1288    +224
        initcall_blacklist                           224     372    +148
        try_fill_recv                               2088    2184     +96
        ...
        Total: Before=8457273, After=8465898, chg +0.10%
      
      The gain for systems with large offsets to physical memory & the ability
      to continue using generic kernels on such systems seems well worth this
      small cost.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Suggested-by: default avatarVladimir Kondratiev <vladimir.kondratiev@intel.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20049/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      0211d49e
    • Paul Burton's avatar
      MIPS: Allow auto-dection of ARCH_PFN_OFFSET & PHYS_OFFSET · 6c359eb1
      Paul Burton authored
      On systems where physical memory begins at a non-zero address, defining
      PHYS_OFFSET (which influences ARCH_PFN_OFFSET) can save us time & memory
      by avoiding book-keeping for pages from address zero to the start of
      memory.
      
      Some MIPS platforms already make use of this, but with the definition of
      PHYS_OFFSET being compile-time constant it hasn't been possible to
      enable this optimization for a kernel which may run on systems with
      varying physical memory base addresses.
      
      Introduce a new Kconfig option CONFIG_MIPS_AUTO_PFN_OFFSET which, when
      enabled, makes ARCH_PFN_OFFSET a variable & detects it from the boot
      memory map (which for example may have been populated from DT). The
      relationship with PHYS_OFFSET is reversed, with PHYS_OFFSET now being
      based on ARCH_PFN_OFFSET. This is because ARCH_PFN_OFFSET is used far
      more often, so avoiding the need for runtime calculation gives us a
      smaller impact on kernel text size (0.1% rather than 0.15% for
      64r6el_defconfig).
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Suggested-by: default avatarVladimir Kondratiev <vladimir.kondratiev@intel.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20048/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      6c359eb1
    • Paul Burton's avatar
      MIPS: Fix ISA virt/bus conversion for non-zero PHYS_OFFSET · 0494d7ff
      Paul Burton authored
      isa_virt_to_bus() & isa_bus_to_virt() claim to treat ISA bus addresses
      as being identical to physical addresses, but they fail to do so in the
      presence of a non-zero PHYS_OFFSET.
      
      Correct this by having them use virt_to_phys() & phys_to_virt(), which
      consolidates the calculations to one place & ensures that ISA bus
      addresses do indeed match physical addresses.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20047/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: Vladimir Kondratiev <vladimir.kondratiev@intel.com>
      0494d7ff
    • Paul Burton's avatar
      MIPS: Make (UN)CAC_ADDR() PHYS_OFFSET-agnostic · 0d0e1477
      Paul Burton authored
      Converting an address between cached & uncached (typically addresses in
      (c)kseg0 & (c)kseg1 or 2 xkphys regions) should not depend upon
      PHYS_OFFSET in any way - we're converting from a virtual address in one
      unmapped region to a virtual address in another unmapped region.
      
      For some reason our CAC_ADDR() & UNCAC_ADDR() macros make use of
      PAGE_OFFSET, which typically includes PHYS_OFFSET. This means that
      platforms with a non-zero PHYS_OFFSET typically have to workaround
      miscalculation by these 2 macros by also defining UNCAC_BASE to a value
      that isn't really correct.
      
      It appears that an attempt has previously been made to address this with
      commit 3f4579252aa1 ("MIPS: make CAC_ADDR and UNCAC_ADDR account for
      PHYS_OFFSET") which was later undone by commit ed3ce16c ("Revert
      "MIPS: make CAC_ADDR and UNCAC_ADDR account for PHYS_OFFSET"") which
      also introduced the ar7 workaround. That attempt at a fix was roughly
      equivalent, but essentially caused the CAC_ADDR() & UNCAC_ADDR() macros
      to cancel out PHYS_OFFSET by adding & then subtracting it again. In his
      revert Leonid is correct that using PHYS_OFFSET makes no sense in the
      context of these macros, but appears to have missed its inclusion via
      PAGE_OFFSET which means PHYS_OFFSET actually had an effect after the
      revert rather than before it.
      
      Here we fix this by modifying CAC_ADDR() & UNCAC_ADDR() to stop using
      PAGE_OFFSET (& thus PHYS_OFFSET), instead using __pa() & __va() along
      with UNCAC_BASE.
      
      For UNCAC_ADDR(), __pa() will convert a cached address to a physical
      address which we can simply use as an offset from UNCAC_BASE to obtain
      an address in the uncached region.
      
      For CAC_ADDR() we can undo the effect of UNCAC_ADDR() by subtracting
      UNCAC_BASE and using __va() on the result.
      
      With this change made, remove definitions of UNCAC_BASE from the ar7 &
      pic32 platforms which appear to have defined them only to workaround
      this problem.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      References: 3f4579252aa1 ("MIPS: make CAC_ADDR and UNCAC_ADDR account for PHYS_OFFSET")
      References: ed3ce16c ("Revert "MIPS: make CAC_ADDR and UNCAC_ADDR account for PHYS_OFFSET"")
      Patchwork: https://patchwork.linux-mips.org/patch/20046/
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: Vladimir Kondratiev <vladimir.kondratiev@intel.com>
      0d0e1477
  12. 28 Jul, 2018 4 commits
  13. 27 Jul, 2018 1 commit
    • Christoph Hellwig's avatar
      MIPS: remove mips_swiotlb_ops · a999933d
      Christoph Hellwig authored
      mips_swiotlb_ops differs from the generic swiotlb_dma_ops only in that
      it contains a mb() barrier after each operations that maps or syncs
      dma memory to the device.
      
      The dma operations are defined to not be memory barriers, but instead
      the write* operations to kick the DMA off are supposed to contain them.
      
      For mips this handled by war_io_reorder_wmb(), which evaluates to the
      stronger wmb() instead of the pure compiler barrier barrier() for
      just those platforms that use swiotlb, so I think we are covered
      properly.
      
      [paul.burton@mips.com:
        - Include linux/swiotlb.h to fix build failures for configs with
          CONFIG_SWIOTLB=y.]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20038/
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: linux-mips@linux-mips.org
      Cc: iommu@lists.linux-foundation.org
      Cc: linux-kernel@vger.kernel.org
      a999933d
  14. 26 Jul, 2018 5 commits
  15. 25 Jul, 2018 2 commits
    • Mathias Kresin's avatar
      MIPS: ath79: get PCIe controller out of reset · 0316b053
      Mathias Kresin authored
      The ar724x pci driver expects the PCIe controller to be brought out of
      reset by the bootloader.
      
      At least the AVM Fritz 300E bootloader doesn't take care of releasing
      the different PCIe controller related resets which causes an endless
      hang as soon as either the PCIE Reset register (0x180f0018) or the PCI
      Application Control register (0x180f0000) is read from.
      
      Do the full "PCIE Root Complex Initialization Sequence" if the PCIe
      host controller is still in reset during probing.
      
      The QCA u-boot sleeps 10ms after the PCIE Application Control bit is
      set to ready. It has been shown that 10ms might not be enough time if
      PCIe should be used right after setting the bit. During my tests it
      took up to 20ms till the link was up. Giving the link up to 100ms
      should work for all cases.
      Signed-off-by: default avatarMathias Kresin <dev@kresin.me>
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/19916/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      0316b053
    • Gabor Juhos's avatar
      MIPS: ath79: enable uart during early_prink · ffc20581
      Gabor Juhos authored
      This patch ensures, that the pinmux register is properly setup for the
      boot console UART when early_printk is enabled.
      
      [paul.burton@mips.com:
        - s/poinmux/pinmux/
        - s/uart/UART/
        - Drop extraneous parentheses.]
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      ffc20581