1. 03 Aug, 2016 3 commits
  2. 02 Aug, 2016 10 commits
    • Paul Burton's avatar
      MIPS: Use CPHYSADDR to implement mips32 __pa · 0d8d83d0
      Paul Burton authored
      Use CPHYSADDR to implement the __pa macro converting from a virtual to a
      physical address for MIPS32, much as is already done for MIPS64 (though
      without the complication of having both compatibility & XKPHYS
      segments).
      
      This allows for __pa to work regardless of whether the address being
      translated is in kseg0 or kseg1, unlike the previous subtraction based
      approach which only worked for addresses in kseg0. Working for kseg1
      addresses is important if __pa is used on addresses allocated by
      dma_alloc_coherent, where on systems with non-coherent I/O we provide
      addresses in kseg1. If this address is then used with
      dma_map_single_attrs then it is provided to virt_to_page, which in turn
      calls virt_to_phys which is a wrapper around __pa. The result is that we
      end up with a physical address 0x20000000 bytes (ie. the size of kseg0)
      too high.
      
      In addition to providing consistency with MIPS64 & fixing the kseg1 case
      above this has the added bonus of generating smaller code for systems
      implementing MIPS32r2 & beyond, where a single ext instruction can
      extract the physical address rather than needing to load an immediate
      into a temp register & subtract it. This results in ~1.3KB savings for a
      boston_defconfig kernel adjusted to set CONFIG_32BIT=y.
      
      This patch does not change the EVA case, which may or may not have
      similar issues around handling both cached & uncached addresses but is
      beyond the scope of this patch.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13836/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      0d8d83d0
    • Aaro Koskinen's avatar
      MIPS: Octeon: Dlink_dsr-1000n.dts: add more leds. · 5c315e39
      Aaro Koskinen authored
      Add more leds discovered by reverse engineering. Labels are according
      to markings in the mechanics.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13466/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      5c315e39
    • Aaro Koskinen's avatar
      MIPS: Octeon: Clean up GPIO definitions in dlink_dsr-1000n.dts. · e1b7d0e2
      Aaro Koskinen authored
      Clean up GPIO definitions in dlink_dsr-1000n.dts.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13465/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e1b7d0e2
    • Aaro Koskinen's avatar
      MIPS: Octeon: Delete built-in DTB pruning code for D-Link DSR-1000N. · 86bee12f
      Aaro Koskinen authored
      Users will get more complete functionality by using the appended DTB,
      so delete the legacy booting support for this board.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13464/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      86bee12f
    • Jonas Gorski's avatar
      MIPS: store the appended dtb address in a variable · 15f37e15
      Jonas Gorski authored
      Instead of rewriting the arguments to match the UHI spec, store the
      address of a appended or UHI supplied dtb in fw_supplied_dtb.
      
      That way the original bootloader arugments are kept intact while still
      making the use of an appended dtb invisible for mach code.
      
      Mach code can still find out if it is an appended dtb by comparing
      fw_arg1 with fw_supplied_dtb.
      Signed-off-by: default avatarJonas Gorski <jogo@openwrt.org>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Alban Bedel <albeu@free.fr>
      Cc: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13699/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      15f37e15
    • Jonas Gorski's avatar
      MIPS: ZBOOT: copy appended dtb to the end of the kernel · b8f54f2c
      Jonas Gorski authored
      Instead of rewriting the arguments, just move the appended dtb to where
      the decompressed kernel expects it. This eliminates the need for special
      casing vmlinuz.bin appended dtb files.
      Signed-off-by: default avatarJonas Gorski <jogo@openwrt.org>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Alban Bedel <albeu@free.fr>
      Cc: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13698/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      b8f54f2c
    • Álvaro Fernández Rojas's avatar
      MIPS: ralink: fix spis group pinmux · 79977894
      Álvaro Fernández Rojas authored
      pwm function for spis conflicts with uart2 and uart1, fix this by changing it
      to pwm_uart2, which reflects the real use of these pins with these pinmux
      (2 for pwm and 2 for uart).
      Signed-off-by: default avatarÁlvaro Fernández Rojas <noltari@gmail.com>
      Cc: john@phrozen.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13369/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      79977894
    • Harvey Hunt's avatar
      MIPS: Factor o32 specific code into signal_o32.c · d1e63c94
      Harvey Hunt authored
      The commit ebb5e78c ("MIPS: Initial implementation of a VDSO")
      caused building a 64 bit kernel with support for n32 and not o32
      to produce a build error:
      
      arch/mips/kernel/signal32.c:415:11: error: ‘vdso_image_o32’ undeclared here (not in a function)
        .vdso  = &vdso_image_o32,
      
      Fix this by moving the o32 specific code into signal_o32.c and
      updating the Makefile accordingly.
      Signed-off-by: default avatarHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13690/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      d1e63c94
    • Paul Burton's avatar
      MIPS: non-exec stack & heap when non-exec PT_GNU_STACK is present · 1a770b85
      Paul Burton authored
      The stack and heap have both been executable by default on MIPS until
      now. This patch changes the default to be non-executable, but only for
      ELF binaries with a non-executable PT_GNU_STACK header present. This
      does apply to both the heap & the stack, despite the name PT_GNU_STACK,
      and this matches the behaviour of other architectures like ARM & x86.
      
      Current MIPS toolchains do not produce the PT_GNU_STACK header, which
      means that we can rely upon this patch not changing the behaviour of
      existing binaries. The new default will only take effect for newly
      compiled binaries once toolchains are updated to support PT_GNU_STACK,
      and since those binaries are newly compiled they can be compiled
      expecting the change in default behaviour. Again this matches the way in
      which the ARM & x86 architectures handled their implementations of
      non-executable memory.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13765/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      1a770b85
    • Paul Burton's avatar
      MIPS: Use per-mm page to execute branch delay slot instructions · 432c6bac
      Paul Burton authored
      In some cases the kernel needs to execute an instruction from the delay
      slot of an emulated branch instruction. These cases include:
      
        - Emulated floating point branch instructions (bc1[ft]l?) for systems
          which don't include an FPU, or upon which the kernel is run with the
          "nofpu" parameter.
      
        - MIPSr6 systems running binaries targeting older revisions of the
          architecture, which may include branch instructions whose encodings
          are no longer valid in MIPSr6.
      
      Executing instructions from such delay slots is done by writing the
      instruction to memory followed by a trap, as part of an "emuframe", and
      executing it. This avoids the requirement of an emulator for the entire
      MIPS instruction set. Prior to this patch such emuframes are written to
      the user stack and executed from there.
      
      This patch moves FP branch delay emuframes off of the user stack and
      into a per-mm page. Allocating a page per-mm leaves userland with access
      to only what it had access to previously, and compared to other
      solutions is relatively simple.
      
      When a thread requires a delay slot emulation, it is allocated a frame.
      A thread may only have one frame allocated at any one time, since it may
      only ever be executing one instruction at any one time. In order to
      ensure that we can free up allocated frame later, its index is recorded
      in struct thread_struct. In the typical case, after executing the delay
      slot instruction we'll execute a break instruction with the BRK_MEMU
      code. This traps back to the kernel & leads to a call to do_dsemulret
      which frees the allocated frame & moves the user PC back to the
      instruction that would have executed following the emulated branch.
      In some cases the delay slot instruction may be invalid, such as a
      branch, or may trigger an exception. In these cases the BRK_MEMU break
      instruction will not be hit. In order to ensure that frames are freed
      this patch introduces dsemul_thread_cleanup() and calls it to free any
      allocated frame upon thread exit. If the instruction generated an
      exception & leads to a signal being delivered to the thread, or indeed
      if a signal simply happens to be delivered to the thread whilst it is
      executing from the struct emuframe, then we need to take care to exit
      the frame appropriately. This is done by either rolling back the user PC
      to the branch or advancing it to the continuation PC prior to signal
      delivery, using dsemul_thread_rollback(). If this were not done then a
      sigreturn would return to the struct emuframe, and if that frame had
      meanwhile been used in response to an emulated branch instruction within
      the signal handler then we would execute the wrong user code.
      
      Whilst a user could theoretically place something like a compact branch
      to self in a delay slot and cause their thread to become stuck in an
      infinite loop with the frame never being deallocated, this would:
      
        - Only affect the users single process.
      
        - Be architecturally invalid since there would be a branch in the
          delay slot, which is forbidden.
      
        - Be extremely unlikely to happen by mistake, and provide a program
          with no more ability to harm the system than a simple infinite loop
          would.
      
      If a thread requires a delay slot emulation & no frame is available to
      it (ie. the process has enough other threads that all frames are
      currently in use) then the thread joins a waitqueue. It will sleep until
      a frame is freed by another thread in the process.
      
      Since we now know whether a thread has an allocated frame due to our
      tracking of its index, the cookie field of struct emuframe is removed as
      we can be more certain whether we have a valid frame. Since a thread may
      only ever have a single frame at any given time, the epc field of struct
      emuframe is also removed & the PC to continue from is instead stored in
      struct thread_struct. Together these changes simplify & shrink struct
      emuframe somewhat, allowing twice as many frames to fit into the page
      allocated for them.
      
      The primary benefit of this patch is that we are now free to mark the
      user stack non-executable where that is possible.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13764/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      432c6bac
  3. 01 Aug, 2016 1 commit
  4. 29 Jul, 2016 13 commits
    • James Hogan's avatar
      MIPS: c-r4k: Use SMP calls for CM indexed cache ops · 11f76903
      James Hogan authored
      The MIPS Coherence Manager (CM) can propagate address-based ("hit")
      cache operations to other cores in the coherent system, alleviating
      software of the need to use SMP calls, however indexed cache operations
      are not propagated by hardware since doing so makes no sense for
      separate caches.
      
      Update r4k_op_needs_ipi() to report that only hit cache operations are
      globalized by the CM, requiring indexed cache operations to be
      globalized by software via an SMP call.
      
      r4k_on_each_cpu() previously had a special case for CONFIG_MIPS_MT_SMP,
      intended to avoid the SMP calls when the only other CPUs in the system
      were other VPEs in the same core, and hence sharing the same caches.
      This was changed by commit cccf34e9 ("MIPS: c-r4k: Fix cache
      flushing for MT cores") to apparently handle multi-core multi-VPE
      systems, but it focussed mainly on hit cache ops, so the SMP calls were
      still disabled entirely for CM systems.
      
      This doesn't normally cause problems, but tests can be written to hit
      these corner cases by using multiple threads, or changing task
      affinities to force the process to migrate cores. For example the
      failure of mprotect RW->RX to globally sync icaches (via
      flush_cache_range) can be detected by modifying and mprotecting a code
      page on one core, and migrating to a different core to execute from it.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13807/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      11f76903
    • James Hogan's avatar
      MIPS: c-r4k: Avoid small flush_icache_range SMP calls · f70ddc07
      James Hogan authored
      Avoid SMP calls for flushing small icache ranges. On non-CM platforms,
      and CM platforms too after we make r4k_on_each_cpu() take the cache op
      type into account, it will be called on multiple CPUs due to the
      possibility that local_r4k_flush_icache_range_ipi() could do
      non-globalized indexed cache ops. This rougly copies the range size
      check out into r4k_flush_icache_range(), which can disallow indexed
      cache ops and allow r4k_on_each_cpu() to skip the SMP call.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13805/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f70ddc07
    • James Hogan's avatar
      MIPS: c-r4k: Local flush_icache_range cache op override · 27b93d9c
      James Hogan authored
      Allow the permitted cache op types used by
      local_r4k_flush_icache_range_ipi() to be overridden by the SMP caller.
      This will allow SMP calls to be avoided under certain circumstances,
      falling back to a single CPU performing globalized hit cache ops only.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13803/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      27b93d9c
    • James Hogan's avatar
      MIPS: c-r4k: Split r4k_flush_kernel_vmap_range() · a9341ae2
      James Hogan authored
      Split the operation of r4k_flush_kernel_vmap_range() into separate
      SMP callbacks for the indexed cache flush and hit cache flush cases,
      since the logic to determine which to use can be determined by the
      initiating CPU prior to doing any SMP calls.
      
      This will help when we change r4k_on_each_cpu() to distinguish indexed
      and hit cache ops in a later patch, preventing globalized hit cache ops
      being performed redundantly on multiple CPUs.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13806/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      a9341ae2
    • James Hogan's avatar
      MIPS: c-r4k: Exclude sibling CPUs in SMP calls · 640511ae
      James Hogan authored
      When performing SMP calls to foreign cores, exclude sibling CPUs from
      the provided map, as we already handle the local core on the current
      CPU. This prevents an SMP call from for example core 0, VPE 1 to VPE 0
      on the same core.
      
      In the process the cpu_foreign_map cpumask is turned into an array of
      cpumasks, so that each CPU has its own version of it which excludes
      sibling CPUs. r4k_op_needs_ipi() is also updated to reflect that cache
      management SMP calls are not needed when all CPUs are siblings (i.e.
      there are no foreign CPUs according to the new cpu_foreign_map[]
      semantics which exclude siblings).
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jayachandran C. <jchandra@broadcom.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13801/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      640511ae
    • James Hogan's avatar
      MIPS: c-r4k: Fix valid ASID optimisation · 6d758bfc
      James Hogan authored
      Several cache operations are optimised to return early from the SMP call
      handler if the memory map in question has no valid ASID on the current
      CPU, or any online CPU in the case of MIPS_MT_SMP. The idea is that if a
      memory map has never been used on a CPU it shouldn't have cache lines in
      need of flushing.
      
      However this doesn't cover all cases when ASIDs for other CPUs need to
      be checked:
      - Offline VPEs may have recently been online and brought lines into the
        (shared) cache, so they should also be checked, rather than only
        online CPUs.
      - SMP systems with a Coherence Manager (CM), but with MT disabled still
        have globalized hit cache ops, but don't use SMP calls, so all present
        CPUs should be taken into account.
      - R6 systems have a different multithreading implementation, so
        MIPS_MT_SMP won't be set, but as above may still have a CM which
        globalizes hit cache ops.
      
      Additionally for non-globalized cache operations where an SMP call to a
      single VPE in each foreign core is used, it is not necessary to check
      every CPU in the system, only sibling CPUs sharing the same first level
      cache.
      
      Fix this by making has_valid_asid() take a cache op type argument like
      r4k_on_each_cpu(), so it can determine whether r4k_on_each_cpu() will
      have done SMP calls to other cores. It can then determine which set of
      CPUs to check the ASIDs of based on that, excluding foreign CPUs if an
      SMP call will have been performed.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13804/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      6d758bfc
    • James Hogan's avatar
      MIPS: c-r4k: Add r4k_on_each_cpu cache op type arg · d374d937
      James Hogan authored
      The r4k_on_each_cpu() function calls the specified cache flush helper on
      other CPUs if deemed necessary due to the cache ops not being
      globalized by hardware. However this really depends on the cache op
      addressing type, as the MIPS Coherence Manager (CM) if present will
      globalize "hit" cache ops (addressed by virtual address), but not
      "index" cache ops (addressed by cache index). This results in index
      cache ops only being performed on a single CPU when CM is present.
      
      Most (but not all) of the functions called by r4k_on_each_cpu() perform
      cache operations exclusively with a single cache op type, so add a type
      argument and modify the callers to pass in some combination of R4K_HIT
      (global kernel virtual addressing or user virtual addressing
      conditional upon matching active_mm) and R4K_INDEX (index into cache).
      
      This will allow r4k_on_each_cpu() to later distinguish these cases and
      decide whether to perform an SMP call based on it.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13798/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      d374d937
    • James Hogan's avatar
      MIPS: c-r4k: Avoid dcache flush for sigtramps · 8bd646e9
      James Hogan authored
      Avoid the dcache and scache flush in local_r4k_flush_cache_sigtramp() if
      the icache fills straight from the dcache.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13802/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      8bd646e9
    • James Hogan's avatar
      MIPS: c-r4k: Fix sigtramp SMP call to use kmap · e523f289
      James Hogan authored
      Fix r4k_flush_cache_sigtramp() and local_r4k_flush_cache_sigtramp() to
      flush the delay slot emulation trampoline cacheline through a kmap
      rather than directly when the active_mm doesn't match that of the task
      initiating the flush, a bit like local_r4k_flush_cache_page() does.
      
      This would fix a corner case on SMP systems without hardware globalized
      hit cache ops, where a migration to another CPU after the flush, where
      that CPU did not have the same mm active at the time of the flush, could
      result in stale icache content being executed instead of the trampoline,
      e.g. from a previous delay slot emulation with a similar stack pointer.
      
      This case was artificially triggered by replacing the icache flush with
      a full indexed flush (not globalized on CM systems) and forcing the SMP
      call to take place, with a test program that alternated two FPU delay
      slots with a parent process repeatedly changing scheduler affinity.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13797/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e523f289
    • James Hogan's avatar
      MIPS: c-r4k: Fix protected_writeback_scache_line for EVA · 0758b116
      James Hogan authored
      The protected_writeback_scache_line() function is used by
      local_r4k_flush_cache_sigtramp() to flush an FPU delay slot emulation
      trampoline on the userland stack from the caches so it is visible to
      subsequent instruction fetches.
      
      Commit de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing
      functions") updated some protected_ cache flush functions to use EVA
      CACHEE instructions via protected_cachee_op(), and commit 83fd4344
      ("MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line") did
      the same thing for protected_writeback_dcache_line(), but
      protected_writeback_scache_line() never got updated. Lets fix that now
      to flush the right user address from the secondary cache rather than
      some arbitrary kernel unmapped address.
      
      This issue was spotted through code inspection, and it seems unlikely to
      be possible to hit this in practice. It theoretically affect EVA kernels
      on EVA capable cores with an L2 cache, where the icache fetches straight
      from RAM (cpu_icache_snoops_remote_store == 0), running a hard float
      userland with FPU disabled (nofpu). That both Malta and Boston platforms
      override cpu_icache_snoops_remote_store to 1 suggests that all MIPS
      cores fetch instructions into icache straight from L2 rather than RAM.
      
      Fixes: de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13800/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      0758b116
    • James Hogan's avatar
      MIPS: SMP: Drop stop_this_cpu() cpu_foreign_map hack · 92696316
      James Hogan authored
      Commit cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores")
      added the cpu_foreign_map cpumask containing a single VPE from each
      online core, and recalculated it when secondary CPUs are brought up.
      
      stop_this_cpu() was also updated to recalculate cpu_foreign_map, but
      with an additional hack before marking the CPU as offline to copy
      cpu_online_mask into cpu_foreign_map and perform an SMP memory barrier.
      
      This appears to have been intended to prevent cache management IPIs
      being missed when the VPE representing the core in cpu_foreign_map is
      taken offline while other VPEs remain online. Unfortunately there is
      nothing in this hack to prevent r4k_on_each_cpu() from reading the old
      cpu_foreign_map, and smp_call_function_many() from reading that new
      cpu_online_mask with the core's representative VPE marked offline. It
      then wouldn't send an IPI to any online VPEs of that core.
      
      stop_this_cpu() is only actually called in panic and system shutdown /
      halt / reboot situations, in which case all CPUs are going down and we
      don't really need to care about cache management, so drop this hack.
      
      Note that the __cpu_disable() case for CPU hotplug is handled in the
      previous commit, and no synchronisation is needed there due to the use
      of stop_machine() which prevents hotplug from taking place while any CPU
      has disabled preemption (as r4k_on_each_cpu() does).
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13796/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      92696316
    • James Hogan's avatar
      MIPS: SMP: Update cpu_foreign_map on CPU disable · 826e99be
      James Hogan authored
      When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated.
      This could result in cache management SMP calls being sent to offline
      CPUs instead of online siblings in the same core.
      
      Add a call to calculate_cpu_foreign_map() in the various MIPS cpu
      disable callbacks after set_cpu_online(). All cases are updated for
      consistency and to keep cpu_foreign_map strictly up to date, not just
      those which may support hardware multithreading.
      
      Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Hongliang Tao <taohl@lemote.com>
      Cc: Hua Yan <yanh@lemote.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13799/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      826e99be
    • James Hogan's avatar
      MIPS: SMP: Clear ASID without confusing has_valid_asid() · a05c3920
      James Hogan authored
      The SMP flush_tlb_*() functions may clear the memory map's ASIDs for
      other CPUs if the mm has only a single user (the current CPU) in order
      to avoid SMP calls. However this makes it appear to has_valid_asid(),
      which is used by various cache flush functions, as if the CPUs have
      never run in the mm, and therefore can't have cached any of its memory.
      
      For flush_tlb_mm() this doesn't sound unreasonable.
      
      flush_tlb_range() corresponds to flush_cache_range() which does do full
      indexed cache flushes, but only on the icache if the specified mapping
      is executable, otherwise it doesn't guarantee that there are no cache
      contents left for the mm.
      
      flush_tlb_page() corresponds to flush_cache_page(), which will perform
      address based cache ops on the specified page only, and also only
      touches the icache if the page is executable. It does not guarantee that
      there are no cache contents left for the mm.
      
      For example, this affects flush_cache_range() which uses the
      has_valid_asid() optimisation. It is required to flush the icache when
      mappings are made executable (e.g. using mprotect) so they are
      immediately usable. If some code is changed to non executable in order
      to be modified then it will not be flushed from the icache during that
      time, but the ASID on other CPUs may still be cleared for TLB flushing.
      When the code is changed back to executable, flush_cache_range() will
      assume the code hasn't run on those other CPUs due to the zero ASID, and
      won't invalidate the icache on them.
      
      This is fixed by clearing the other CPUs ASIDs to 1 instead of 0 for the
      above two flush_tlb_*() functions when the corresponding cache flushes
      are likely to be incomplete (non executable range flush, or any page
      flush). This ASID appears valid to has_valid_asid(), but still triggers
      ASID regeneration due to the upper ASID version bits being 0, which is
      less than the minimum ASID version of 1 and so always treated as stale.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13795/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      a05c3920
  5. 28 Jul, 2016 6 commits
  6. 24 Jul, 2016 7 commits