kvm_memslots() will be called by kvm_write_guest_offset_cached() so we should
take the srcu lock. Let's pull the srcu lock operation from kvm_steal_time_set_preempted()
again to fix xen part.

Fixes: 30b5c851 ("KVM: x86/xen: Add support for vCPU runstate information")
Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
Message-Id: <1619166200-9215-1-git-send-email-wanpengli@tencent.com>
Reviewed-by: NSean Christopherson <seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Newer Xen versions expose two Xen feature flags to tell us if the domain
is directly mapped or not. Only when a domain is directly mapped it
makes sense to enable swiotlb-xen on ARM.

Introduce a function on ARM to check the new Xen feature flags and also
to deal with the legacy case. Call the function xen_swiotlb_detect.
Signed-off-by: NStefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20210319200140.12512-1-sstabellini@kernel.orgSigned-off-by: NJuergen Gross <jgross@suse.com>

Take a pass at cleaning up a bunch of warnings
from 'make dtbs_check' that have crept in.
Signed-off-by: NKevin Hilman <khilman@baylibre.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210421204833.18523-1-khilman@baylibre.com'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

irq_create_strict_mappings() is a poor way to allow the use of
a linear IRQ domain as a legacy one. Let's be upfront about
it and use a legacy domain when appropriate.
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210406093557.1073423-3-maz@kernel.org

GIC CPU interfaces versions predating GIC v4.1 were not built to
accommodate vINTID within the vSGI range; as reported in the GIC
specifications (8.2 "Changes to the CPU interface"), it is
CONSTRAINED UNPREDICTABLE to deliver a vSGI to a PE with
ID_AA64PFR0_EL1.GIC < b0011.

Check the GIC CPUIF version by reading the SYS_ID_AA64_PFR0_EL1.

Disable vSGIs if a CPUIF version < 4.1 is detected to prevent using
vSGIs on systems where they may misbehave.
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210317100719.3331-2-lorenzo.pieralisi@arm.com

The only stepping of Broadwell Xeon parts is stepping 1. Fix the
relevant isolation_ucodes[] entry, which previously enumerated
stepping 2.

Although the original commit was characterized as an optimization, it
is also a workaround for a correctness issue.

If a PMI arrives between kvm's call to perf_guest_get_msrs() and the
subsequent VM-entry, a stale value for the IA32_PEBS_ENABLE MSR may be
restored at the next VM-exit. This is because, unbeknownst to kvm, PMI
throttling may clear bits in the IA32_PEBS_ENABLE MSR. CPUs with "PEBS
isolation" don't suffer from this issue, because perf_guest_get_msrs()
doesn't report the IA32_PEBS_ENABLE value.

Fixes: 9b545c04 ("perf/x86/kvm: Avoid unnecessary work in guest filtering")
Signed-off-by: NJim Mattson <jmattson@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NPeter Shier <pshier@google.com>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Link: https://lkml.kernel.org/r/20210422001834.1748319-1-jmattson@google.com

Commit 941432d0 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.

This was based on the observation that the Pine64-LTS has as "push-push"
SD card socket, and that the schematic mentions the card detect GPIO.

After having received two reports about failing SD card access with that
patch, some more research and polls on that subject revealed that there
are at least two different versions of the Pine64-LTS out there:
- On some boards (including mine) the card detect pin is "stuck" at
  high, regardless of an microSD card being inserted or not.
- On other boards the card-detect is working, but is active-high, by
  virtue of an explicit inverter circuit, as shown in the schematic.

To cover all versions of the board out there, and don't take any chances,
let's revert the introduction of the active-low CD GPIO, but let's use
the broken-cd property for the Pine64-LTS this time. That should avoid
regressions and should work for everyone, even allowing SD card changes
now.
The SOPine card detect has proven to be working, so let's keep that
GPIO in place.

Fixes: 941432d0 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
Reported-by: NMichael Weiser <michael.weiser@gmx.de>
Reported-by: NDaniel Kulesz <kuleszdl@posteo.org>
Suggested-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMichael Weiser <michael.weiser@gmx.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210414104740.31497-1-andre.przywara@arm.com

There may be a kernel panic on the Haswell server and the Broadwell
server, if the snbep_pci2phy_map_init() return error.

The uncore_extra_pci_dev[HSWEP_PCI_PCU_3] is used in the cpu_init() to
detect the existence of the SBOX, which is a MSR type of PMON unit.
The uncore_extra_pci_dev is allocated in the uncore_pci_init(). If the
snbep_pci2phy_map_init() returns error, perf doesn't initialize the
PCI type of the PMON units, so the uncore_extra_pci_dev will not be
allocated. But perf may continue initializing the MSR type of PMON
units. A null dereference kernel panic will be triggered.

The sockets in a Haswell server or a Broadwell server are identical.
Only need to detect the existence of the SBOX once.
Current perf probes all available PCU devices and stores them into the
uncore_extra_pci_dev. It's unnecessary.
Use the pci_get_device() to replace the uncore_extra_pci_dev. Only
detect the existence of the SBOX on the first available PCU device once.

Factor out hswep_has_limit_sbox(), since the Haswell server and the
Broadwell server uses the same way to detect the existence of the SBOX.

Add some macros to replace the magic number.

Fixes: 5306c31c ("perf/x86/uncore/hsw-ep: Handle systems with only two SBOXes")
Reported-by: NSteve Wahl <steve.wahl@hpe.com>
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: NSteve Wahl <steve.wahl@hpe.com>
Link: https://lkml.kernel.org/r/1618521764-100923-1-git-send-email-kan.liang@linux.intel.com

There is not a consistent pattern for checking Hyper-V hypercall status.
Existing code uses a number of variants.  The variants work, but a consistent
pattern would improve the readability of the code, and be more conformant
to what the Hyper-V TLFS says about hypercall status.

Implemented new helper functions hv_result(), hv_result_success(), and
hv_repcomp().  Changed the places where hv_do_hypercall() and related variants
are used to use the helper functions.
Signed-off-by: NJoseph Salisbury <joseph.salisbury@microsoft.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1618620183-9967-2-git-send-email-joseph.salisbury@linux.microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

This patch makes no functional changes.  It simply moves hv_do_rep_hypercall()
out of arch/x86/include/asm/mshyperv.h and into asm-generic/mshyperv.h

hv_do_rep_hypercall() is architecture independent, so it makes sense that it
should be in the architecture independent mshyperv.h, not in the x86-specific
mshyperv.h.

This is done in preperation for a follow up patch which creates a consistent
pattern for checking Hyper-V hypercall status.
Signed-off-by: NJoseph Salisbury <joseph.salisbury@microsoft.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/1618620183-9967-1-git-send-email-joseph.salisbury@linux.microsoft.comSigned-off-by: NWei Liu <wei.liu@kernel.org>

Commit in Fixes: added support for kexec-ing a kernel on panic using a
new system call. As part of it, it does prepare a memory map for the new
kernel.

However, while doing so, it wrongly accesses memory it has not
allocated: it accesses the first element of the cmem->ranges[] array in
memmap_exclude_ranges() but it has not allocated the memory for it in
crash_setup_memmap_entries(). As KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
  Write of size 8 at addr ffffc90000426008 by task kexec/1187

  (gdb) list *crash_setup_memmap_entries+0x17e
  0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322).
  317                                      unsigned long long mend)
  318     {
  319             unsigned long start, end;
  320
  321             cmem->ranges[0].start = mstart;
  322             cmem->ranges[0].end = mend;
  323             cmem->nr_ranges = 1;
  324
  325             /* Exclude elf header region */
  326             start = image->arch.elf_load_addr;
  (gdb)

Make sure the ranges array becomes a single element allocated.

 [ bp: Write a proper commit message. ]

Fixes: dd5f7260 ("kexec: support for kexec on panic using new system call")
Signed-off-by: NMike Galbraith <efault@gmx.de>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NDave Young <dyoung@redhat.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/725fa3dc1da2737f0f6188a1a9701bead257ea9d.camel@gmx.de

The !CONFIG_KEXEC_CORE code in arch/x86/platform/uv/uv_nmi.c was unused, untested
and didn't even build for 7 years. Since we fixed this by requiring X86_UV to
depend on CONFIG_KEXEC_CORE, remove the (now) dead code.

Also move the uv_nmi_kexec_failed definition back up to where the other file-scope
global variables are defined.
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Cc: Mike Travis <travis@sgi.com>
Cc: linux-kernel@vger.kernel.org

When KEXEC is disabled, the UV build fails:

  arch/x86/platform/uv/uv_nmi.c:875:14: error: ‘uv_nmi_kexec_failed’ undeclared (first use in this function)

Since uv_nmi_kexec_failed is only defined in the KEXEC_CORE #ifdef branch,
this code cannot ever have been build tested:

	if (main)
		pr_err("UV: NMI kdump: KEXEC not supported in this kernel\n");
	atomic_set(&uv_nmi_kexec_failed, 1);

Nor is this use possible in uv_handle_nmi():

                atomic_set(&uv_nmi_kexec_failed, 0);

These bugs were introduced in this commit:

    d0a9964e: ("x86/platform/uv: Implement simple dump failover if kdump fails")

Which added the uv_nmi_kexec_failed assignments to !KEXEC code, while making the
definition KEXEC-only - apparently without testing the !KEXEC case.

Instead of complicating the #ifdef maze, simplify the code by requiring X86_UV
to depend on KEXEC_CORE. This pattern is present in other architectures as well.

( We'll remove the untested, 7 years old !KEXEC complications from the file in a
  separate commit. )

Fixes: d0a9964e: ("x86/platform/uv: Implement simple dump failover if kdump fails")
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Cc: Mike Travis <travis@sgi.com>
Cc: linux-kernel@vger.kernel.org

Update iommu property in lpass cpu node for supporting
simultaneous playback on headset and speaker.
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NV Sujith Kumar Reddy <vsujithk@codeaurora.org>
Signed-off-by: NSrinivasa Rao Mandadapu <srivasam@codeaurora.org>
Link: https://lore.kernel.org/r/20210406163330.11996-1-srivasam@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Match what's downstream for this board.
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Ajit Pandey <ajitp@codeaurora.org>
Cc: Judy Hsiao <judyhsiao@chromium.org>
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210315133924.v2.2.If218189eff613a6c48ba12d75fad992377d8f181@changeidSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

This was present downstream. Add upstream too. NOTE: upstream I
managed to get some sort of halfway state and got one pinctrl entry in
the coachz-r1 device tree. Remove that as part of this since it's now
in the dtsi.
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Ajit Pandey <ajitp@codeaurora.org>
Cc: Judy Hsiao <judyhsiao@chromium.org>
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210315133924.v2.1.I601a051cad7cfd0923e55b69ef7e5748910a6096@changeidSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

M5Stack are releasing a new widget based on the
SigmaStar SSD202D. We have some support for the
SSD202D so lets add a dts for it.
Signed-off-by: NDaniel Palmer <daniel@0x0f.com>
Link: https://m5stack-store.myshopify.com/products/unitv2-ai-camera-gc2145
Link: https://lore.kernel.org/r/20210417011015.2105280-4-daniel@0x0f.com'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Fix unit names to make dtbs_check happy.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210414144643.17435-2-matthias.bgg@kernel.org
Link: https://lore.kernel.org/r/20210416143923.23406-3-matthias.bgg@kernel.org'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Fix unit names to make dtbs_check happy.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210414144643.17435-1-matthias.bgg@kernel.org
Link: https://lore.kernel.org/r/20210416143923.23406-2-matthias.bgg@kernel.org'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Fix a regression caused by making the 486SX separately selectable in
Kconfig, for which the HIGHMEM64G setting has not been updated and
therefore has become exposed as a user-selectable option for the M486SX
configuration setting unlike with original M486 and all the other
settings that choose non-PAE-enabled processors:

  High Memory Support
  > 1. off (NOHIGHMEM)
    2. 4GB (HIGHMEM4G)
    3. 64GB (HIGHMEM64G)
  choice[1-3?]:

With the fix in place the setting is now correctly removed:

  High Memory Support
  > 1. off (NOHIGHMEM)
    2. 4GB (HIGHMEM4G)
  choice[1-2?]:

 [ bp: Massage commit message. ]

Fixes: 87d6021b ("x86/math-emu: Limit MATH_EMULATION to 486SX compatibles")
Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org # v5.5+
Link: https://lkml.kernel.org/r/alpine.DEB.2.21.2104141221340.44318@angie.orcam.me.uk

Fix the following coccicheck warning:

./arch/m68k/include/asm/sun3xflop.h:109:2-3: Unneeded semicolon
Signed-off-by: NWan Jiabing <wanjiabing@vivo.com>
Link: https://lore.kernel.org/r/20210415031450.23379-1-wanjiabing@vivo.comSigned-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Since uprobes is not supported for thumb, check that the thumb bit is
not set when matching the uprobes instruction hooks.

The Arm UDF instructions used for uprobes triggering
(UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the
same encoding as a pair of unallocated 32-bit thumb instructions (not
UDF) when the condition code is 0b1111 (0xf). This in effect makes it
possible to trigger the uprobes functionality from thumb, and at that
using two unallocated instructions which are not permanently undefined.
Signed-off-by: NFredrik Strupe <fredrik@strupe.net>
Cc: stable@vger.kernel.org
Fixes: c7edc9e3 ("ARM: add uprobes support")
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Fix IA64 discontig.c Section mismatch warnings.

When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions
computer_pernodesize() and scatter_node_data() should not be marked as
__meminit because they are needed after init, on any memory hotplug
event.  Also, early_nr_cpus_node() is called by compute_pernodesize(),
so early_nr_cpus_node() cannot be __meminit either.

  WARNING: modpost: vmlinux.o(.text.unlikely+0x1612): Section mismatch in reference from the function arch_alloc_nodedata() to the function .meminit.text:compute_pernodesize()
  The function arch_alloc_nodedata() references the function __meminit compute_pernodesize().
  This is often because arch_alloc_nodedata lacks a __meminit annotation or the annotation of compute_pernodesize is wrong.

  WARNING: modpost: vmlinux.o(.text.unlikely+0x1692): Section mismatch in reference from the function arch_refresh_nodedata() to the function .meminit.text:scatter_node_data()
  The function arch_refresh_nodedata() references the function __meminit scatter_node_data().
  This is often because arch_refresh_nodedata lacks a __meminit annotation or the annotation of scatter_node_data is wrong.

  WARNING: modpost: vmlinux.o(.text.unlikely+0x1502): Section mismatch in reference from the function compute_pernodesize() to the function .meminit.text:early_nr_cpus_node()
  The function compute_pernodesize() references the function __meminit early_nr_cpus_node().
  This is often because compute_pernodesize lacks a __meminit annotation or the annotation of early_nr_cpus_node is wrong.

Link: https://lkml.kernel.org/r/20210411001201.3069-1-rdunlap@infradead.orgSigned-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Mike Rapoport <rppt@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix ia64 generic_defconfig duplicate entries, as warned by:

  arch/ia64/configs/generic_defconfig: warning: override: reassigning to symbol ATA:  => 58
  arch/ia64/configs/generic_defconfig: warning: override: reassigning to symbol ATA_PIIX:  => 59

These 2 symbols still have the same value as in the removed lines.

Link: https://lkml.kernel.org/r/20210411020255.18052-1-rdunlap@infradead.org
Fixes: c331649e ("ia64: Use libata instead of the legacy ide driver in defconfigs")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in
arch/csky/Kconfig.

The symbol in e1000 has been around longer, so change arch/csky/ to use
DRAM_BASE instead of RAM_BASE to remove the conflict.  (although e1000
is also a 2-line change)

Link: https://lkml.kernel.org/r/20210411055335.7111-1-rdunlap@infradead.orgSigned-off-by: NRandy Dunlap <rdunlap@infradead.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Acked-by: NGuo Ren <guoren@kernel.org>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
instrumentation, but we should only need one config, so that we remove
CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable.  see [1].

When enable KASAN stack instrumentation, then for gcc we could do no
prompt and default value y, and for clang prompt and default value n.

This patch fixes the following compilation warning:

  include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not defined, evaluates to 0 [-Wundef]

[akpm@linux-foundation.org: fix merge snafu]

Link: https://bugzilla.kernel.org/show_bug.cgi?id=210221 [1]
Link: https://lkml.kernel.org/r/20210226012531.29231-1-walter-zh.wu@mediatek.com
Fixes: d9b571c8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
Signed-off-by: NWalter Wu <walter-zh.wu@mediatek.com>
Suggested-by: NDmitry Vyukov <dvyukov@google.com>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NAndrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Debian's clang carries a patch that makes the default FPU mode
'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON
instructions on hardware that does not support them:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch
https://bugs.debian.org/841474
https://bugs.debian.org/842142
https://bugs.debian.org/914268

This results in the following build error when clang's integrated
assembler is used because the '.arch' directive overrides the '.fpu'
directive:

arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON
 vmov.i32 q0, #1
 ^
arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON
 vshr.u64 q1, q0, #7
 ^
arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON
 vshr.u64 q0, q0, #8
 ^
arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON
 vmov.i32 d4, #19
 ^

Shuffle the order of the '.arch' and '.fpu' directives so that the code
builds regardless of the default FPU mode. This has been tested against
both clang with and without Debian's patch and GCC.

Cc: stable@vger.kernel.org
Fixes: d8f1308a ("crypto: arm/curve25519 - wire up NEON implementation")
Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118Reported-by: NArnd Bergmann <arnd@arndb.de>
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Suggested-by: NJessica Clarke <jrtc27@jrtc27.com>
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Acked-by: NJason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The new carry handling code in the CTR driver can deal with a carry
occurring in the 4x/5x parallel code path, by using a computed goto to
jump into the carry sequence at the right place as to only apply the
carry to a subset of the blocks being processed.

If the lower half of the counter wraps and ends up at exactly 0x0, a
carry needs to be applied to the counter, but not to the counter values
taken for the 4x/5x parallel sequence. In this case, the computed goto
skips all register assignments, and branches straight to the jump
instruction that gets us back to the fast path. This produces the
correct result, but due to the fact that this branch target does not
carry the correct BTI annotation, this fails when BTI is enabled.

Let's omit the computed goto entirely in this case, and jump straight
back to the fast path after applying the carry to the main counter.

Fixes: 5318d3db ("crypto: arm64/aes-ctr - improve tail handling")
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add call to run_crash_ipi_callback() to gather more info of what the
secondary CPUs were doing to help with failure analysis.

Excerpt from Georges:

'It is only changing where crash secondaries will be stalling after
having taken care of properly laying down "crash note regs". Please
note that "crash note regs" are a key piece of data used by crash dump
debuggers to provide a reliable backtrace of running processors.'

Secondary change pursuant to

  a5f526ec ("CodingStyle: Inclusive Terminology"):

change master/slave to main/secondary.

 [ bp: Massage commit message. ]
Signed-off-by: NGeorges Aureau <georges.aureau@hpe.com>
Signed-off-by: NMike Travis <mike.travis@hpe.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NSteve Wahl <steve.wahl@hpe.com>
Link: https://lkml.kernel.org/r/20210311151028.82678-1-mike.travis@hpe.com

BIOS now sets the x2apic enabled bit (and the ACPI table) for extended
APIC modes. Use that bit to indicate if extended mode is set.

 [ bp: Fixup subject prefix, merge subsequent fix
   https://lkml.kernel.org/r/20210415220626.223955-1-mike.travis@hpe.com ]
Signed-off-by: NMike Travis <mike.travis@hpe.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210408160047.1703-1-mike.travis@hpe.com

Current riscv's kprobe handlers are run with both preemption and
interrupt enabled, this violates kprobe requirements. Fix this issue
by keeping interrupts disabled for BREAKPOINT exception.

Fixes: c22b0bcb ("riscv: Add kprobes supported")
Cc: stable@vger.kernel.org
Signed-off-by: NJisheng Zhang <jszhang@kernel.org>
Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
[Palmer: add a comment]
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

Currently, the riscv's kprobes(powerred by ftrace) handler is
preemptible. Futher check indicates we miss something similar as the
commit c536aa1c ("kprobes/ftrace: Add recursion protection to the
ftrace callback"), so do similar modifications as the commit does.

Fixes: 829adda5 ("riscv: Add KPROBES_ON_FTRACE supported")
Cc: stable@vger.kernel.org
Signed-off-by: NJisheng Zhang <jszhang@kernel.org>
Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

These two functions are used to implement the kprobes feature so they
can't be kprobed.

Fixes: c22b0bcb ("riscv: Add kprobes supported")
Cc: stable@vger.kernel.org
Signed-off-by: NJisheng Zhang <jszhang@kernel.org>
Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

There is a spelling mistake when SPARSEMEM Kconfig copy.

Fixes: a5406a7f ("riscv: Correct SPARSEMEM configuration")
Cc: stable@vger.kernel.org
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

The ADM1278 IC is accessible on I2C bus and on both Wiwynn and Quanta
Tioga Pass implementations a pair of parallel 0.5 mOhm resistors is used
for current measurement.
Signed-off-by: NPaul Fertser <fercerpav@gmail.com>
Link: https://lore.kernel.org/r/20210415140521.11352-1-fercerpav@gmail.comSigned-off-by: NJoel Stanley <joel@jms.id.au>

Enable all I2C busses that are used in AMD EthanolX CRB:
 i2c0 - APML P0
 i2c1 - APML P1
 i2c2 - FPGA
 i2c3 - 24LC128 EEPROM
 i2c4 - P0 Power regulators
 i2c5 - P1 Power regulators
 i2c6 - P0/P1 Thermal diode
 i2c7 - Thermal Sensors
 i2c8 - BMC I2C
Signed-off-by: NKonstantin Aladyshev <aladyshev22@gmail.com>
Link: https://lore.kernel.org/r/20210415155300.1135-1-aladyshev22@gmail.comSigned-off-by: NJoel Stanley <joel@jms.id.au>

Add the muxes present in pass 2 and remove the eeproms that were
removed.
Signed-off-by: NEddie James <eajames@linux.ibm.com>
Signed-off-by: NJoel Stanley <joel@jms.id.au>

The 1S4U system populates fans 0, 1, 2, and 4. Update the dts to
reflect this.

Fixes: 7f03894a ("ARM: dts: aspeed: Add Rainier 1S4U machine")
Signed-off-by: NEddie James <eajames@linux.ibm.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NJoel Stanley <joel@jms.id.au>

The si7021 was incorrectly placed at 0x20 on i2c bus 7. It is at 0x40.

Fixes: 9c44db70 ("ARM: dts: aspeed: rainier: Add i2c devices")
Signed-off-by: NEddie James <eajames@linux.ibm.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NJoel Stanley <joel@jms.id.au>

The second presence detection PCA9552 was incorrectly added to bus 9.

Fixes: 8be44de6 ("ARM: dts: aspeed: Rainier: Add presence GPIOs")
Signed-off-by: NEddie James <eajames@linux.ibm.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NJoel Stanley <joel@jms.id.au>