1. 19 7月, 2019 2 次提交
    • D
      mm/memory_hotplug: allow arch_remove_memory() without CONFIG_MEMORY_HOTREMOVE · 80ec922d
      David Hildenbrand 提交于
      We want to improve error handling while adding memory by allowing to use
      arch_remove_memory() and __remove_pages() even if
      CONFIG_MEMORY_HOTREMOVE is not set to e.g., implement something like:
      
      	arch_add_memory()
      	rc = do_something();
      	if (rc) {
      		arch_remove_memory();
      	}
      
      We won't get rid of CONFIG_MEMORY_HOTREMOVE for now, as it will require
      quite some dependencies for memory offlining.
      
      Link: http://lkml.kernel.org/r/20190527111152.16324-7-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NPavel Tatashin <pasha.tatashin@soleen.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Oscar Salvador <osalvador@suse.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
      Cc: Andrew Banman <andrew.banman@hpe.com>
      Cc: Arun KS <arunks@codeaurora.org>
      Cc: Qian Cai <cai@lca.pw>
      Cc: Mathieu Malaterre <malat@debian.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chintan Pandya <cpandya@codeaurora.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Jun Yao <yaojun8558363@gmail.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Yu Zhao <yuzhao@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80ec922d
    • D
      arm64/mm: add temporary arch_remove_memory() implementation · 22eb6346
      David Hildenbrand 提交于
      A proper arch_remove_memory() implementation is on its way, which also
      cleanly removes page tables in arch_add_memory() in case something goes
      wrong.
      
      As we want to use arch_remove_memory() in case something goes wrong
      during memory hotplug after arch_add_memory() finished, let's add a
      temporary hack that is sufficient enough until we get a proper
      implementation that cleans up page table entries.
      
      We will remove CONFIG_MEMORY_HOTREMOVE around this code in follow up
      patches.
      
      Link: http://lkml.kernel.org/r/20190527111152.16324-5-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Chintan Pandya <cpandya@codeaurora.org>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Jun Yao <yaojun8558363@gmail.com>
      Cc: Yu Zhao <yuzhao@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Anshuman Khandual <anshuman.khandual@arm.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Andrew Banman <andrew.banman@hpe.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arun KS <arunks@codeaurora.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Christophe Leroy <christophe.leroy@c-s.fr>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Mathieu Malaterre <malat@debian.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Oscar Salvador <osalvador@suse.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Qian Cai <cai@lca.pw>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      22eb6346
  2. 17 7月, 2019 4 次提交
  3. 15 7月, 2019 2 次提交
  4. 13 7月, 2019 4 次提交
  5. 08 7月, 2019 1 次提交
    • M
      KVM: arm/arm64: Initialise host's MPIDRs by reading the actual register · 1e0cf16c
      Marc Zyngier 提交于
      As part of setting up the host context, we populate its
      MPIDR by using cpu_logical_map(). It turns out that contrary
      to arm64, cpu_logical_map() on 32bit ARM doesn't return the
      *full* MPIDR, but a truncated version.
      
      This leaves the host MPIDR slightly corrupted after the first
      run of a VM, since we won't correctly restore the MPIDR on
      exit. Oops.
      
      Since we cannot trust cpu_logical_map(), let's adopt a different
      strategy. We move the initialization of the host CPU context as
      part of the per-CPU initialization (which, in retrospect, makes
      a lot of sense), and directly read the MPIDR from the HW. This
      is guaranteed to work on both arm and arm64.
      Reported-by: NAndre Przywara <Andre.Przywara@arm.com>
      Tested-by: NAndre Przywara <Andre.Przywara@arm.com>
      Fixes: 32f13955 ("arm/arm64: KVM: Statically configure the host's view of MPIDR")
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      1e0cf16c
  6. 05 7月, 2019 13 次提交
    • D
      KVM: arm64: Migrate _elx sysreg accessors to msr_s/mrs_s · fdec2a9e
      Dave Martin 提交于
      Currently, the {read,write}_sysreg_el*() accessors for accessing
      particular ELs' sysregs in the presence of VHE rely on some local
      hacks and define their system register encodings in a way that is
      inconsistent with the core definitions in <asm/sysreg.h>.
      
      As a result, it is necessary to add duplicate definitions for any
      system register that already needs a definition in sysreg.h for
      other reasons.
      
      This is a bit of a maintenance headache, and the reasons for the
      _el*() accessors working the way they do is a bit historical.
      
      This patch gets rid of the shadow sysreg definitions in
      <asm/kvm_hyp.h>, converts the _el*() accessors to use the core
      __msr_s/__mrs_s interface, and converts all call sites to use the
      standard sysreg #define names (i.e., upper case, with SYS_ prefix).
      
      This patch will conflict heavily anyway, so the opportunity
      to clean up some bad whitespace in the context of the changes is
      taken.
      
      The change exposes a few system registers that have no sysreg.h
      definition, due to msr_s/mrs_s being used in place of msr/mrs:
      additions are made in order to fill in the gaps.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoffer Dall <christoffer.dall@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: https://www.spinics.net/lists/kvm-arm/msg31717.html
      [Rebased to v4.21-rc1]
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      [Rebased to v5.2-rc5, changelog updates]
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      fdec2a9e
    • A
      KVM: arm/arm64: Add save/restore support for firmware workaround state · 99adb567
      Andre Przywara 提交于
      KVM implements the firmware interface for mitigating cache speculation
      vulnerabilities. Guests may use this interface to ensure mitigation is
      active.
      If we want to migrate such a guest to a host with a different support
      level for those workarounds, migration might need to fail, to ensure that
      critical guests don't loose their protection.
      
      Introduce a way for userland to save and restore the workarounds state.
      On restoring we do checks that make sure we don't downgrade our
      mitigation level.
      Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      99adb567
    • A
      arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests · c118bbb5
      Andre Przywara 提交于
      Recent commits added the explicit notion of "workaround not required" to
      the state of the Spectre v2 (aka. BP_HARDENING) workaround, where we
      just had "needed" and "unknown" before.
      
      Export this knowledge to the rest of the kernel and enhance the existing
      kvm_arm_harden_branch_predictor() to report this new state as well.
      Export this new state to guests when they use KVM's firmware interface
      emulation.
      Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      c118bbb5
    • A
      KVM: arm/arm64: Rename kvm_pmu_{enable/disable}_counter functions · 418e5ca8
      Andrew Murray 提交于
      The kvm_pmu_{enable/disable}_counter functions can enable/disable
      multiple counters at once as they operate on a bitmask. Let's
      make this clearer by renaming the function.
      Suggested-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NAndrew Murray <andrew.murray@arm.com>
      Reviewed-by: NJulien Thierry <julien.thierry@arm.com>
      Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      418e5ca8
    • J
      KVM: arm64: Skip more of the SError vaxorcism · 11b41626
      James Morse 提交于
      During __guest_exit() we need to consume any SError left pending by the
      guest so it doesn't contaminate the host. With v8.2 we use the
      ESB-instruction. For systems without v8.2, we use dsb+isb and unmask
      SError. We do this on every guest exit.
      
      Use the same dsb+isr_el1 trick, this lets us know if an SError is pending
      after the dsb, allowing us to skip the isb and self-synchronising PSTATE
      write if its not.
      
      This means SError remains masked during KVM's world-switch, so any SError
      that occurs during this time is reported by the host, instead of causing
      a hyp-panic.
      
      As we're benchmarking this code lets polish the layout. If you give gcc
      likely()/unlikely() hints in an if() condition, it shuffles the generated
      assembly so that the likely case is immediately after the branch. Lets
      do the same here.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      
      Changes since v2:
       * Added isb after the dsb to prevent an early read
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      11b41626
    • J
      KVM: arm64: Re-mask SError after the one instruction window · dad6321f
      James Morse 提交于
      KVM consumes any SError that were pending during guest exit with a
      dsb/isb and unmasking SError. It currently leaves SError unmasked for
      the rest of world-switch.
      
      This means any SError that occurs during this part of world-switch
      will cause a hyp-panic. We'd much prefer it to remain pending until
      we return to the host.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      dad6321f
    • J
      arm64: Update silicon-errata.txt for Neoverse-N1 #1349291 · 3276cc24
      James Morse 提交于
      Neoverse-N1 affected by #1349291 may report an Uncontained RAS Error
      as Unrecoverable. The kernel's architecture code already considers
      Unrecoverable errors as fatal as without kernel-first support no
      further error-handling is possible.
      
      Now that KVM attributes SError to the host/guest more precisely
      the host's architecture code will always handle host errors that
      become pending during world-switch.
      Errors misclassified by this errata that affected the guest will be
      re-injected to the guest as an implementation-defined SError, which can
      be uncontained.
      
      Until kernel-first support is implemented, no workaround is needed
      for this issue.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      3276cc24
    • J
      KVM: arm64: Defer guest entry when an asynchronous exception is pending · 5dcd0fdb
      James Morse 提交于
      SError that occur during world-switch's entry to the guest will be
      accounted to the guest, as the exception is masked until we enter the
      guest... but we want to attribute the SError as precisely as possible.
      
      Reading DISR_EL1 before guest entry requires free registers, and using
      ESB+DISR_EL1 to consume and read back the ESR would leave KVM holding
      a host SError... We would rather leave the SError pending and let the
      host take it once we exit world-switch. To do this, we need to defer
      guest-entry if an SError is pending.
      
      Read the ISR to see if SError (or an IRQ) is pending. If so fake an
      exit. Place this check between __guest_enter()'s save of the host
      registers, and restore of the guest's. SError that occur between
      here and the eret into the guest must have affected the guest's
      registers, which we can naturally attribute to the guest.
      
      The dsb is needed to ensure any previous writes have been done before
      we read ISR_EL1. On systems without the v8.2 RAS extensions this
      doesn't give us anything as we can't contain errors, and the ESR bits
      to describe the severity are all implementation-defined. Replace
      this with a nop for these systems.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      5dcd0fdb
    • J
      KVM: arm64: Consume pending SError as early as possible · 0e5b9c08
      James Morse 提交于
      On systems with v8.2 we switch the 'vaxorcism' of guest SError with an
      alternative sequence that uses the ESB-instruction, then reads DISR_EL1.
      This saves the unmasking and remasking of asynchronous exceptions.
      
      We do this after we've saved the guest registers and restored the
      host's. Any SError that becomes pending due to this will be accounted
      to the guest, when it actually occurred during host-execution.
      
      Move the ESB-instruction as early as possible. Any guest SError
      will become pending due to this ESB-instruction and then consumed to
      DISR_EL1 before the host touches anything.
      
      This lets us account for host/guest SError precisely on the guest
      exit exception boundary.
      
      Because the ESB-instruction now lands in the preamble section of
      the vectors, we need to add it to the unpatched indirect vectors
      too, and to any sequence that may be patched in over the top.
      
      The ESB-instruction always lives in the head of the vectors,
      to be before any memory write. Whereas the register-store always
      lives in the tail.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      0e5b9c08
    • J
      KVM: arm64: Make indirect vectors preamble behaviour symmetric · 5d994374
      James Morse 提交于
      The KVM indirect vectors support is a little complicated. Different CPUs
      may use different exception vectors for KVM that are generated at boot.
      Adding new instructions involves checking all the possible combinations
      do the right thing.
      
      To make changes here easier to review lets state what we expect of the
      preamble:
        1. The first vector run, must always run the preamble.
        2. Patching the head or tail of the vector shouldn't remove
           preamble instructions.
      
      Today, this is easy as we only have one instruction in the preamble.
      Change the unpatched tail of the indirect vector so that it always
      runs this, regardless of patching.
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      5d994374
    • J
      KVM: arm64: Abstract the size of the HYP vectors pre-amble · 3dbf100b
      James Morse 提交于
      The EL2 vector hardening feature causes KVM to generate vectors for
      each type of CPU present in the system. The generated sequences already
      do some of the early guest-exit work (i.e. saving registers). To avoid
      duplication the generated vectors branch to the original vector just
      after the preamble. This size is hard coded.
      
      Adding new instructions to the HYP vector causes strange side effects,
      which are difficult to debug as the affected code is patched in at
      runtime.
      
      Add KVM_VECTOR_PREAMBLE to tell kvm_patch_vector_branch() how big
      the preamble is. The valid_vect macro can then validate this at
      build time.
      Reviewed-by: NJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      3dbf100b
    • J
      arm64: assembler: Switch ESB-instruction with a vanilla nop if !ARM64_HAS_RAS · 2b68a2a9
      James Morse 提交于
      The ESB-instruction is a nop on CPUs that don't implement the RAS
      extensions. This lets us use it in places like the vectors without
      having to use alternatives.
      
      If someone disables CONFIG_ARM64_RAS_EXTN, this instruction still has
      its RAS extensions behaviour, but we no longer read DISR_EL1 as this
      register does depend on alternatives.
      
      This could go wrong if we want to synchronize an SError from a KVM
      guest. On a CPU that has the RAS extensions, but the KConfig option
      was disabled, we consume the pending SError with no chance of ever
      reading it.
      
      Hide the ESB-instruction behind the CONFIG_ARM64_RAS_EXTN option,
      outputting a regular nop if the feature has been disabled.
      Reported-by: NJulien Thierry <julien.thierry@arm.com>
      Signed-off-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      2b68a2a9
    • Z
      KVM: arm64/sve: Fix vq_present() macro to yield a bool · e644fa18
      Zhang Lei 提交于
      The original implementation of vq_present() relied on aggressive
      inlining in order for the compiler to know that the code is
      correct, due to some const-casting issues.  This was causing sparse
      and clang to complain, while GCC compiled cleanly.
      
      Commit 0c529ff7 addressed this problem, but since vq_present()
      is no longer a function, there is now no implicit casting of the
      returned value to the return type (bool).
      
      In set_sve_vls(), this uncast bit value is compared against a bool,
      and so may spuriously compare as unequal when both are nonzero.  As
      a result, KVM may reject valid SVE vector length configurations as
      invalid, and vice versa.
      
      Fix it by forcing the returned value to a bool.
      Signed-off-by: NZhang Lei <zhang.lei@jp.fujitsu.com>
      Fixes: 0c529ff7 ("KVM: arm64: Implement vq_present() as a macro")
      Signed-off-by: Dave Martin <Dave.Martin@arm.com> [commit message rewrite]
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e644fa18
  7. 04 7月, 2019 1 次提交
  8. 03 7月, 2019 2 次提交
    • A
      crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR · 7367bfeb
      Ard Biesheuvel 提交于
      This implements 5-way interleaving for ECB, CBC decryption and CTR,
      resulting in a speedup of ~11% on Marvell ThunderX2, which has a
      very deep pipeline and therefore a high issue latency for NEON
      instructions operating on the same registers.
      
      Note that XTS is left alone: implementing 5-way interleave there
      would either involve spilling of the calculated tweaks to the
      stack, or recalculating them after the encryption operation, and
      doing either of those would most likely penalize low end cores.
      
      For ECB, this is not a concern at all, given that we have plenty
      of spare registers. For CTR and CBC decryption, we take advantage
      of the fact that v16 is not used by the CE version of the code
      (which is the only one targeted by the optimization), and so we
      can reshuffle the code a bit and avoid having to spill to memory
      (with the exception of one extra reload in the CBC routine)
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7367bfeb
    • A
      crypto: arm64/aes-ce - add 5 way interleave routines · e2174139
      Ard Biesheuvel 提交于
      In preparation of tweaking the accelerated AES chaining mode routines
      to be able to use a 5-way stride, implement the core routines to
      support processing 5 blocks of input at a time. While at it, drop
      the 2 way versions, which have been unused for a while now.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      e2174139
  9. 01 7月, 2019 1 次提交
  10. 28 6月, 2019 2 次提交
  11. 27 6月, 2019 8 次提交
    • J
      arm_pmu: acpi: spe: Add initial MADT/SPE probing · d24a0c70
      Jeremy Linton 提交于
      ACPI 6.3 adds additional fields to the MADT GICC
      structure to describe SPE PPI's. We pick these out
      of the cached reference to the madt_gicc structure
      similarly to the core PMU code. We then create a platform
      device referring to the IRQ and let the user/module loader
      decide whether to load the SPE driver.
      Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
      Reviewed-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      d24a0c70
    • V
      arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire · e1d9149e
      Vicente Bergas 提交于
      Before this patch, the Type-C port on the Sapphire board is dead.
      If setting the 'regulator-always-on' property to 'vcc5v0_typec0'
      then the port works for about 4 seconds at start-up. This is a
      sample trace with a memory stick plugged in:
      1.- The memory stick LED lights on and kernel reports:
      [    4.782999] scsi 0:0:0:0: Direct-Access USB DISK PMAP PQ: 0 ANSI: 4
      [    5.904580] sd 0:0:0:0: [sdb] 3913344 512-byte logical blocks: (2.00 GB/1.87 GiB)
      [    5.906860] sd 0:0:0:0: [sdb] Write Protect is off
      [    5.908973] sd 0:0:0:0: [sdb] Mode Sense: 23 00 00 00
      [    5.909122] sd 0:0:0:0: [sdb] No Caching mode page found
      [    5.911214] sd 0:0:0:0: [sdb] Assuming drive cache: write through
      [    5.951585]  sdb: sdb1
      [    5.954816] sd 0:0:0:0: [sdb] Attached SCSI removable disk
      2.- 4 seconds later the memory stick LED lights off and kernel reports:
      [    9.082822] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER
      3.- After a minute the kernel reports:
      [   71.666761] usb 5-1: USB disconnect, device number 2
      It has been checked that, although the LED is off, VBUS is present.
      
      If, instead, the dr_mode is changed to host and the phy-supply changed
      accordingly, then it works. It has only been tested in host mode.
      Signed-off-by: NVicente Bergas <vicencb@gmail.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      e1d9149e
    • E
      arm64: dts: rockchip: Update DWC3 modules on RK3399 SoCs · e6d237fd
      Enric Balletbo i Serra 提交于
      As per binding documentation [1], the DWC3 core should have the "ref",
      "bus_early" and "suspend" clocks. As explained in the binding, those
      clocks are required for new platforms but not for existing platforms
      before commit fe8abf33 ("usb: dwc3: support clocks and resets for
      DWC3 core").
      
      However, as those clocks are really treated as required, this ends with
      having some annoying messages when the "rockchip,rk3399-dwc3" is used:
      
      [    1.724107] dwc3 fe800000.dwc3: Failed to get clk 'ref': -2
      [    1.731893] dwc3 fe900000.dwc3: Failed to get clk 'ref': -2
      [    2.495937] dwc3 fe800000.dwc3: Failed to get clk 'ref': -2
      [    2.647239] dwc3 fe900000.dwc3: Failed to get clk 'ref': -2
      
      In order to remove those annoying messages, update the DWC3 hardware
      module node and add all the required clocks. With this change, both, the
      glue node and the DWC3 core node, have the clocks defined, but that's
      not really a problem and there isn't a side effect on do this. So, we
      can get rid of the annoying get clk error messages.
      
      [1] Documentation/devicetree/bindings/usb/dwc3.txt
      Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      e6d237fd
    • L
      arm64: dts: rockchip: enable rk3328 watchdog clock · c9a8af80
      Leonidas P. Papadakos 提交于
      Add the missing clock property for the watchdog on rk3328.
      Signed-off-by: NLeonidas P. Papadakos <papadakospan@gmail.com>
      [set wdt node to always enabled, as it is not board-specific]
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      c9a8af80
    • V
      arm64: dts: rockchip: Add support for Hugsun X99 TV Box · 3222bcf5
      Vivek Unune 提交于
      Add devicetree support for Hugsun X99 TV Box based on RK3399 SoC
      
      Tested with LibreElec running kernel v5.1.2.
      Following peripherals tested and work:
      
      Peripheral works:
      - UART2 debug
      - eMMC
      - USB 3.0 port
      - USB 2.0 port
      - sdio, sd-card
      - HDMI
      - Ethernet
      - WiFi/BT
      
      Not tested:
      - Type-C port
      - OPTICAL
      - IR
      Signed-off-by: NVivek Unune <npcomplete13@gmail.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      3222bcf5
    • D
      arm64: dts: rockchip: Define values for the IPA governor for rock960 · cd21c54a
      Daniel Lezcano 提交于
      Currently the default thermal values for the rk3399-rock960 board is
      inherited from the generic definition in rk3399.dtsi.
      
      In order to ensure the rock960 has more room for througput before
      being capped by the thermal framework and is correctly supported by
      the IPA governor, let's define the power values and the right trip
      points for better performances:
      
       - sustainable power is tested to be 1550mW
      
       - increase the first mitigation point to 75°C in order to get better
         performances
      
       - the first trip point is 65°C in order to let the IPA to collect
         enough data for the PID regulation when it reaches 75°C
      
       - restrict the cooling device to the big CPUs as the little CPUs
         contribution to the heating effect can be considered negligible
      
      The intelligent power allocator PID coefficient to be set in sysfs
      are:
      
          k_d: 0
          k_po: 79
          k_i: 10
          k_pu: 50
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      cd21c54a
    • D
      arm64: dts: rockchip: Fix multiple thermal zones conflict in rk3399.dtsi · 95f231f8
      Daniel Lezcano 提交于
      Currently the common thermal zones definitions for the rk3399 assumes
      multiple thermal zones are supported by the governors. This is not the
      case and each thermal zone has its own governor instance acting
      individually without collaboration with other governors.
      
      As the cooling device for the CPU and the GPU thermal zones is the
      same, each governors take different decisions for the same cooling
      device leading to conflicting instructions and an erratic behavior.
      
      As the cooling-maps is about to become an optional property, let's
      remove the cpu cooling device map from the GPU thermal zone.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      95f231f8
    • J
      arm64: dts: rockchip: add core dtsi file for RK3399Pro SoCs · 587b4ee2
      Jianqun Xu 提交于
      This patch adds core dtsi file for Rockchip RK3399Pro SoCs,
      include rk3399.dtsi. Also enable pciei0/pcie_phy for AP to
      talk to NPU part inside SoC.
      Signed-off-by: NJianqun Xu <jay.xu@rock-chips.com>
      Acked-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      587b4ee2