1. 05 Aug, 2019 12 commits
    • Junhua Huang's avatar
      arm64: mm: free the initrd reserved memblock in a aligned manner · 13776f9d
      Junhua Huang authored
      We should free the initrd reserved memblock in an aligned manner,
      because the initrd reserves the memblock in an aligned manner
      in arm64_memblock_init().
      Otherwise there are some fragments in memblock_reserved regions
      after free_initrd_mem(). e.g.:
      /sys/kernel/debug/memblock # cat reserved
         0: 0x0000000080080000..0x00000000817fafff
         1: 0x0000000083400000..0x0000000083ffffff
         2: 0x0000000090000000..0x000000009000407f
         3: 0x00000000b0000000..0x00000000b000003f
         4: 0x00000000b26184ea..0x00000000b2618fff
      The fragments like the ranges from b0000000 to b000003f and
      from b26184ea to b2618fff should be freed.
      
      And we can do free_reserved_area() after memblock_free(),
      as free_reserved_area() calls __free_pages(), once we've done
      that it could be allocated somewhere else,
      but memblock and iomem still say this is reserved memory.
      
      Fixes: 05c58752 ("arm64: To remove initrd reserved area entry from memblock")
      Signed-off-by: default avatarJunhua Huang <huang.junhua@zte.com.cn>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      13776f9d
    • Will Deacon's avatar
      arm64: io: Relax implicit barriers in default I/O accessors · 22ec7161
      Will Deacon authored
      The arm64 implementation of the default I/O accessors requires barrier
      instructions to satisfy the memory ordering requirements documented in
      memory-barriers.txt [1], which are largely derived from the behaviour of
      I/O accesses on x86.
      
      Of particular interest are the requirements that a write to a device
      must be ordered against prior writes to memory, and a read from a device
      must be ordered against subsequent reads from memory. We satisfy these
      requirements using various flavours of DSB: the most expensive barrier
      we have, since it implies completion of prior accesses. This was deemed
      necessary when we first implemented the accessors, since accesses to
      different endpoints could propagate independently and therefore the only
      way to enforce order is to rely on completion guarantees [2].
      
      Since then, the Armv8 memory model has been retrospectively strengthened
      to require "other-multi-copy atomicity", a property that requires memory
      accesses from an observer to become visible to all other observers
      simultaneously [3]. In other words, propagation of accesses is limited
      to transitioning from locally observed to globally observed. It recently
      became apparent that this change also has a subtle impact on our I/O
      accessors for shared peripherals, allowing us to use the cheaper DMB
      instruction instead.
      
      As a concrete example, consider the following:
      
      	memcpy(dma_buffer, data, bufsz);
      	writel(DMA_START, dev->ctrl_reg);
      
      A DMB ST instruction between the final write to the DMA buffer and the
      write to the control register will ensure that the writes to the DMA
      buffer are observed before the write to the control register by all
      observers. Put another way, if an observer can see the write to the
      control register, it can also see the writes to memory. This has always
      been the case and is not sufficient to provide the ordering required by
      Linux, since there is no guarantee that the master interface of the
      DMA-capable device has observed either of the accesses. However, in an
      other-multi-copy atomic world, we can infer two things:
      
        1. A write arriving at an endpoint shared between multiple CPUs is
           visible to all CPUs
      
        2. A write that is visible to all CPUs is also visible to all other
           observers in the shareability domain
      
      Pieced together, this allows us to use DMB OSHST for our default I/O
      write accessors and DMB OSHLD for our default I/O read accessors (the
      outer-shareability is for handling non-cacheable mappings) for shared
      devices. Memory-mapped, DMA-capable peripherals that are private to a
      CPU (i.e. inaccessible to other CPUs) still require the DSB, however
      these are few and far between and typically require special treatment
      anyway which is outside of the scope of the portable driver API (e.g.
      GIC, page-table walker, SPE profiler).
      
      Note that our mandatory barriers remain as DSBs, since there are cases
      where they are used to flush the store buffer of the CPU, e.g. when
      publishing page table updates to the SMMU.
      
      [1] https://git.kernel.org/linus/4614bbdee357
      [2] https://www.youtube.com/watch?v=i6DayghhA8Q
      [3] https://www.cl.cam.ac.uk/~pes20/armv8-mca/Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      22ec7161
    • Mark Brown's avatar
      arm64: Remove unused cpucap_multi_entry_cap_cpu_enable() · 2f8f180b
      Mark Brown authored
      The function cpucap_multi_entry_cap_cpu_enable() is unused, remove it to
      avoid any confusion reading the code and potential for bit rot.
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      2f8f180b
    • Will Deacon's avatar
      arm64: sysreg: Remove unused and rotting SCTLR_ELx field definitions · 73961dc1
      Will Deacon authored
      Our SCTLR_ELx field definitions are somewhat over-engineered in that
      they carefully define masks describing the RES0/RES1 bits and then use
      these to construct further masks representing bits to be set/cleared for
      the _EL1 and _EL2 registers.
      
      However, most of the resulting definitions aren't actually used by
      anybody and have subsequently started to bit-rot when new fields have
      been added by the architecture, resulting in fields being part of the
      RES0 mask despite being defined and used elsewhere.
      
      Rather than fix up these masks, simply remove the unused parts entirely
      so that we can drop the maintenance burden. We can always add things
      back if we need them in the future.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      73961dc1
    • Will Deacon's avatar
      arm64: esr: Add ESR exception class encoding for trapped ERET · 332e5281
      Will Deacon authored
      The ESR.EC encoding of 0b011010 (0x1a) describes an exception generated
      by an ERET, ERETAA or ERETAB instruction as a result of a nested
      virtualisation trap to EL2.
      
      Add an encoding for this EC and a string description so that we identify
      it correctly if we take one unexpectedly.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarMarc Zyngier <maz@kernel.org>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      332e5281
    • Chuhong Yuan's avatar
      arm64: Replace strncmp with str_has_prefix · b3e089cd
      Chuhong Yuan authored
      In commit b6b27355
      ("tracing: Use str_has_prefix() instead of using fixed sizes")
      the newly introduced str_has_prefix() was used
      to replace error-prone strncmp(str, const, len).
      Here fix codes with the same pattern.
      Signed-off-by: default avatarChuhong Yuan <hslester96@gmail.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      b3e089cd
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Rename arm_smmu_v3_set_proximity() 'node' local variable · 3e77eeb7
      Lorenzo Pieralisi authored
      Commit 36a2ba07 ("ACPI/IORT: Reject platform device creation on NUMA
      node mapping failure") introduced a local variable 'node' in
      arm_smmu_v3_set_proximity() that shadows the struct acpi_iort_node
      pointer function parameter.
      
      Execution was unaffected but it is prone to errors and can lead
      to subtle bugs.
      
      Rename the local variable to prevent any issue.
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Reported-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      3e77eeb7
    • Masahiro Yamada's avatar
      arm64: remove unneeded uapi/asm/stat.h · b717480f
      Masahiro Yamada authored
      stat.h is listed in include/uapi/asm-generic/Kbuild, so Kbuild will
      automatically generate it.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      b717480f
    • Bhupesh Sharma's avatar
      arm64/kexec: Use consistent convention of initializing 'kxec_buf.mem' with KEXEC_BUF_MEM_UNKNOWN · c19d050f
      Bhupesh Sharma authored
      With commit b6664ba4 ("s390, kexec_file: drop arch_kexec_mem_walk()"),
      we introduced the KEXEC_BUF_MEM_UNKNOWN macro. If kexec_buf.mem is set
      to this value, kexec_locate_mem_hole() will try to allocate free memory.
      
      While other arch(s) like s390 and x86_64 already use this macro to
      initialize kexec_buf.mem with, arm64 uses an equivalent value of 0.
      Replace it with KEXEC_BUF_MEM_UNKNOWN, to keep the convention of
      initializing 'kxec_buf.mem' consistent across various archs.
      
      Cc: takahiro.akashi@linaro.org
      Cc: james.morse@arm.com
      Reviewed-by: default avatarMatthias Brugger <mbrugger@suse.com>
      Signed-off-by: default avatarBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      c19d050f
    • Mark Rutland's avatar
      arm64: remove pointless __KERNEL__ guards · b907b80d
      Mark Rutland authored
      For a number of years, UAPI headers have been split from kernel-internal
      headers. The latter are never exposed to userspace, and always built
      with __KERNEL__ defined.
      
      Most headers under arch/arm64 don't have __KERNEL__ guards, but there
      are a few stragglers lying around. To make things more consistent, and
      to set a good example going forward, let's remove these redundant
      __KERNEL__ guards.
      
      In a couple of cases, a trailing #endif lacked a comment describing its
      corresponding #if or #ifdef, so these are fixes up at the same time.
      
      Guards in auto-generated crypto code are left as-is, as these guards are
      generated by scripting imported from the upstream openssl project
      scripts. Guards in UAPI headers are left as-is, as these can be included
      by userspace or the kernel.
      
      There should be no functional change as a result of this patch.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      b907b80d
    • Julien Thierry's avatar
      arm64: Remove unused assembly macro · c8785794
      Julien Thierry authored
      As of commit 4141c857 ("arm64: convert
      raw syscall invocation to C"), moving syscall handling from assembly to
      C, the macro mask_nospec64 is no longer referenced.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      c8785794
    • Linus Torvalds's avatar
      Linux 5.3-rc3 · e21a712a
      Linus Torvalds authored
      e21a712a
  2. 04 Aug, 2019 10 commits
  3. 03 Aug, 2019 18 commits