Pull RISC-V fixes from Palmer Dabbelt:
 "A handful of fixes:

   - a fix to properly select SPARSEMEM_STATIC on rv32

   - a few fixes to kprobes

  I don't generally like sending stuff this late, but these all seem
  pretty safe"

* tag 'riscv-for-linus-5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: keep interrupts disabled for BREAKPOINT exception
  riscv: kprobes/ftrace: Add recursion protection to the ftrace callback
  riscv: add do_page_fault and do_trap_break into the kprobes blacklist
  riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"

Pull arm64 fix from Catalin Marinas:
 "Fix kernel compilation when using the LLVM integrated assembly.

  A recent commit (2decad92, "arm64: mte: Ensure TIF_MTE_ASYNC_FAULT
  is set atomically") broke the kernel build when using the LLVM
  integrated assembly (only noticeable with clang-12 as MTE is not
  supported by earlier versions and the code in question not compiled).
  The Fixes: tag in the commit refers to the original patch introducing
  subsections for the alternative code sequences"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: alternatives: Move length validation in alternative_{insn, endif}

Pull drm fixes from Daniel Vetter:
 "I pinged the usual suspects, only intel fixes pending"

* tag 'drm-fixes-2021-04-16' of git://anongit.freedesktop.org/drm/drm:
  drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel
  drm/i915: Don't zero out the Y plane's watermarks
  drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT

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: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
[Palmer: add a comment]
Signed-off-by: Palmer 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: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Palmer 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: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Palmer 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: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>

Pull ACPI fix from Rafael Wysocki:
 "Restore the initrd-based ACPI table override functionality broken by
  one of the recent fixes"

* tag 'acpi-5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()

Pull gpio fix from Bartosz Golaszewski:
 "A single fix for an older problem with the sysfs interface: do not
  allow exporting GPIO lines which were marked invalid by the driver"

* tag 'gpio-fixes-for-v5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpio: sysfs: Obey valid_mask

Pull HID fixes from Jiri Kosina:
 "The changes are all device/driver specific fixes:

   - EV_KEY and EV_ABS regression fix for Wacom from Ping Cheng

   - BIOS-specific quirk to fix some of the AMD_SFH-based systems, from
     Hans de Goede

   - other small error handling fixes and device ID additions"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
  HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices
  AMD_SFH: Add DMI quirk table for BIOS-es which don't set the activestatus bits
  AMD_SFH: Add sensor_mask module parameter
  AMD_SFH: Removed unused activecontrolstatus member from the amd_mp2_dev struct
  HID: wacom: Assign boolean values to a bool variable
  HID cp2112: fix support for multiple gpiochips
  HID: alps: fix error return code in alps_input_configured()
  HID: asus: Add support for 2021 ASUS N-Key keyboard
  HID: google: add don USB id

After commit 2decad92 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
set atomically"), LLVM's integrated assembler fails to build entry.S:

<instantiation>:5:7: error: expected assembly-time absolute expression
 .org . - (664b-663b) + (662b-661b)
      ^
<instantiation>:6:7: error: expected assembly-time absolute expression
 .org . - (662b-661b) + (664b-663b)
      ^

The root cause is LLVM's assembler has a one-pass design, meaning it
cannot figure out these instruction lengths when the .org directive is
outside of the subsection that they are in, which was changed by the
.arch_extension directive added in the above commit.

Apply the same fix from commit 966a0acc ("arm64/alternatives: move
length validation inside the subsection") to the alternative_endif
macro, shuffling the .org directives so that the length validation
happen will always happen in the same subsections. alternative_insn has
not shown any issue yet but it appears that it could have the same issue
in the future so just preemptively change it.

Fixes: f7b93d42 ("arm64/alternatives: use subsections for replacement sequences")
Cc: <stable@vger.kernel.org> # 5.8.x
Link: https://github.com/ClangBuiltLinux/linux/issues/1347Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20210414000803.662534-1-nathan@kernel.orgSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>

Pull input fixes from Dmitry Torokhov:
 "Just a few driver fixes here"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: elants_i2c - drop zero-checking of ABS_MT_TOUCH_MAJOR resolution
  Input: elants_i2c - fix division by zero if firmware reports zero phys size
  Input: nspire-keypad - enable interrupts only when opened
  Input: i8042 - fix Pegatron C15B ID entry
  Input: n64joy - fix return value check in n64joy_probe()
  Input: s6sy761 - fix coordinate read bit shift

Merge tag 'drm-intel-fixes-2021-04-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Display panel & power related fixes:

- Backlight fix (Lyude)
- Display watermark fix (Ville)
- VLV panel power fix (Hans)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YHg4nz/ndzDRmPjd@intel.com

Merge tag 'for-5.12/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

Pull device mapper fix from Mike Snitzer:
 "Fix DM verity target FEC support's RS roots IO to always be aligned.

  This fixes a previous stable@ fix that overcorrected for a different
  configuration that also resulted in misaligned roots IO"

* tag 'for-5.12/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm verity fec: fix misaligned RS roots IO

commit df7b59ba ("dm verity: fix FEC for RS roots unaligned to
block size") introduced the possibility for misaligned roots IO
relative to the underlying device's logical block size. E.g. Android's
default RS roots=2 results in dm_bufio->block_size=1024, which causes
the following EIO if the logical block size of the device is 4096,
given v->data_dev_block_bits=12:

E sd 0    : 0:0:0: [sda] tag#30 request not aligned to the logical block size
E blk_update_request: I/O error, dev sda, sector 10368424 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
E device-mapper: verity-fec: 254:8: FEC 9244672: parity read failed (block 18056): -5

Fix this by onlu using f->roots for dm_bufio blocksize IFF it is
aligned to v->data_dev_block_bits.

Fixes: df7b59ba ("dm verity: fix FEC for RS roots unaligned to block size")
Cc: stable@vger.kernel.org
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>

Pull s390 fixes from Heiko Carstens:

 - setup stack backchain properly in external and i/o interrupt handler
   to fix stack unwinding. This broke when converting to generic entry

  - save caller address of psw_idle to get a sane stacktrace

* tag 's390-5.12-7' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/entry: save the caller of psw_idle
  s390/entry: avoid setting up backchain in ext|io handlers

Pull arm64 fixes from Will Deacon:

 - Fix incorrect asm constraint for load_unaligned_zeropad() fixup

 - Fix thread flag update when setting TIF_MTE_ASYNC_FAULT

 - Fix restored irq state when handling fault on kprobe

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: kprobes: Restore local irqflag if kprobes is cancelled
  arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically
  arm64: fix inline asm in load_unaligned_zeropad()

Pull dmaengine fixes from Vinod Koul:
 "A couple of dmaengine driver fixes for:

   - race and descriptor issue for xilinx driver

   - fix interrupt handling, wq state & cleanup, field sizes for
     completion, msix permissions for idxd driver

   - runtime pm fix for tegra driver

   - double free fix in dma_async_device_register"

* tag 'dmaengine-fix-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine:
  dmaengine: idxd: fix wq cleanup of WQCFG registers
  dmaengine: idxd: clear MSIX permission entry on shutdown
  dmaengine: plx_dma: add a missing put_device() on error path
  dmaengine: tegra20: Fix runtime PM imbalance on error
  dmaengine: Fix a double free in dma_async_device_register
  dmaengine: dw: Make it dependent to HAS_IOMEM
  dmaengine: idxd: fix wq size store permission state
  dmaengine: idxd: fix opcap sysfs attribute output
  dmaengine: idxd: fix delta_rec and crc size field for completion record
  dmaengine: idxd: Fix clobbering of SWERR overflow bit on writeback
  dmaengine: xilinx: dpdma: Fix race condition in done IRQ
  dmaengine: xilinx: dpdma: Fix descriptor issuing on video group

Pull VFIO fix from Alex Williamson:
 "Verify mmap region within range (Christian A. Ehrhardt)"

* tag 'vfio-v5.12-rc8' of git://github.com/awilliam/linux-vfio:
  vfio/pci: Add missing range check in vfio_pci_mmap

Pull kvm fix from Paolo Bonzini:
 "Fix for a possible out-of-bounds access"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: VMX: Don't use vcpu->run->internal.ndata as an array index

Pull tracing fix from Steven Rostedt:
 "Fix a memory link in dyn_event_release().

  An error path exited the function before freeing the allocated 'argv'
  variable"

* tag 'trace-v5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing/dynevent: Fix a memory leak in an error handling path

__vmx_handle_exit() uses vcpu->run->internal.ndata as an index for
an array access.  Since vcpu->run is (can be) mapped to a user address
space with a writer permission, the 'ndata' could be updated by the
user process at anytime (the user process can set it to outside the
bounds of the array).
So, it is not safe that __vmx_handle_exit() uses the 'ndata' that way.

Fixes: 1aa561b1 ("kvm: x86: Add "last CPU" to some KVM_EXIT information")
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Message-Id: <20210413154739.490299-1-reijiw@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Pull MTD fix from Richard Weinberger:
 "Fix WAITRDY break condition and timeout in mtk nand driver"

* tag 'fixes-for-5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
  mtd: rawnand: mtk: Fix WAITRDY break condition and timeout

We must free 'argv' before returning, as already done in all the other
paths of this function.

Link: https://lkml.kernel.org/r/21e3594ccd7fc88c5c162c98450409190f304327.1618136448.git.christophe.jaillet@wanadoo.fr

Fixes: d262271d ("tracing/dynevent: Delegate parsing to create function")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

When mmaping an extra device region verify that the region index
derived from the mmap offset is valid.

Fixes: a15b1883 ("vfio_pci: Allow mapping extra regions")
Cc: stable@vger.kernel.org
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
Message-Id: <20210412214124.GA241759@lisa.in-ulm.de>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

Commit 1a1c130a ("ACPI: tables: x86: Reserve memory occupied by
ACPI tables") attempted to address an issue with reserving the memory
occupied by ACPI tables, but it broke the initrd-based table override
mechanism relied on by multiple users.

To restore the initrd-based ACPI table override functionality, move
the acpi_boot_table_init() invocation in setup_arch() on x86 after
the acpi_table_upgrade() one.

Fixes: 1a1c130a ("ACPI: tables: x86: Reserve memory occupied by ACPI tables")
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If instruction being single stepped caused a page fault, the kprobes
is cancelled to let the page fault handler continue as a normal page
fault. But the local irqflags are disabled so cpu will restore pstate
with DAIF masked. After pagefault is serviced, the kprobes is
triggerred again, we overwrite the saved_irqflag by calling
kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
irqflag. After kprobes is serviced, the cpu pstate is retored with
DAIF masked.

This patch is inspired by one patch for riscv from Liao Chang.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20210412174101.6bfb0594@xhacker.debianSigned-off-by: Will Deacon <will@kernel.org>

A pre-release silicon erratum workaround where wq reset does not clear
WQCFG registers was leaked into upstream code. Use wq reset command
instead of blasting the MMIO region. This also address an issue where
we clobber registers in future devices.

Fixes: da32b28c ("dmaengine: idxd: cleanup workqueue config after disabling")
Reported-by: Shreenivaas Devarajan <shreenivaas.devarajan@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/161824330020.881560.16375921906426627033.stgit@djiang5-desk3.ch.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Add disabling/clearing of MSIX permission entries on device shutdown to
mirror the enabling of the MSIX entries on probe. Current code left the
MSIX enabled and the pasid entries still programmed at device shutdown.

Fixes: 8e50d392 ("dmaengine: idxd: Add shared workqueue support")
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/161824457969.882533.6020239898682672311.stgit@djiang5-desk3.ch.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Pull m68knommu fix from Greg Ungerer:
 "Some m68k platforms with a non-zero memory base fail to boot with the
  recent flatmem changes.

  This is a single regression fix to the pfn offset for that case"

* tag 'm68knommu-for-v5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68k: fix flatmem memory model setup

The entry from EL0 code checks the TFSRE0_EL1 register for any
asynchronous tag check faults in user space and sets the
TIF_MTE_ASYNC_FAULT flag. This is not done atomically, potentially
racing with another CPU calling set_tsk_thread_flag().

Replace the non-atomic ORR+STR with an STSET instruction. While STSET
requires ARMv8.1 and an assembler that understands LSE atomics, the MTE
feature is part of ARMv8.5 and already requires an updated assembler.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Fixes: 637ec831 ("arm64: mte: Handle synchronous and asynchronous tag check faults")
Cc: <stable@vger.kernel.org> # 5.10.x
Reported-by: Will Deacon <will@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20210409173710.18582-1-catalin.marinas@arm.comSigned-off-by: Will Deacon <will@kernel.org>

After the recently added commit fe0f1e3b ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.

I've managed to reproduce this without rebooting by doing:
chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
echo 0 > /sys/class/graphics/fb0/blank

Which rapidly turns the panel off and back on again.

The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
used for panel on/off, since starting with MIPI-sequences version >= 3 the
delays are already included inside the MIPI-sequences.

The problems exposed by the "Shut down displays gracefully on reboot"
change, show that using this helper for the panel_pwr_cycle_delay is
not the right thing to do. This has not been noticed until now because
normally the panel never is cycled off and directly on again in quick
succession.

Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
call to avoid the panel staying black after a quick off + on cycle.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-1-hdegoede@redhat.com
(cherry picked from commit 2878b29f)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Don't zero out the watermarks for the Y plane since we've already
computed them when computing the UV plane's watermarks (since the
UV plane always appears before ethe Y plane when iterating through
the planes).

This leads to allocating no DDB for the Y plane since .min_ddb_alloc
also gets zeroed. And that of course leads to underruns when scanning
out planar formats.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: dbf71381 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210327005945.4929-1-ville.syrjala@linux.intel.comReviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit f99b805f)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.

Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:

/* Use highest possible value of Pn for more granularity of brightness
 * adjustment while satifying the conditions below.
 * ...
 * - FxP is within 25% of desired value.
 *   Note: 25% is arbitrary value and may need some tweak.
 */

So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.

Fixes: 2227816e ("drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight")
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318170204.513000-1-lyude@redhat.com
(cherry picked from commit 9e2eb6d5)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Currently psw_idle does not allocate a stack frame and does not
save its r14 and r15 into the save area. Even though this is valid from
call ABI point of view, because psw_idle does not make any calls
explicitly, in reality psw_idle is an entry point for controlled
transition into serving interrupts. So, in practice, psw_idle stack
frame is analyzed during stack unwinding. Depending on build options
that r14 slot in the save area of psw_idle might either contain a value
saved by previous sibling call or complete garbage.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs
 ([task    0000038000003dd8] 0x0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

So, to make a stacktrace nicer and actually point for the real caller of
psw_idle in this frequently occurring case, make psw_idle save its r14.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs
 ([task    0000038000003dd8] arch_cpu_idle+0x3c/0xd0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Currently when interrupt arrives to cpu while in kernel context
INT_HANDLER macro (used for ext_int_handler and io_int_handler)
allocates new stack frame and pt_regs on the kernel stack and
sets up the backchain to jump over the pt_regs to the frame which has
been interrupted. This is not ideal to two reasons:

1. This hides the fact that kernel stack contains interrupt frame in it
   and hence breaks arch_stack_walk_reliable(), which needs to know that to
   guarantee "reliability" and checks that there are no pt_regs on the way.

2. It breaks the backchain unwinder logic, which assumes that the next
   stack frame after an interrupt frame is reliable, while it is not.
   In some cases (when r14 contains garbage) this leads to early unwinding
   termination with an error, instead of marking frame as unreliable
   and continuing.

To address that, only set backchain to 0.

Fixes: 56e62a73 ("s390: convert to generic entry")
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Add a missing put_device(&pdev->dev) if the call to
dma_async_device_register(dma); fails.

Fixes: 905ca51e ("dmaengine: plx-dma: Introduce PLX DMA engine PCI driver skeleton")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Link: https://lore.kernel.org/r/YFnq/0IQzixtAbC1@mwandaSigned-off-by: Vinod Koul <vkoul@kernel.org>

pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20210409082805.23643-1-dinghao.liu@zju.edu.cnSigned-off-by: Vinod Koul <vkoul@kernel.org>

In the first list_for_each_entry() macro of dma_async_device_register,
it gets the chan from list and calls __dma_async_device_channel_register
(..,chan). We can see that chan->local is allocated by alloc_percpu() and
it is freed chan->local by free_percpu(chan->local) when
__dma_async_device_channel_register() failed.

But after __dma_async_device_channel_register() failed, the caller will
goto err_out and freed the chan->local in the second time by free_percpu().

The cause of this problem is forget to set chan->local to NULL when
chan->local was freed in __dma_async_device_channel_register(). My
patch sets chan->local to NULL when the callee failed to avoid double free.

Fixes: d2fb0a04 ("dmaengine: break out channel registration")
Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20210331014458.3944-1-lyl2019@mail.ustc.edu.cnSigned-off-by: Vinod Koul <vkoul@kernel.org>

Some architectures do not provide devm_*() APIs. Hence make the driver
dependent on HAVE_IOMEM.

Fixes: dbde5c29 ("dw_dmac: use devm_* functions to simplify code")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20210324141757.24710-1-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>