Currently, maximum physical memory allowed is equal to -PAGE_OFFSET.
That's why we remove any memory blocks spanning beyond that size. However,
it is done only for memblock containing linux kernel which will not work
if there are multiple memblocks.

Process all memory blocks to figure out how much memory needs to be removed
and remove at the end instead of updating the memblock list in place.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

Currently, initrd_start/end are computed during early_init_dt_scan
but used during arch_setup. We will get the following panic if initrd is used
and CONFIG_DEBUG_VIRTUAL is turned on.

[    0.000000] ------------[ cut here ]------------
[    0.000000] kernel BUG at arch/riscv/mm/physaddr.c:33!
[    0.000000] Kernel BUG [#1]
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc4-00015-ged0b226fed02 #886
[    0.000000] epc: ffffffe0002058d2 ra : ffffffe0000053f0 sp : ffffffe001001f40
[    0.000000]  gp : ffffffe00106e250 tp : ffffffe001009d40 t0 : ffffffe00107ee28
[    0.000000]  t1 : 0000000000000000 t2 : ffffffe000a2e880 s0 : ffffffe001001f50
[    0.000000]  s1 : ffffffe0001383e8 a0 : ffffffe00c087e00 a1 : 0000000080200000
[    0.000000]  a2 : 00000000010bf000 a3 : ffffffe00106f3c8 a4 : ffffffe0010bf000
[    0.000000]  a5 : ffffffe000000000 a6 : 0000000000000006 a7 : 0000000000000001
[    0.000000]  s2 : ffffffe00106f068 s3 : ffffffe00106f070 s4 : 0000000080200000
[    0.000000]  s5 : 0000000082200000 s6 : 0000000000000000 s7 : 0000000000000000
[    0.000000]  s8 : 0000000080011010 s9 : 0000000080012700 s10: 0000000000000000
[    0.000000]  s11: 0000000000000000 t3 : 000000000001fe30 t4 : 000000000001fe30
[    0.000000]  t5 : 0000000000000000 t6 : ffffffe00107c471
[    0.000000] status: 0000000000000100 badaddr: 0000000000000000 cause: 0000000000000003
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x22/0x46 with crng_init=0

To avoid the error, initrd_start/end can be computed from phys_initrd_start/size
in setup itself. It also improves the initrd placement by aligning the start
and size with the page size.

Fixes: 76d2a049 ("RISC-V: Init and Halt Code")
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

Currently, maximum number of mapper pages are set to the pfn calculated
from the memblock size of the memblock containing kernel. This will work
until that memblock spans the entire memory. However, it will be set to
a wrong value if there are multiple memblocks defined in kernel
(e.g. with efi runtime services).

Set the the maximum value to the pfn calculated from dram size.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

It fails to boot the v5.8-rc4 kernel with CONFIG_KASAN because kasan_init
and kasan_early_init use uninitialized __sbi_rfence as executing the
tlb_flush_all(). Actually, at this moment, only the CPU which is
responsible for the system initialization enables the MMU. Other CPUs are
parking at the .Lsecondary_start. Hence the tlb_flush_all() is able to be
replaced by local_tlb_flush_all() to avoid using uninitialized
__sbi_rfence.
Signed-off-by: NVincent Chen <vincent.chen@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

vmlinux-objs-y is added to targets, which currently means that the EFI
stub gets added to the targets as well. It shouldn't be added since it
is built elsewhere.

This confuses Makefile.build which interprets the EFI stub as a target
	$(obj)/$(objtree)/drivers/firmware/efi/libstub/lib.a
and will create drivers/firmware/efi/libstub/ underneath
arch/x86/boot/compressed, to hold this supposed target, if building
out-of-tree. [0]

Fix this by pulling the stub out of vmlinux-objs-y into efi-obj-y.

[0] See scripts/Makefile.build near the end:
    # Create directories for object files if they do not exist
Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NMasahiro Yamada <masahiroy@kernel.org>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Link: https://lkml.kernel.org/r/20200715032631.1562882-1-nivedita@alum.mit.edu

Some builds of GCC enable stack protector by default. Simply removing
the arguments is not sufficient to disable stack protector, as the stack
protector for those GCC builds must be explicitly disabled. Remove the
argument removals and add -fno-stack-protector. Additionally include
missed x32 argument updates, and adjust whitespace for readability.

Fixes: 20355e5f ("x86/entry: Exclude low level entry code from sanitizing")
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/202006261333.585319CA6B@keescook

tss_invalidate_io_bitmap() wasn't wired up properly through the pvop
machinery, so the TSS and Xen's io bitmap would get out of sync
whenever disabling a valid io bitmap.

Add a new pvop for tss_invalidate_io_bitmap() to fix it.

This is XSA-329.

Fixes: 22fe5b04 ("x86/ioperm: Move TSS bitmap update to exit to user work")
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NJuergen Gross <jgross@suse.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/d53075590e1f91c19f8af705059d3ff99424c020.1595030016.git.luto@kernel.org

Setting interrupt affinity on inactive interrupts is inconsistent when
hierarchical irq domains are enabled. The core code should just store the
affinity and not call into the irq chip driver for inactive interrupts
because the chip drivers may not be in a state to handle such requests.

X86 has a hacky workaround for that but all other irq chips have not which
causes problems e.g. on GIC V3 ITS.

Instead of adding more ugly hacks all over the place, solve the problem in
the core code. If the affinity is set on an inactive interrupt then:

    - Store it in the irq descriptors affinity mask
    - Update the effective affinity to reflect that so user space has
      a consistent view
    - Don't call into the irq chip driver

This is the core equivalent of the X86 workaround and works correctly
because the affinity setting is established in the irq chip when the
interrupt is activated later on.

Note, that this is only effective when hierarchical irq domains are enabled
by the architecture. Doing it unconditionally would break legacy irq chip
implementations.

For hierarchial irq domains this works correctly as none of the drivers can
have a dependency on affinity setting in inactive state by design.

Remove the X86 workaround as it is not longer required.

Fixes: 02edee15 ("x86/apic/vector: Ignore set_affinity call for inactive interrupts")
Reported-by: NAli Saidi <alisaidi@amazon.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NAli Saidi <alisaidi@amazon.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200529015501.15771-1-alisaidi@amazon.com
Link: https://lkml.kernel.org/r/877dv2rv25.fsf@nanos.tec.linutronix.de

While digging through the recent mmiowb preemption issue it came up that
we aren't actually preventing IO from crossing a scheduling boundary.
While it's a bit ugly to overload smp_mb__after_spinlock() with this
behavior, it's what PowerPC is doing so there's some precedent.
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

The clang integrated assembler requires the 'cmp' instruction to
have a length prefix here:

arch/x86/math-emu/wm_sqrt.S:212:2: error: ambiguous instructions require an explicit suffix (could be 'cmpb', 'cmpw', or 'cmpl')
 cmp $0xffffffff,-24(%ebp)
 ^

Make this a 32-bit comparison, which it was clearly meant to be.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Link: https://lkml.kernel.org/r/20200527135352.1198078-1-arnd@arndb.de

When assembling with Clang via `make LLVM_IAS=1` and CONFIG_HYPERV enabled,
we observe the following error:

<instantiation>:9:6: error: expected absolute expression
 .if HYPERVISOR_REENLIGHTENMENT_VECTOR == 3
     ^
<instantiation>:1:1: note: while in macro instantiation
idtentry HYPERVISOR_REENLIGHTENMENT_VECTOR asm_sysvec_hyperv_reenlightenment sysvec_hyperv_reenlightenment has_error_code=0
^
./arch/x86/include/asm/idtentry.h:627:1: note: while in macro instantiation
idtentry_sysvec HYPERVISOR_REENLIGHTENMENT_VECTOR sysvec_hyperv_reenlightenment;
^
<instantiation>:9:6: error: expected absolute expression
 .if HYPERVISOR_STIMER0_VECTOR == 3
     ^
<instantiation>:1:1: note: while in macro instantiation
idtentry HYPERVISOR_STIMER0_VECTOR asm_sysvec_hyperv_stimer0 sysvec_hyperv_stimer0 has_error_code=0
^
./arch/x86/include/asm/idtentry.h:628:1: note: while in macro instantiation
idtentry_sysvec HYPERVISOR_STIMER0_VECTOR sysvec_hyperv_stimer0;

This is caused by typos in arch/x86/include/asm/idtentry.h:

HYPERVISOR_REENLIGHTENMENT_VECTOR -> HYPERV_REENLIGHTENMENT_VECTOR
HYPERVISOR_STIMER0_VECTOR         -> HYPERV_STIMER0_VECTOR

For more details see ClangBuiltLinux issue #1088.

Fixes: a16be368 ("x86/entry: Convert various hypervisor vectors to IDTENTRY_SYSVEC")
Suggested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NWei Liu <wei.liu@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1088
Link: https://github.com/ClangBuiltLinux/linux/issues/1043
Link: https://lore.kernel.org/patchwork/patch/1272115/
Link: https://lkml.kernel.org/r/20200714194740.4548-1-sedat.dilek@gmail.com

Clang's integrated assembler does not allow symbols with non-absolute
values to be reassigned. Modify the interrupt entry loop macro to be
compatible with IAS by using a label and an offset.
Reported-by: NNick Desaulniers <ndesaulniers@google.com>
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Suggested-by: NNick Desaulniers <ndesaulniers@google.com>
Suggested-by: NBrian Gerst <brgerst@gmail.com>
Suggested-by: NArvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: NJian Cai <caij2003@gmail.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> #
Link: https://github.com/ClangBuiltLinux/linux/issues/1043
Link: https://lkml.kernel.org/r/20200714233024.1789985-1-caij2003@gmail.com

Rather than open-code test_tsk_thread_flag() at each callsite, simply
replace the couple of offenders with calls to test_tsk_thread_flag()
directly.
Signed-off-by: NWill Deacon <will@kernel.org>

Setting a system call number of -1 is special, as it indicates that the
current system call should be skipped.

Use NO_SYSCALL instead of -1 when checking for this scenario, which is
different from the -1 returned due to a seccomp failure.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Keno Fischer <keno@juliacomputing.com>
Cc: Luis Machado <luis.machado@linaro.org>
Signed-off-by: NWill Deacon <will@kernel.org>

If a task executes syscall(-1), we intercept this early and force x0 to
be -ENOSYS so that we don't need to distinguish this scenario from one
where the scno is -1 because a tracer wants to skip the system call
using ptrace. With the return value set, the return path is the same as
the skip case.

Although there is a one-line comment noting this in el0_svc_common(), it
misses out most of the detail. Expand the comment to describe a bit more
about what is going on.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Keno Fischer <keno@juliacomputing.com>
Cc: Luis Machado <luis.machado@linaro.org>
Signed-off-by: NWill Deacon <will@kernel.org>

Our tracehook logic for syscall entry/exit raises a SIGTRAP back to the
tracer following a ptrace request such as PTRACE_SYSCALL. As part of this
procedure, we clobber the reported value of one of the tracee's general
purpose registers (x7 for native tasks, r12 for compat) to indicate
whether the stop occurred on syscall entry or exit. This is a slightly
unfortunate ABI, as it prevents the tracer from accessing the real
register value and is at odds with other similar stops such as seccomp
traps.

Since we're stuck with this ABI, expand the comment in our tracehook
logic to acknowledge the issue and describe the behaviour in more detail.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Luis Machado <luis.machado@linaro.org>
Reported-by: NKeno Fischer <keno@juliacomputing.com>
Signed-off-by: NWill Deacon <will@kernel.org>

Although we zero the upper bits of x0 on entry to the kernel from an
AArch32 task, we do not clear them on the exception return path and can
therefore expose 64-bit sign extended syscall return values to userspace
via interfaces such as the 'perf_regs' ABI, which deal exclusively with
64-bit registers.

Explicitly clear the upper 32 bits of x0 on return from a compat system
call.

Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Keno Fischer <keno@juliacomputing.com>
Cc: Luis Machado <luis.machado@linaro.org>
Signed-off-by: NWill Deacon <will@kernel.org>

Luis reports that, when reverse debugging with GDB, single-step does not
function as expected on arm64:

  | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP
  | request by GDB won't execute the underlying instruction. As a consequence,
  | the PC doesn't move, but we return a SIGTRAP just like we would for a
  | regular successful PTRACE_SINGLESTEP request.

The underlying problem is that when the CPU register state is restored
as part of a reverse step, the SPSR.SS bit is cleared and so the hardware
single-step state can transition to the "active-pending" state, causing
an unexpected step exception to be taken immediately if a step operation
is attempted.

In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate
accessible by the GPR regset, but it's a bit late for that now. Instead,
simply prevent userspace from configuring the bit to a value which is
inconsistent with the TIF_SINGLESTEP state for the task being traced.

Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Keno Fischer <keno@juliacomputing.com>
Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.orgReported-by: NLuis Machado <luis.machado@linaro.org>
Tested-by: NLuis Machado <luis.machado@linaro.org>
Signed-off-by: NWill Deacon <will@kernel.org>

Although the arm64 single-step state machine can be fast-forwarded in
cases where we wish to generate a SIGTRAP without actually executing an
instruction, this has two major limitations outside of simply skipping
an instruction due to emulation.

1. Stepping out of a ptrace signal stop into a signal handler where
   SIGTRAP is blocked. Fast-forwarding the stepping state machine in
   this case will result in a forced SIGTRAP, with the handler reset to
   SIG_DFL.

2. The hardware implicitly fast-forwards the state machine when executing
   an SVC instruction for issuing a system call. This can interact badly
   with subsequent ptrace stops signalled during the execution of the
   system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt
   the stepping state by updating the PSTATE for the tracee.

Resolve both of these issues by injecting a pseudo-singlestep exception
on entry to a signal handler and also on return to userspace following a
system call.

Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Tested-by: NLuis Machado <luis.machado@linaro.org>
Reported-by: NKeno Fischer <keno@juliacomputing.com>
Signed-off-by: NWill Deacon <will@kernel.org>

Fix dtschema validator warnings like:
    intc@fffc1000: $nodename:0:
        'intc@fffc1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$'

Fixes: 78cd6a9d ("arm64: dts: Add base stratix 10 dtsi")
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>

Fix dtschema validator warnings like:
    l2-cache@fffff000: $nodename:0:
        'l2-cache@fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$'

Fixes: 475dc86d ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC")
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>

Match the QSPI reg address in the socfpga_stratix10_socdk.dts file.

Fixes: 80f132d7 ("arm64: dts: increase the QSPI reg address for Stratix10 and Agilex")
Cc: linux-stable <stable@vger.kernel.org> # >= v5.6
Signed-off-by: NDinh Nguyen <dinh.nguyen@intel.com>

Add status = "okay" to QSPI node.

Fixes: 0cb140d0 ("arm64: dts: stratix10: Add QSPI support for Stratix10")
Cc: linux-stable <stable@vger.kernel.org> # >= v5.6
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>

Add status = "okay" to QSPI node.

Fixes: c4c8757b ("arm64: dts: agilex: add QSPI support for Intel Agilex")
Cc: linux-stable <stable@vger.kernel.org> # >= v5.5
Signed-off-by: NDinh Nguyen <dinguyen@kernel.org>

P9 DD2 NX workbook (Table 4-36) says DMA controller uses CC=5
internally for translation fault handling. NX reserves CC=250 for
OS to notify user space when NX encounters address translation
failure on the request buffer. Not an issue in earlier releases
as NX does not get faults on kernel addresses.

This patch defines CSB_CC_FAULT_ADDRESS(250) and updates CSB.CC with
this proper error code for user space.

Fixes: c96c4436 ("powerpc/vas: Update CSB and notify process for fault CRBs")
Signed-off-by: NHaren Myneni <haren@linux.ibm.com>
[mpe: Added Fixes tag and fix typo in comment]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/019fd53e7538c6f8f332d175df74b1815ef5aa8c.camel@linux.ibm.com

With the current 8KB stack size there are frequent overflows in a 64-bit
configuration.  We may split IRQ stacks off in the future, but this fixes a
number of issues right now.
Signed-off-by: NAndreas Schwab <schwab@suse.de>
Reviewed-by: NAnup Patel <anup@brainfault.org>
[Palmer: mention irqstack in the commit text]
Fixes: 7db91e57 ("RISC-V: Task implementation")
Cc: stable@vger.kernel.org
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

Quite some non OF/ACPI users of irqdomains allocate firmware nodes of type
IRQCHIP_FWNODE_NAMED or IRQCHIP_FWNODE_NAMED_ID and free them right after
creating the irqdomain. The only purpose of these FW nodes is to convey
name information. When this was introduced the core code did not store the
pointer to the node in the irqdomain. A recent change stored the firmware
node pointer in irqdomain for other reasons and missed to notice that the
usage sites which do the alloc_fwnode/create_domain/free_fwnode sequence
are broken by this. Storing a dangling pointer is dangerous itself, but in
case that the domain is destroyed later on this leads to a double free.

Remove the freeing of the firmware node after creating the irqdomain from
all affected call sites to cure this.

Fixes: 711419e5 ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode")
Reported-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NMarc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/873661qakd.fsf@nanos.tec.linutronix.de

Got following d_can probe errors with kernel 5.8-rc1 on am437x

[   10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[  OK  ] Reached target Network.
[   10.787363] c_can_platform 481cc000.can: probe failed
[   10.792484] c_can_platform: probe of 481cc000.can failed with error -2
[   10.799457] c_can_platform 481d0000.can: probe failed
[   10.804617] c_can_platform: probe of 481d0000.can failed with error -2

actually, Tony has fixed this issue on am335x with the patch [3]

Since am437x has the same clock structure with am335x
[1][2], so reuse the code from Tony Lindgren's patch [3] to fix it.

[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
     Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
     Integration
[3]: commit 516f1117 ("ARM: dts: Configure osc clock for d_can on
     am335x")

Fixes: 1a5cd7c2 ("bus: ti-sysc: Enable all clocks directly during init to read revision")
Signed-off-by: Ndillon min <dillon.minfei@gmail.com>
[tony@atomide.com: aligned commit message a bit for readability]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix memory leak in omap_hwmod_allocate_module not freeing in
handling error path.

Fixes: 8c879705("ARM: OMAP2+: Add functions to allocate module data from device tree")
Signed-off-by: NChen Tao <chentao107@huawei.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
[tony@atomide.com: fix call iounmap for missing regs]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Early secure guest boot hits the below crash while booting with
vcpus numbers aligned with page boundary for PAGE size of 64k
and LPPACA size of 1k i.e 64, 128 etc.

  Partition configured for 64 cpus.
  CPU maps initialized for 1 thread per core
  ------------[ cut here ]------------
  kernel BUG at arch/powerpc/kernel/paca.c:89!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries

This is due to the BUG_ON() for shared_lppaca_total_size equal to
shared_lppaca_size. Instead the code should only BUG_ON() if we have
exceeded the total_size, which indicates we've overflowed the array.

Fixes: bd104e6d ("powerpc/pseries/svm: Use shared memory for LPPACA structures")
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: NSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Reviewed-by: NLaurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: NThiago Jung Bauermann <bauerman@linux.ibm.com>
[mpe: Reword change log to clarify we're fixing not removing the check]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200619070113.16696-1-sathnaga@linux.vnet.ibm.com

config option PCIE_RCAR internally selects PCIE_RCAR_HOST which builds
the same driver. So this patch renames CONFIG_PCIE_RCAR to
CONFIG_PCIE_RCAR_HOST so that PCIE_RCAR can be safely dropped from
Kconfig file.
Signed-off-by: NLad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1589494238-2933-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>

Even if the IAMR value denies execute access, the current code returns
true from pkey_access_permitted() for an execute permission check, if
the AMR read pkey bit is cleared.

This results in repeated page fault loop with a test like below:

  #define _GNU_SOURCE
  #include <errno.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <signal.h>
  #include <inttypes.h>

  #include <assert.h>
  #include <malloc.h>
  #include <unistd.h>
  #include <pthread.h>
  #include <sys/mman.h>

  #ifdef SYS_pkey_mprotect
  #undef SYS_pkey_mprotect
  #endif

  #ifdef SYS_pkey_alloc
  #undef SYS_pkey_alloc
  #endif

  #ifdef SYS_pkey_free
  #undef SYS_pkey_free
  #endif

  #undef PKEY_DISABLE_EXECUTE
  #define PKEY_DISABLE_EXECUTE	0x4

  #define SYS_pkey_mprotect	386
  #define SYS_pkey_alloc		384
  #define SYS_pkey_free		385

  #define PPC_INST_NOP		0x60000000
  #define PPC_INST_BLR		0x4e800020
  #define PROT_RWX		(PROT_READ | PROT_WRITE | PROT_EXEC)

  static int sys_pkey_mprotect(void *addr, size_t len, int prot, int pkey)
  {
  	return syscall(SYS_pkey_mprotect, addr, len, prot, pkey);
  }

  static int sys_pkey_alloc(unsigned long flags, unsigned long access_rights)
  {
  	return syscall(SYS_pkey_alloc, flags, access_rights);
  }

  static int sys_pkey_free(int pkey)
  {
  	return syscall(SYS_pkey_free, pkey);
  }

  static void do_execute(void *region)
  {
  	/* jump to region */
  	asm volatile(
  		"mtctr	%0;"
  		"bctrl"
  		: : "r"(region) : "ctr", "lr");
  }

  static void do_protect(void *region)
  {
  	size_t pgsize;
  	int i, pkey;

  	pgsize = getpagesize();

  	pkey = sys_pkey_alloc(0, PKEY_DISABLE_EXECUTE);
  	assert (pkey > 0);

  	/* perform mprotect */
  	assert(!sys_pkey_mprotect(region, pgsize, PROT_RWX, pkey));
  	do_execute(region);

  	/* free pkey */
  	assert(!sys_pkey_free(pkey));

  }

  int main(int argc, char **argv)
  {
  	size_t pgsize, numinsns;
  	unsigned int *region;
  	int i;

  	/* allocate memory region to protect */
  	pgsize = getpagesize();
  	region = memalign(pgsize, pgsize);
  	assert(region != NULL);
  	assert(!mprotect(region, pgsize, PROT_RWX));

  	/* fill page with NOPs with a BLR at the end */
  	numinsns = pgsize / sizeof(region[0]);
  	for (i = 0; i < numinsns - 1; i++)
  		region[i] = PPC_INST_NOP;
  	region[i] = PPC_INST_BLR;

  	do_protect(region);

  	return EXIT_SUCCESS;
  }

The fix is to only check the IAMR for an execute check, the AMR value
is not relevant.

Fixes: f2407ef3 ("powerpc: helper to validate key-access permissions of a pte")
Cc: stable@vger.kernel.org # v4.16+
Reported-by: NSandipan Das <sandipan@linux.ibm.com>
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
[mpe: Add detail to change log, tweak wording & formatting]
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200712132047.1038594-1-aneesh.kumar@linux.ibm.com

No callers of imx_add_imx_dma() need an error IRQ, so they supply 0 as
"irq_err", which means we register a resource of IRQ 0, which is invalid
and causes a warning if used.

Remove the "irq_err" argument altogether so there's no chance of trying to
use the invalid IRQ 0.

Fixes: a85a6c86 ("driver core: platform: Clarify that IRQ 0 is invalid")
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: kernel@pengutronix.de
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-imx@nxp.com
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Since commit a85a6c86 ("driver core: platform: Clarify that IRQ 0 is
invalid"), the kernel is a bit touchy when it encounters interrupt 0.
As a result, there are lots of warnings such as the following when booting
systems such as 'kzm'.

WARNING: CPU: 0 PID: 1 at drivers/base/platform.c:224 platform_get_irq_optional+0x118/0x128
0 is an invalid IRQ number
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3 #1
Hardware name: Kyoto Microcomputer Co., Ltd. KZM-ARM11-01
[<c01127d4>] (unwind_backtrace) from [<c010c620>] (show_stack+0x10/0x14)
[<c010c620>] (show_stack) from [<c06f5f54>] (dump_stack+0xe8/0x120)
[<c06f5f54>] (dump_stack) from [<c0128878>] (__warn+0xe4/0x108)
[<c0128878>] (__warn) from [<c0128910>] (warn_slowpath_fmt+0x74/0xbc)
[<c0128910>] (warn_slowpath_fmt) from [<c08b8e84>] (platform_get_irq_optional+0x118/0x128)
[<c08b8e84>] (platform_get_irq_optional) from [<c08b8eb4>] (platform_irq_count+0x20/0x3c)
[<c08b8eb4>] (platform_irq_count) from [<c0728660>] (mxc_gpio_probe+0x8c/0x494)
[<c0728660>] (mxc_gpio_probe) from [<c08b93cc>] (platform_drv_probe+0x48/0x98)
[<c08b93cc>] (platform_drv_probe) from [<c08b703c>] (really_probe+0x214/0x344)
[<c08b703c>] (really_probe) from [<c08b7274>] (driver_probe_device+0x58/0xb4)
[<c08b7274>] (driver_probe_device) from [<c08b7478>] (device_driver_attach+0x58/0x60)
[<c08b7478>] (device_driver_attach) from [<c08b7504>] (__driver_attach+0x84/0xc0)
[<c08b7504>] (__driver_attach) from [<c08b50f8>] (bus_for_each_dev+0x78/0xb8)
[<c08b50f8>] (bus_for_each_dev) from [<c08b62cc>] (bus_add_driver+0x154/0x1e0)
[<c08b62cc>] (bus_add_driver) from [<c08b82b8>] (driver_register+0x74/0x108)
[<c08b82b8>] (driver_register) from [<c0102320>] (do_one_initcall+0x80/0x3b4)
[<c0102320>] (do_one_initcall) from [<c1501008>] (kernel_init_freeable+0x170/0x208)
[<c1501008>] (kernel_init_freeable) from [<c0e178d4>] (kernel_init+0x8/0x11c)
[<c0e178d4>] (kernel_init) from [<c0100134>] (ret_from_fork+0x14/0x20)

As it turns out, mxc_register_gpio() is a bit lax when setting the
number of resources: it registers a resource with interrupt 0 when in
reality there is no such interrupt. Fix the problem by not declaring
the second interrupt resource if there is no second interrupt.

Fixes: a85a6c86 ("driver core: platform: Clarify that IRQ 0 is invalid")
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

The audio codec on the GW551x routes to ssi1.  It fixes audio capture on
the device.

Cc: stable@vger.kernel.org
Fixes: 3117e851 ("ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x")
Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

CONFIG_CC_IS_GCC is undefined when Clang is used, which breaks the build
(see our Travis link below).

Clang 8 was chosen as a minimum version for this check because there
were some improvements around __builtin_constant_p in that release. In
reality, MIPS was not even buildable until clang 9 so that check was not
technically necessary. Just remove all compiler checks and just assume
that we have a working compiler.

Fixes: d4e60453 ("Restore gcc check in mips asm/unroll.h")
Link: https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/359642821Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit dc6d95b1 ("KVM: MIPS: Add more MMIO load/store
instructions emulation") introduced some 64bit load/store instructions
emulation which are unavailable on 32bit platform, and it causes build
errors:

arch/mips/kvm/emulate.c: In function 'kvm_mips_emulate_store':
arch/mips/kvm/emulate.c:1734:6: error: right shift count >= width of type [-Werror]
      ((vcpu->arch.gprs[rt] >> 56) & 0xff);
      ^
arch/mips/kvm/emulate.c:1738:6: error: right shift count >= width of type [-Werror]
      ((vcpu->arch.gprs[rt] >> 48) & 0xffff);
      ^
arch/mips/kvm/emulate.c:1742:6: error: right shift count >= width of type [-Werror]
      ((vcpu->arch.gprs[rt] >> 40) & 0xffffff);
      ^
arch/mips/kvm/emulate.c:1746:6: error: right shift count >= width of type [-Werror]
      ((vcpu->arch.gprs[rt] >> 32) & 0xffffffff);
      ^
arch/mips/kvm/emulate.c:1796:6: error: left shift count >= width of type [-Werror]
      (vcpu->arch.gprs[rt] << 32);
      ^
arch/mips/kvm/emulate.c:1800:6: error: left shift count >= width of type [-Werror]
      (vcpu->arch.gprs[rt] << 40);
      ^
arch/mips/kvm/emulate.c:1804:6: error: left shift count >= width of type [-Werror]
      (vcpu->arch.gprs[rt] << 48);
      ^
arch/mips/kvm/emulate.c:1808:6: error: left shift count >= width of type [-Werror]
      (vcpu->arch.gprs[rt] << 56);
      ^
cc1: all warnings being treated as errors
make[3]: *** [arch/mips/kvm/emulate.o] Error 1

So, use #if defined(CONFIG_64BIT) && defined(CONFIG_KVM_MIPS_VZ) to
guard the 64bit load/store instructions emulation.
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: dc6d95b1 ("KVM: MIPS: Add more MMIO load/store instructions emulation")
Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Message-Id: <1594365797-536-1-git-send-email-chenhc@lemote.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit 850448f3 ("KVM: nVMX: Fix VMX preemption timer migration",
2020-06-01) accidentally broke nVMX live migration from older version
by changing the userspace ABI.  Restore it and, while at it, ensure
that vmx->nested.has_preemption_timer_deadline is always initialized
according to the KVM_STATE_VMX_PREEMPTION_TIMER_DEADLINE flag.

Cc: Makarand Sonare <makarandsonare@google.com>
Fixes: 850448f3 ("KVM: nVMX: Fix VMX preemption timer migration")
Reviewed-by: NJim Mattson <jmattson@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The constant arrays in gdb_xml.h are only used in arch/riscv/kernel/kgdb.c,
but other c files may include the gdb_xml.h indirectly via including the
kgdb.h. Hence, It will cause many unused-const-variable warnings. This
patch makes the kgdb.h not to include the gdb_xml.h to solve this problem.
Signed-off-by: NVincent Chen <vincent.chen@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>

Currently, only riscv kgdb.c uses the kgdb_has_hit_break() to identify
the kgdb breakpoint. It causes other architectures will encounter the "no
previous prototype" warnings if the compile option has W=1. Moving the
declaration of extern kgdb_has_hit_break() from risc-v kgdb.h to generic
kgdb.h to avoid generating these warnings.
Signed-off-by: NVincent Chen <vincent.chen@sifive.com>
Acked-by: NDaniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>