When sending a rdata, transport may return -EAGAIN. In this case
we should re-obtain credits because the session may have been
reconnected.

Change in v2: adjust_credits before re-sending
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>

When sending a wdata, transport may return -EAGAIN. In this case
we should re-obtain credits because the session may have been
reconnected.

Change in v2: adjust_credits before re-sending
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>

Pull powerpc fixes from Michael Ellerman:
 "One fix for a boot failure on 32-bit, introduced during the merge
  window.

  A fix for our handling of CLOCK_MONOTONIC in the 64-bit VDSO. Changing
  the wall clock across the Y2038 boundary could cause CLOCK_MONOTONIC
  to jump forward and backward.

  Our spectre_v2 reporting was a bit confusing due to a bug I
  introduced. On some systems it was reporting that the count cache was
  disabled and also that we were flushing the count cache on context
  switch. Only the former is true, and given that the count cache is
  disabled it doesn't make any sense to flush it. No one reported it, so
  presumably the presence of any mitigation is all people check for.

  Finally a small build fix for zsmalloc on 32-bit.

  Thanks to: Ben Hutchings, Christophe Leroy, Diana Craciun, Guenter
  Roeck, Michael Neuling"

* tag 'powerpc-5.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/security: Fix spectre_v2 reporting
  powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
  powerpc/6xx: fix setup and use of SPRN_SPRG_PGDIR for hash32
  powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038

Pull iommu fixes from Joerg Roedel:

 - AMD IOMMU fix for sg-mapping with sg->offset > PAGE_SIZE

 - Fix for IOVA code to trigger the slow-path less often

 - Two fixes for Intel VT-d to avoid writing to read-only registers and
   to flush the right domain id for the default domains in scalable mode

* tag 'iommu-fixes-v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/vt-d: Save the right domain ID used by hardware
  iommu/vt-d: Check capability before disabling protected memory
  iommu/iova: Fix tracking of recently failed iova address
  iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE

Pull sound fixes from Takashi Iwai:
 "The only significant change is the regression fixes for the jack
  detection at resume on HD-audio, while others are all small or trivial
  fixes like the coverage of missing error code or usual HD-audio quirk"

* tag 'sound-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
  ALSA: hda - Enforces runtime_resume after S3 and S4 for each codec
  ALSA: hda - Don't trigger jackpoll_work in azx_resume
  ALSA: opl3: fix mismatch between snd_opl3_drum_switch definition and declaration
  ALSA: hda - add Lenovo IdeaCentre B550 to the power_save_blacklist
  ALSA: firewire-motu: use 'version' field of unit directory to identify model
  ALSA: sb8: add a check for request_region
  ALSA: echoaudio: add a check for ioremap_nocache

Pull device properties framework fix from Rafael Wysocki:
 "Add missing 'static' in two places (YueHaibing)"

* tag 'devprop-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  drivers: base: swnode: Make two functions static

Pull ACPI fix from Rafael Wysocki:
 "Prevent device references acquired by bus_find_device() in
  acpi_dev_present() from being leaked (Andy Shevchenko)"

* tag 'acpi-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / utils: Drop reference in test for device presence

Pull power management fixes from Rafael Wysocki:
 "These rearrange some code in the generic power domains (genpd)
  framework to avoid a potential deadlock and make the turbostat utility
  behave more as expected.

  Specifics:

   - Rearrange the generic power domains (genpd) code to avoid a
     potential deadlock possible due to its interactions with the clock
     framework (Jiada Wang)

   - Make turbostat return the exit status of the command run under it
     if that command fails (David Arcari)"

* tag 'pm-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / Domains: Avoid a potential deadlock
  tools/power turbostat: return the exit status of a command

Pull MMC fixes from Ulf Hansson:
 "A couple of MMC host fixes intended for v5.1:

   - alcor: Fix DMA reads

   - renesas_sdhi: Limit block count to 16-bit for old revisions

   - sdhci-omap: Fixup support for read-only pins

   - mxcmmc: Revert support for highmem pages

   - davinci/pxamci: Fix clang build warnings"

* tag 'mmc-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: renesas_sdhi: limit block count to 16 bit for old revisions
  mmc: alcor: fix DMA reads
  mmc: sdhci-omap: Set caps2 to indicate no physical write protect pin
  mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages"
  mmc: davinci: remove extraneous __init annotation
  mmc: pxamci: fix enum type confusion

The driver sets a default domain id (FLPT_DEFAULT_DID) in the
first level only pasid entry, but saves a different domain id
in @sdev->did. The value saved in @sdev->did will be used to
invalidate the translation caches. Hence, the driver might
result in invalidating the caches with a wrong domain id.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Fixes: 1c4f88b7 ("iommu/vt-d: Shared virtual address in scalable mode")
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability register).

Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: mark gross <mgross@intel.com>
Suggested-by: Ashok Raj <ashok.raj@intel.com>
Fixes: f8bab735 ("intel-iommu: PMEN support")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

If a 32 bit allocation request is too big to possibly succeed, it
early exits with a failure and then should never update max32_alloc_
size. This patch fixes current code, now the size is only updated if
the slow path failed while walking the tree. Without the fix the
allocation may enter the slow path again even if there was a failure
before of a request with the same or a smaller size.

Cc: <stable@vger.kernel.org> # 4.20+
Fixes: bee60e94 ("iommu/iova: Optimise attempts to allocate iova from 32bit address range")
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

* pm-domains:
  PM / Domains: Avoid a potential deadlock

Pull drm fixes from Dave Airlie:
 "i915, amdgpu, vmwgfx, exynos, nouveau and udl fixes.

  Seems to be lots of little minor ones for regressions in rc1, and some
  cleanups. The exynos one is the largest one, and is for a hw
  difference between exynos versions"

* tag 'drm-fixes-2019-03-22' of git://anongit.freedesktop.org/drm/drm:
  drm/nouveau/dmem: empty chunk do not have a buffer object associated with them.
  drm/nouveau/debugfs: Fix check of pm_runtime_get_sync failure
  drm/nouveau/dmem: Fix a NULL vs IS_ERR() check
  drm/nouveau/dmem: remove set but not used variable 'drm'
  drm/exynos/mixer: fix MIXER shadow registry synchronisation code
  drm/vmwgfx: Don't double-free the mode stored in par->set_mode
  drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID's
  drm/amdgpu: fix invalid use of change_bit
  drm/amdgpu: revert "cleanup setting bulk_movable"
  drm/i915: Sanity check mmap length against object size
  drm/i915: Fix off-by-one in reporting hanging process
  drm/i915/bios: assume eDP is present on port A when there is no VBT
  drm/udl: use drm_gem_object_put_unlocked.

- Parially revert a bulk move clean up change to fix a ref count bug
- Fix invalid use of change_bit that caused a crash on PPC64 and ARM64
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190321020933.3508-1-alexander.deucher@amd.com

Two fixes CC'd stable. One fix for a long-standing a bit hard-to-trigger fbdev
modesetting bug and one out-of-bo-id fix.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190321112026.114328-1-thellstrom@vmware.com

Merge tag 'exynos-drm-fixes-for-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes

- Fix page fault issue at Mixer device
  . This patch fixes the page fault issue by correcting sychronization
    method for updating shadow registers for Mixer device.
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1553162223-10090-1-git-send-email-inki.dae@samsung.com

Merge tag 'drm-intel-fixes-2019-03-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

A protection on our mmap against attempts to map past the end of the object;
plus a fix off-by-one in our hang report and a protection;
and a fix for eDP panels on Gen9 platforms on VBT absence.
Signed-off-by: Dave Airlie <airlied@redhat.com>

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

Some minor nouveau dmem and other fixes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CABDvA==kMkD6n-cS9KpQBcTU1E8p7Wc+H1ZuOhSfD7yTFJVvkw@mail.gmail.com

Empty chunk do not have a bo associated with them so no need to pin/unpin
on suspend/resume.

This fix suspend/resume on 5.1rc1 when NOUVEAU_SVM is enabled.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

pm_runtime_get_sync returns negative on failure.

Fixes: eaeb9010 ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The hmm_devmem_add() function doesn't return NULL, it returns error
pointers.

Fixes: 5be73b69 ("drm/nouveau/dmem: device memory helpers for SVM")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free':
drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning:
 variable 'drm' set but not used [-Wunused-but-set-variable]
  struct nouveau_drm *drm;
                      ^
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Pull arm64 fixes from Catalin Marinas:
 "Mostly fixes apart from the kprobe blacklist checking which was
  deferred because of conflicting with a fix merged after I pinned the
  arm64 for-next/core branch (f2b3d856 "arm64: kprobe: Always
  blacklist the KVM world-switch code").

  Summary:

   - Update the kprobe blacklist checking for arm64. This was supposed
     to be queued during the merging window but, due to conflicts, it
     was deferred post -rc1

   - Extend the Fujitsu erratum 010001 workaround to A64FX v1r0

   - Whitelist HiSilicon Taishan v110 CPUs as not susceptible to
     Meltdown

   - Export save_stack_trace_regs()

   - Remove obsolete selection of MULTI_IRQ_HANDLER"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: remove obsolete selection of MULTI_IRQ_HANDLER
  arm64: kpti: Whitelist HiSilicon Taishan v110 CPUs
  arm64: Add MIDR encoding for HiSilicon Taishan CPUs
  arm64/stacktrace: Export save_stack_trace_regs()
  arm64: apply workaround on A64FX v1r0
  arm64: kprobes: Use arch_populate_kprobe_blacklist()
  arm64: kprobes: Move exception_text check in blacklist
  arm64: kprobes: Remove unneeded RODATA check
  arm64: kprobes: Move extable address check into arch_prepare_kprobe()

Pull selinux fix from Paul Moore:
 "Another small SELinux fix for v5.1"

* tag 'selinux-pr-20190321' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
  selinux: fix NULL dereference in policydb_destroy()

Pull udf fixes from Jan Kara:
 "Two udf error handling fixes"

* tag 'fixes_for_v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  udf: Propagate errors from udf_truncate_extents()
  udf: Fix crash on IO error during truncate

Pull fsnotify fixes from Jan Kara:
 "One inotify and one fanotify fix"

* tag 'fsnotify_for_v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  fanotify: Allow copying of file handle to userspace
  inotify: Fix fsnotify_mark refcount leak in inotify_update_existing_watch()

R-Car Gen2 has two different SDHI incarnations in the same chip. The
older one does not support the recently introduced 32 bit register
access to the block count register. Make sure we use this feature only
after the first known version.

Thanks to the Renesas Testing team for this bug report!

Fixes: 5603731a ("mmc: tmio: fix access width of Block Count Register")
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Phong Hoang <phong.hoang.wz@renesas.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Setting max_blk_count to 1 here was causing the mmc block layer
to always use the MMC_READ_SINGLE_BLOCK command here, which the
driver does not DMA-accelerate.

Drop the max_blk_ settings here. The mmc host defaults suffice,
along with the max_segs and max_seg_size settings, which I have
now documented in more detail.

Now each MMC command reads 4 512-byte blocks, using DMA instead of
PIO. On my SD card, this increases read performance (measured with dd)
from 167kb/sec to 4.6mb/sec.

Link: http://lkml.kernel.org/r/CAD8Lp47L5T3jnAjBiPs1cQ+yFA3L6LJtgFvMETnBrY63-Zdi2g@mail.gmail.comSigned-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Fixes: c5413ad8 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

After commit 6d5cd068 ("mmc: sdhci: use WP GPIO in
sdhci_check_ro()") and commit 39ee32ce ("mmc: sdhci-omap: drop
->get_ro() implementation"), sdhci-omap relied on SDHCI_PRESENT_STATE
to check if the card is read-only, if wp-gpios is not populated
in device tree. However SDHCI_PRESENT_STATE in sdhci-omap does not have
correct read-only state.

sdhci-omap can be used by platforms with both micro SD slot and standard
SD slot with physical write protect pin (using GPIO). Set caps2 to
MMC_CAP2_NO_WRITE_PROTECT based on if wp-gpios property is populated or
not.

This fix is required since existing device-tree node doesn't have
"disable-wp" property and to preserve old-dt compatibility.

Fixes: 6d5cd068 ("mmc: sdhci: use WP GPIO in sdhci_check_ro()")
Fixes: 39ee32ce ("mmc: sdhci-omap: drop ->get_ro() implementation")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

When I updated the spectre_v2 reporting to handle software count cache
flush I got the logic wrong when there's no software count cache
enabled at all.

The result is that on systems with the software count cache flush
disabled we print:

  Mitigation: Indirect branch cache disabled, Software count cache flush

Which correctly indicates that the count cache is disabled, but
incorrectly says the software count cache flush is enabled.

The root of the problem is that we are trying to handle all
combinations of options. But we know now that we only expect to see
the software count cache flush enabled if the other options are false.

So split the two cases, which simplifies the logic and fixes the bug.
We were also missing a space before "(hardware accelerated)".

The result is we see one of:

  Mitigation: Indirect branch serialisation (kernel only)
  Mitigation: Indirect branch cache disabled
  Mitigation: Software count cache flush
  Mitigation: Software count cache flush (hardware accelerated)

Fixes: ee13cb24 ("powerpc/64s: Add support for software count cache flush")
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: Diana Craciun <diana.craciun@nxp.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

This reverts commit b189e758.

Unable to handle kernel paging request at virtual address c8358000
pgd = efa405c3
[c8358000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT ARM
CPU: 0 PID: 711 Comm: kworker/0:2 Not tainted 4.20.0+ #30
Hardware name: Freescale i.MX27 (Device Tree Support)
Workqueue: events mxcmci_datawork
PC is at mxcmci_datawork+0xbc/0x2ac
LR is at mxcmci_datawork+0xac/0x2ac
pc : [<c04e33c8>]    lr : [<c04e33b8>]    psr: 60000013
sp : c6c93f08  ip : 24004180  fp : 00000008
r10: c8358000  r9 : c78b3e24  r8 : c6c92000
r7 : 00000000  r6 : c7bb8680  r5 : c7bb86d4  r4 : c78b3de0
r3 : 00002502  r2 : c090b2e0  r1 : 00000880  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: a68a8000  DAC: 00000055
Process kworker/0:2 (pid: 711, stack limit = 0x389543bc)
Stack: (0xc6c93f08 to 0xc6c94000)
3f00:                   c7bb86d4 00000000 00000000 c6cbfde0 c7bb86d4 c7ee4200
3f20: 00000000 c0907ea8 00000000 c7bb86d8 c0907ea8 c012077c c6cbfde0 c7bb86d4
3f40: c6cbfde0 c6c92000 c6cbfdf4 c09280ba c0907ea8 c090b2e0 c0907ebc c0120c18
3f60: c6cbfde0 00000000 00000000 c6cbb580 c7ba7c40 c7837edc c6cbb598 00000000
3f80: c6cbfde0 c01208f8 00000000 c01254fc c7ba7c40 c0125400 00000000 00000000
3fa0: 00000000 00000000 00000000 c01010d0 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c04e33c8>] (mxcmci_datawork) from [<c012077c>] (process_one_work+0x1f0/0x338)
[<c012077c>] (process_one_work) from [<c0120c18>] (worker_thread+0x320/0x474)
[<c0120c18>] (worker_thread) from [<c01254fc>] (kthread+0xfc/0x118)
[<c01254fc>] (kthread) from [<c01010d0>] (ret_from_fork+0x14/0x24)
Exception stack(0xc6c93fb0 to 0xc6c93ff8)
3fa0:                                     00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e3500000 1a000059 e5153050 e5933038 (e48a3004)
---[ end trace 54ca629b75f0e737 ]---
note: kworker/0:2[711] exited with preempt_count 1
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Fixes: b189e758 ("mmc: mxcmmc: handle highmem pages")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC.  This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.

Fixes: 9f8aefed ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G")
Fixes: b72f936f ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G")
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
Reviewed-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
  ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
- before setting registers synchronisation on VSYNC should be turned off,
  ie. MXR_STATUS_SYNC_ENABLE should be reset,
- after finishing MXR_STATUS_SYNC_ENABLE should be set again.
The patch hopefully implements it correctly.
Below sample kernel log from page fault caused by the bug:

[   25.670038] exynos-sysmmu 14650000.sysmmu: 14450000.mixer: PAGE FAULT occurred at 0x2247b800
[   25.677888] ------------[ cut here ]------------
[   25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
[   25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[   25.693778] Modules linked in:
[   25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 5.0.0-rc7-01157-g5f86b1566bdd #136
[   25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
[   25.716470] LR is at lock_is_held_type+0x44/0x64

v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync
Reported-by: Marian Mihailescu <mihailescu2m@gmail.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Pull ARC updates from Vineet Gupta:

 - unaligned access support for HS cores

 - Removed extra memory barrier around spinlock code

 - HSDK platform updates: enable dmac, reset

 - some more boot logging updates

 - misc minor fixes

* tag 'arc-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  arch: arc: Kconfig: pedantic formatting
  ARCv2: spinlock: remove the extra smp_mb before lock, after unlock
  ARC: unaligned: relax the check for gcc supporting -mno-unaligned-access
  ARC: boot log: cut down on verbosity
  ARCv2: boot log: refurbish HS core/release identification
  arc: hsdk_defconfig: Enable CONFIG_BLK_DEV_RAM
  ARC: u-boot args: check that magic number is correct
  ARC: perf: bpok condition only exists for ARCompact
  ARCv2: Add explcit unaligned access support (and ability to disable too)
  ARCv2: lib: introduce memcpy optimized for unaligned access
  ARC: [plat-hsdk]: Enable AXI DW DMAC support
  ARC: [plat-hsdk]: Add reset controller handle to manage USB reset
  ARC: DTB: [scripted] fix node name and address spelling

The arm64 config selects MULTI_IRQ_HANDLER, which was renamed to
GENERIC_IRQ_MULTI_HANDLER by commit 4c301f9b ("ARM: Convert
to GENERIC_IRQ_MULTI_HANDLER"). The 'new' option is already
selected, so just remove the obsolete entry.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
enabled, and that was the case before commit 4ffe713b
("powerpc/mm: Increase the max addressable memory to 2PB").

On 32-bit systems, where CONFIG_SPARSEMEM is not enabled, we now
define it as 46.  That is larger than the real number of physical
address bits, and breaks calculations in zsmalloc:

  mm/zsmalloc.c:130:49: warning: right shift count is negative
    MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
                                                   ^~
  ...
  mm/zsmalloc.c:253:21: error: variably modified 'size_class' at file scope
    struct size_class *size_class[ZS_SIZE_CLASSES];
                       ^~~~~~~~~~

Fixes: 4ffe713b ("powerpc/mm: Increase the max addressable memory to 2PB")
Cc: stable@vger.kernel.org # v4.20+
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing
'old_mode' in favor of using par->set_mode directly fixes the problem.

Cc: <stable@vger.kernel.org>
Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

If it's not a system error and get_node implementation accommodate the
buffer object then it should return 0 with memm::mm_node set to NULL.

v2: Test for id != -ENOMEM instead of id == -ENOSPC.

Cc: <stable@vger.kernel.org>
Fixes: 4eb085e4 ("drm/vmwgfx: Convert to new IDA API")
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

Lockdep warns that prepare_lock and genpd->mlock can cause a deadlock
the deadlock scenario is like following:
First thread is probing cs2000
cs2000_probe()
  clk_register()
    __clk_core_init()
      clk_prepare_lock()                            ----> acquires prepare_lock
        cs2000_recalc_rate()
          i2c_smbus_read_byte_data()
            rcar_i2c_master_xfer()
              dma_request_chan()
                rcar_dmac_of_xlate()
                  rcar_dmac_alloc_chan_resources()
                    pm_runtime_get_sync()
                      __pm_runtime_resume()
                        rpm_resume()
                          rpm_callback()
                            genpd_runtime_resume()   ----> acquires genpd->mlock

Second thread is attaching any device to the same PM domain
genpd_add_device()
  genpd_lock()                                       ----> acquires genpd->mlock
    cpg_mssr_attach_dev()
      of_clk_get_from_provider()
        __of_clk_get_from_provider()
          __clk_create_clk()
            clk_prepare_lock()                       ----> acquires prepare_lock

Since currently no PM provider access genpd's critical section
in .attach_dev, and .detach_dev callbacks, so there is no need to protect
these two callbacks with genpd->mlock.
This patch avoids a potential deadlock by moving out .attach_dev and .detach_dev
from genpd->mlock, so that genpd->mlock won't be held when prepare_lock is acquired
in .attach_dev and .detach_dev
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>