1. 22 May, 2020 8 commits
    • Serge Semin's avatar
      mips: csrc-r4k: Mark R4K timer as unstable if CPU freq changes · 38586428
      Serge Semin authored
      Commit 07d69579 ("MIPS: Don't register r4k sched clock when CPUFREQ
      enabled") disabled the r4k-clock usage for scheduler ticks counting due
      to the scheduler being non-tolerant for unstable clocks sources. For the
      same reason the clock should be used in the system clocksource framework
      with care. As soon as CPU frequency changes the clocksource framework
      should be notified about this by marking the R4K timer being unstable
      (which it really is, since the ticks rate has been changed synchronously
      with the CPU frequency).
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      38586428
    • Serge Semin's avatar
      mips: Add udelay lpj numbers adjustment · ed26aacf
      Serge Semin authored
      Loops-per-jiffies is a special number which represents a number of
      noop-loop cycles per CPU-scheduler quantum - jiffies. As you
      understand aside from CPU-specific implementation it depends on
      the CPU frequency. So when a platform has the CPU frequency fixed,
      we have no problem and the current udelay interface will work
      just fine. But as soon as CPU-freq driver is enabled and the cores
      frequency changes, we'll end up with distorted udelay's. In order
      to fix this we have to accordinly adjust the per-CPU udelay_val
      (the same as the global loops_per_jiffy) number. This can be done
      in the CPU-freq transition event handler. We subscribe to that event
      in the MIPS arch time-inititalization method.
      Co-developed-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarJiaxun Yang <jiaxun.yang@flygoat.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      ed26aacf
    • Serge Semin's avatar
      mips: Add CPS_NS16550_WIDTH config · ad42e0a8
      Serge Semin authored
      On some platforms IO-memory might require to use a proper load/store
      instructions (like Baikal-T1 IO-memory). To fix the cps-vec UART debug
      printout let's add the CONFIG_CPS_NS16550_WIDTH config to determine which
      instructions lb/sb, lh/sh or lw/sw are required for MMIO operations.
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      ad42e0a8
    • Serge Semin's avatar
      mips: Add CONFIG/CONFIG6/Cause reg fields macro · 999079c8
      Serge Semin authored
      There are bit fields which persist in the MIPS CONFIG and CONFIG6
      registers, but haven't been described in the generic mipsregs.h
      header so far. In particular, the generic CONFIG bitfields are
      BE - endian mode, BM - burst mode, SB - SimpleBE, OCP interface mode
      indicator, UDI - user-defined "CorExtend" instructions, DSP - data
      scratch pad RAM present, ISP - instruction scratch pad RAM present,
      etc. The core-specific CONFIG6 bitfields are JRCD - jump register
      cache prediction disable, R6 - MIPSr6 extensions enable, IFUPerfCtl -
      IFU performance control, SPCD - sleep state performance counter, DLSB -
      disable load/store bonding. A new exception code reported in the
      ExcCode field of the Cause register: 30 - Parity/ECC error exception
      happened on either fetch, load or cache refill. Lets add them to the
      mipsregs.h header to be used in future platform code, which have them
      utilized.
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      999079c8
    • Serge Semin's avatar
      mips: Add CP0 Write Merge config support · 742318ad
      Serge Semin authored
      CP0 config register may indicate whether write-through merging
      is allowed. Currently there are two types of the merging available:
      SysAD Valid and Full modes. Whether each of them are supported by
      the core is implementation dependent. Moreover whether the ability
      to change the mode also depends on the chip family instance. Taking
      into account all of this we created a dedicated mm_config() method
      to detect and enable merging if it's supported. It is called for
      MIPS-type processors at CPU-probe stage and attempts to detect whether
      the write merging is available. If it's known to be supported and
      switchable, then switch on the full mode. Otherwise just perform the
      CP0.Config.MM field analysis.
      
      In addition there are platforms like InterAptiv/ProAptiv, which do have
      the MM bit field set by default, but having write-through cacheing
      unsupported makes write-merging also unsupported. In this case we just
      ignore the MM field value.
      Co-developed-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      742318ad
    • Serge Semin's avatar
      mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs · a2ac81c6
      Serge Semin authored
      Commit 1aeba347 ("MIPS: Hardcode cpu_has_mips* where target ISA
      allows") updated the cpu_has_mips* macro to be replaced with a constant
      expression where it's possible. By mistake it wasn't done correctly
      for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to
      be replaced with conditional expression __isa_range_or_flag(), which
      means either ISA revision being within the range or the corresponding
      CPU options flag was set at the probe stage or both being true at the
      same time. But the ISA level value doesn't indicate whether the ISA is
      MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5
      architectures the __isa_range() macro will activate the
      cpu_has_mips64rX flags, which is incorrect. In order to fix the
      problem we make sure the 64bits CPU support is enabled by means of
      checking the flag cpu_has_64bits aside with proper ISA range and specific
      Revision flag being set.
      
      Fixes: 1aeba347 ("MIPS: Hardcode cpu_has_mips* where target ISA allows")
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      a2ac81c6
    • Serge Semin's avatar
      mips: Add MIPS Warrior P5600 support · 281e3aea
      Serge Semin authored
      This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
      exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
      and system level features like up to six P5600 calculation cores, CM2
      with L2 cache, IOCU/IOMMU (though might be unused depending on the
      system-specific IP core configuration), GIC, CPC, virtualisation module,
      eJTAG and PDtrace.
      
      As being MIPS32 Release 5 based core it provides all the features
      available by the CPU_MIPS32_R5 config, while adding a few more like
      UCA attribute support, availability of CPU-freq (by means of L2/CM
      clock ratio setting), EI/VI GIC modes detection at runtime.
      
      In addition to this if P5600 architecture is enabled modern GNU GCC
      provides a specific tuning for P5600 processors with respect to the
      classic MIPS32 Release 5. First of all branch-likely avoidance is
      activated only when the code is compiled with the speed optimization
      (avoidance is always enabled for the pure MIPS32 Release 5
      architecture). Secondly the madd/msub avoidance is enabled since
      madd/msub utilization isn't profitable due to overhead of getting the
      result out of the HI/LO registers. Multiply-accumulate instructions are
      activated and utilized together with the necessary code reorder when
      multiply-add/multiply-subtract statements are met. Finally load/store
      bonding is activated by default. All of these optimizations may make
      the code relatively faster than if just MIP32 release 5 architecture
      was requested.
      Co-developed-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      281e3aea
    • Serge Semin's avatar
      mips: Add MIPS Release 5 support · ab7c01fd
      Serge Semin authored
      There are five MIPS32/64 architecture releases currently available:
      from 1 to 6 except fourth one, which was intentionally skipped.
      Three of them can be called as major: 1st, 2nd and 6th, that not only
      have some system level alterations, but also introduced significant
      core/ISA level updates. The rest of the MIPS architecture releases are
      minor.
      
      Even though they don't have as much ISA/system/core level changes
      as the major ones with respect to the previous releases, they still
      provide a set of updates (I'd say they were intended to be the
      intermediate releases before a major one) that might be useful for the
      kernel and user-level code, when activated by the kernel or compiler.
      In particular the following features were introduced or ended up being
      available at/after MIPS32/64 Release 5 architecture:
      + the last release of the misaligned memory access instructions,
      + virtualisation - VZ ASE - is optional component of the arch,
      + SIMD - MSA ASE - is optional component of the arch,
      + DSP ASE is optional component of the arch,
      + CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
        must be available if FPU is implemented,
      + CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
        are available.
      + UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
        ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
      + CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
        accidentally clearing LL-bit when returning from an interrupt,
        exception, or error trap,
      + XPA feature together with extended versions of CPx registers is
        introduced, which needs to have mfhc0/mthc0 instructions available.
      
      So due to these changes GNU GCC provides an extended instructions set
      support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
      though the architecture alteration isn't that big, it still worth to be
      taken into account by the kernel software. Finally we can't deny that
      some optimization/limitations might be found in future and implemented
      on some level in kernel or compiler. In this case having even
      intermediate MIPS architecture releases support would be more than
      useful.
      
      So the most of the changes provided by this commit can be split into
      either compile- or runtime configs related. The compile-time related
      changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
      configs and concern the code activating MIPSR2 or MIPSR6 already
      implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
      CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
      platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
      concerns the features which are handled with respect to the MIPS ISA
      revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
      these fields can be used to detect either r1 or r2 or r6 releases.
      But since we know which CPUs in fact support the R5 arch, we can manually
      set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
      use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
      
      Since XPA/EVA provide too complex alterationss and to have them used with
      MIPS32 Release 2 charged kernels (for compatibility with current platform
      configs) they are left to be setup as a separate kernel configs.
      Co-developed-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarAlexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Paul Burton <paulburton@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      ab7c01fd
  2. 21 May, 2020 2 commits
  3. 20 May, 2020 2 commits
  4. 19 May, 2020 3 commits
  5. 18 May, 2020 2 commits
  6. 17 May, 2020 6 commits
  7. 15 May, 2020 5 commits
  8. 13 May, 2020 7 commits
  9. 12 May, 2020 5 commits
    • Thomas Bogendoerfer's avatar
      MIPS: Only include the platform file needed · 26bff9eb
      Thomas Bogendoerfer authored
      Instead of including all Platform files, we simply include the
      needed one and avoid clashes with makefile variables.
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      26bff9eb
    • Nathan Chancellor's avatar
      MIPS: VDSO: Allow ld.lld to link the VDSO · 22235ef3
      Nathan Chancellor authored
      Currently, when linking with ld.lld, this warning pops up:
      
          arch/mips/vdso/Makefile:70: MIPS VDSO requires binutils >= 2.25
      
      CONFIG_LD_VERSION is set with scripts/ld-version.sh, which is specific
      to GNU ld. It returns 0 for ld.lld so CONFIG_MIPS_LD_CAN_LINK_VDSO does
      not set.
      
      ld.lld has a completely different versioning scheme (as it follows
      LLVM's versioning) and it does not have the issue mentioned in the
      comment block so it should be allowed to link the VDSO.
      
      With this patch, the VDSO successfully links and shows P_MIPS_PC32 in
      vgettimeofday.o.
      
      $ llvm-objdump -Dr arch/mips/vdso/vgettimeofday.o | grep R_MIPS_PC32
      			00000024:  R_MIPS_PC32	_start
      			000000b0:  R_MIPS_PC32	_start
      			000002bc:  R_MIPS_PC32	_start
      			0000036c:  R_MIPS_PC32	_start
      			00000468:  R_MIPS_PC32	_start
      Reported-by: default avatarDmitry Golovin <dima@golovin.in>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Link: https://github.com/ClangBuiltLinux/linux/issues/785
      Link: https://github.com/llvm/llvm-project/commit/e364e2e9ce50c12eb2bf093560e1a1a8544d455aSigned-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      22235ef3
    • Nathan Chancellor's avatar
      MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO · 2ff90699
      Nathan Chancellor authored
      Currently, the VDSO is being linked through $(CC). This does not match
      how the rest of the kernel links objects, which is through the $(LD)
      variable.
      
      When clang is built in a default configuration, it first attempts to use
      the target triple's default linker then the system's default linker,
      unless told otherwise through -fuse-ld=... We do not use -fuse-ld=
      because it can be brittle and we have support for invoking $(LD)
      directly. See commit fe00e50b ("ARM: 8858/1: vdso: use $(LD)
      instead of $(CC) to link VDSO") and commit 691efbed ("arm64: vdso:
      use $(LD) instead of $(CC) to link VDSO") for examples of doing this in
      the VDSO.
      
      Do the same thing here. Replace the custom linking logic with $(cmd_ld)
      and ldflags-y so that $(LD) is respected. We need to explicitly add two
      flags to the linker that were implicitly passed by the compiler:
      -G 0 (which comes from ccflags-vdso) and --eh-frame-hdr.
      
      Before this patch (generated by adding '-v' to VDSO_LDFLAGS):
      
      <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/collect2 \
      -plugin <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/liblto_plugin.so \
      -plugin-opt=<gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/lto-wrapper \
      -plugin-opt=-fresolution=/tmp/ccGEi5Ka.res \
      --eh-frame-hdr \
      -G 0 \
      -EB \
      -mips64r2 \
      -shared \
      -melf64btsmip \
      -o arch/mips/vdso/vdso.so.dbg.raw \
      -L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0/64 \
      -L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0 \
      -L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0/../../../../mips64-linux/lib \
      -Bsymbolic \
      --no-undefined \
      -soname=linux-vdso.so.1 \
      -EB \
      --hash-style=sysv \
      --build-id \
      -T arch/mips/vdso/vdso.lds \
      arch/mips/vdso/elf.o \
      arch/mips/vdso/vgettimeofday.o \
      arch/mips/vdso/sigreturn.o
      
      After this patch:
      
      <gcc_prefix>/bin/mips64-linux-ld \
      -m elf64btsmip \
      -Bsymbolic \
      --no-undefined \
      -soname=linux-vdso.so.1 \
      -EB \
      -nostdlib \
      -shared \
      -G 0 \
      --eh-frame-hdr \
      --hash-style=sysv \
      --build-id \
      -T  arch/mips/vdso/vdso.lds \
      arch/mips/vdso/elf.o \
      arch/mips/vdso/vgettimeofday.o
      arch/mips/vdso/sigreturn.o \
      -o arch/mips/vdso/vdso.so.dbg.raw
      
      Note that we leave behind -mips64r2. Turns out that ld ignores it (see
      get_emulation in ld/ldmain.c). This is true of current trunk and 2.23,
      which is the minimum supported version for the kernel:
      
      https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldmain.c;hb=aa4209e7b679afd74a3860ce25659e71cc4847d5#l593
      https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldmain.c;hb=a55e30b51bc6227d8d41f707654d0a5620978dcf#l641
      
      Before this patch, LD=ld.lld did nothing:
      
      $ llvm-readelf -p.comment arch/mips/vdso/vdso.so.dbg | sed 's/(.*//'
      String dump of section '.comment':
      [     0] ClangBuiltLinux clang version 11.0.0
      
      After this patch, it does:
      
      $ llvm-readelf -p.comment arch/mips/vdso/vdso.so.dbg | sed 's/(.*//'
      String dump of section '.comment':
      [     0] Linker: LLD 11.0.0
      [    62] ClangBuiltLinux clang version 11.0.0
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/785Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      2ff90699
    • Nathan Chancellor's avatar
      MIPS: Unconditionally specify '-EB' or '-EL' · fd9d0ca2
      Nathan Chancellor authored
      This was all done to work around a GCC bug that has been fixed after
      4.2. The kernel requires GCC 4.6 or newer so remove all of these hacks
      and just use the traditional flags.
      
       $ mips64-linux-gcc --version | head -n1
       mips64-linux-gcc (GCC) 4.6.3
      
       $ mips64-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE
       #define MIPSEB 1
       #define __MIPSEB__ 1
       #define _MIPSEB 1
       #define __MIPSEB 1
      
       $ mips64-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE
       #define __MIPSEL__ 1
       #define MIPSEL 1
       #define _MIPSEL 1
       #define __MIPSEL 1
      
      This is necessary when converting the MIPS VDSO to use $(LD) instead of
      $(CC) to link because the OUTPUT_FORMAT is defaulted to little endian
      and only flips to big endian when '-EB' is set on the command line.
      There is no issue currently because the compiler explicitly passes
      '-EB' or '-EL' to the linker regardless of whether or not it was
      provided by the user. Passing '-v' to VDSO_LDFLAGS shows:
      
      <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/collect2 ... -EB ...
      
      even though '-EB' is nowhere to be found in KBUILD_CFLAGS. The VDSO
      Makefile already supports getting '-EB' or '-EL' from KBUILD_CFLAGS
      through a filter directive but '-EB' or '-EL' is not always present.
      
      If we do not do this, we will see the following error when compiling
      for big endian:
      
      $ make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64-linux- \
        64r2el_defconfig arch/mips/vdso/
      ...
      mips64-linux-ld: arch/mips/vdso/elf.o: compiled for a big endian system
      and target is little endian
      mips64-linux-ld: arch/mips/vdso/elf.o: endianness incompatible with that
      of the selected emulation
      mips64-linux-ld: failed to merge target specific data of file
      arch/mips/vdso/elf.o
      ...
      
      Remove this legacy hack and just use '-EB' and '-EL' unconditionally.
      Reported-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      fd9d0ca2
    • Nathan Chancellor's avatar
      MIPS: VDSO: Move disabling the VDSO logic to Kconfig · e91946d6
      Nathan Chancellor authored
      After commit 9553d16f ("init/kconfig: Add LD_VERSION Kconfig"), we
      have access to GNU ld's version at configuration time. As a result, we
      can make it clearer under what configuration circumstances the MIPS VDSO
      needs to be disabled.
      
      This is a prerequisite for getting rid of the MIPS VDSO binutils
      warning and linking the VDSO when LD is ld.lld. Wrapping the call to
      ld-ifversion with CONFIG_LD_IS_LLD does not work because the config
      values are wiped away during 'make clean'.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      e91946d6