The ACPI specification states that if the "Guaranteed Performance
Register" is not implemented, the OSPM assumes guaranteed performance
to always be equal to nominal performance.

So for invalid or unimplemented guaranteed performance register, use
nominal performance as guaranteed performance.

This change will fall back to nominal_perf when guranteed_perf is
invalid.  If nominal_perf is also invalid or not present, fall back
to the existing implementation, which is to read from HWP Capabilities
MSR.

Fixes: 86d333a8 ("cpufreq: intel_pstate: Add base_frequency attribute")
Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 4.20+ <stable@vger.kernel.org> # 4.20+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As per the ACPI specification, "Guaranteed Performance Register" is
a "Buffer" field and it cannot be "Integer", so treat the "Integer"
type for "Guaranteed Performance Register" field as invalid and
ignore its value in that case.

Also save one cpc_read() call when "Guaranteed Performance Register"
is not present, which means a register defined as:
"Register(SystemMemory, 0, 0, 0, 0)".

Fixes: 29523f09 ("ACPI / CPPC: Add support for guaranteed performance")
Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 4.20+ <stable@vger.kernel.org> # 4.20+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Since board support for the CLPS711X platform was removed,
remove the board support from the clps711x-timer driver.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lkml.kernel.org/r/20181220111626.17140-1-shc_work@mail.ru

For all riscv architectures (RV32, RV64 and RV128), the clocksource
is a 64 bit incrementing counter.

Fix the clock source mask accordingly.

Tested on both 64bit and 32 bit virt machine in QEMU.

Fixes: 62b01943 ("clocksource: new RISC-V SBI timer driver")
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAnup Patel <anup@brainfault.org>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-riscv@lists.infradead.org
Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Anup Patel <Anup.Patel@wdc.com>
Cc: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190322215411.19362-1-atish.patra@wdc.com

Fix sparse warning:

drivers/clocksource/mips-gic-timer.c:70:18: warning:
 symbol 'gic_compare_irqaction' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <daniel.lezcano@linaro.org>
Link: https://lkml.kernel.org/r/20190322144359.19516-1-yuehaibing@huawei.com

Fix sparse warning:

drivers/clocksource/timer-ti-dm.c:589:5: warning:
 symbol 'omap_dm_timer_set_load_start' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <daniel.lezcano@linaro.org>
Link: https://lkml.kernel.org/r/20190322144302.6704-1-yuehaibing@huawei.com

Fix sparse warnings:

drivers/clocksource/tcb_clksrc.c:74:6: warning:
 symbol 'tc_clksrc_suspend' was not declared. Should it be static?
drivers/clocksource/tcb_clksrc.c:89:6: warning:
 symbol 'tc_clksrc_resume' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <nicolas.ferre@microchip.com>
Cc: <daniel.lezcano@linaro.org>
Cc: <linux-arm-kernel@lists.infradead.org>
Link: https://lkml.kernel.org/r/20190322143940.12396-1-yuehaibing@huawei.com

Fix sparse warning:

drivers/clocksource/clps711x-timer.c:96:13: warning:
 symbol 'clps711x_clksrc_init' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <daniel.lezcano@linaro.org>
Cc: <shc_work@mail.ru>
Cc: <linux-arm-kernel@lists.infradead.org>
Link: https://lkml.kernel.org/r/20190322143708.12716-1-yuehaibing@huawei.com

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: NLiu Yi L <yi.l.liu@intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NJoerg 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: NAshok Raj <ashok.raj@intel.com>
Fixes: f8bab735 ("intel-iommu: PMEN support")
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NJoerg 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: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NRobert Richter <rrichter@marvell.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

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: NJérôme Glisse <jglisse@redhat.com>
Reviewed-by: NTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Tested-by: NTobias 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: NBen 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: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NBen 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: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBen 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: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fix sparse warning:

drivers/irqchip/irq-mvebu-sei.c:481:23: warning:
 symbol 'mvebu_sei_ap806_caps' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <jason@lakedaemon.net>
Cc: <andrew@lunn.ch>
Cc: <gregory.clement@bootlin.com>
Cc: <sebastian.hesselbarth@gmail.com>
Cc: <marc.zyngier@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Link: https://lkml.kernel.org/r/20190321151448.15600-1-yuehaibing@huawei.com

mbigen_write_msg clears eventid bits of a mbigen register
when free a interrupt, because msi_domain_deactivate memset
struct msg to zero. Then multiple mbigen pins with zero eventid
will report the same interrupt number.

The eventid clear call trace:
                free_irq
                __free_irq
                irq_shutdown
                irq_domain_deactivate_irq
                __irq_domain_deactivate_irq
                __irq_domain_deactivate_irq
                msi_domain_deactivate
                platform_msi_write_msg
                mbigen_write_msg
Signed-off-by: NJianguo Chen <chenjianguo3@huawei.com>
[maz: massaged subject]
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

The rising configuration status register (rtsr) is not banked.
As it is shared with the co-processor, it should not be written at probe
time, else the co-processor configuration will be lost.

Fixes: f9fc1745 ("irqchip/stm32: Add host and driver data structures")
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Falling and rising configuration and status registers are not banked.
As they are shared with M4 co-processor, they should not be cleared
at probe time, else M4 co-processor configuration will be lost.

Fixes: f9fc1745 ("irqchip/stm32: Add host and driver data structures")
Signed-off-by: NLoic Pallardy <loic.pallardy@st.com>
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Fix sparse warning:

drivers/irqchip/irq-mmp.c:182:29: warning:
 symbol 'mmp_irq_domain_ops' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Fix sparse warnings:

drivers/irqchip/irq-brcmstb-l2.c:278:12: warning:
 symbol 'brcmstb_l2_edge_intc_of_init' was not declared. Should it be static?
drivers/irqchip/irq-brcmstb-l2.c:285:12: warning:
 symbol 'brcmstb_l2_lvl_intc_of_init' was not declared. Should it be static?
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

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: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Tested-by: NPhong Hoang <phong.hoang.wz@renesas.com>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf 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: NDaniel Drake <drake@endlessm.com>
Reviewed-by: NOleksij Rempel <linux@rempel-privat.de>
Fixes: c5413ad8 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
Cc: stable@vger.kernel.org
Signed-off-by: NUlf 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: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NAlexander Shiyan <shc_work@mail.ru>
Fixes: b189e758 ("mmc: mxcmmc: handle highmem pages")
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

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: NMarian Mihailescu <mihailescu2m@gmail.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The event pool used for queueing commands is destroyed fairly early in the
ibmvscsi_remove() code path. Since, this happens prior to the call so
scsi_remove_host() it is possible for further calls to queuecommand to be
processed which manifest as a panic due to a NULL pointer dereference as
seen here:

PANIC: "Unable to handle kernel paging request for data at address
0x00000000"

Context process backtrace:

DSISR: 0000000042000000 ????Syscall Result: 0000000000000000
4 [c000000002cb3820] memcpy_power7 at c000000000064204
[Link Register] [c000000002cb3820] ibmvscsi_send_srp_event at d000000003ed14a4
5 [c000000002cb3920] ibmvscsi_send_srp_event at d000000003ed14a4 [ibmvscsi] ?(unreliable)
6 [c000000002cb39c0] ibmvscsi_queuecommand at d000000003ed2388 [ibmvscsi]
7 [c000000002cb3a70] scsi_dispatch_cmd at d00000000395c2d8 [scsi_mod]
8 [c000000002cb3af0] scsi_request_fn at d00000000395ef88 [scsi_mod]
9 [c000000002cb3be0] __blk_run_queue at c000000000429860
10 [c000000002cb3c10] blk_delay_work at c00000000042a0ec
11 [c000000002cb3c40] process_one_work at c0000000000dac30
12 [c000000002cb3cd0] worker_thread at c0000000000db110
13 [c000000002cb3d80] kthread at c0000000000e3378
14 [c000000002cb3e30] ret_from_kernel_thread at c00000000000982c

The kernel buffer log is overfilled with this log:

[11261.952732] ibmvscsi: found no event struct in pool!

This patch reorders the operations during host teardown. Start by calling
the SRP transport and Scsi_Host remove functions to flush any outstanding
work and set the host offline. LLDD teardown follows including destruction
of the event pool, freeing the Command Response Queue (CRQ), and unmapping
any persistent buffers. The event pool destruction is protected by the
scsi_host lock, and the pool is purged prior of any requests for which we
never received a response. Finally, move the removal of the scsi host from
our global list to the end so that the host is easily locatable for
debugging purposes during teardown.

Cc: <stable@vger.kernel.org> # v2.6.12+
Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

For each ibmvscsi host created during a probe or destroyed during a remove
we either add or remove that host to/from the global ibmvscsi_head
list. This runs the risk of concurrent modification.

This patch adds a simple spinlock around the list modification calls to
prevent concurrent updates as is done similarly in the ibmvfc driver and
ipr driver.

Fixes: 32d6e4b6 ("scsi: ibmvscsi: add vscsi hosts to global list_head")
Cc: <stable@vger.kernel.org> # v4.10+
Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

We found out that for v2 hw, a SATA disk can not be written to after the
system comes up.

In commit ffb1c820 ("scsi: hisi_sas: remove the check of sas_dev status
in hisi_sas_I_T_nexus_reset()"), we introduced a path where we may issue an
internal abort for a SATA device, but without following it with a
softreset.

We need to always follow an internal abort with a software reset, as per HW
programming flow, so add this.

Fixes: ffb1c820 ("scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset()")
Signed-off-by: NLuo Jiaxing <luojiaxing@huawei.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

The lpi_range_list is supposed to be sorted in ascending order of
->base_id (at least if the range merging is to work), but the current
comparison function returns a positive value if rb->base_id >
ra->base_id, which means that list_sort() will put A after B in that
case - and vice versa, of course.

Fixes: 880cb3cd (irqchip/gic-v3-its: Refactor LPI allocator)
Cc: stable@vger.kernel.org (v4.19+)
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
Reviewed-by: NJason Dillaman <dillaman@redhat.com>

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: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Signed-off-by: NThomas 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: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas 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: NJiada Wang <jiada_wang@mentor.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When commit 8661423e ("ACPI / utils: Add new acpi_dev_present
helper") introduced acpi_dev_present(), it missed the fact that
bus_find_device() took a reference on the device found by it and
the callers of acpi_dev_present() don't drop that reference.

Drop the reference on the device in acpi_dev_present().

Fixes: 8661423e ("ACPI / utils: Add new acpi_dev_present helper")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We only need to clear the bit in a 32bit integer.

This fixes a crah on ARM64 and PPC64LE caused by
"drm/amdgpu: update the vm invalidation engine layout V2"
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 8466cc61.

It can trigger a reference counter bug in TTM. Need to investigate further, but
for now revert the offending change.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This patch fixes crash due to NULL pointer derefrence because CPU pointer
is not set and used by driver.  Instead, driver is passes CPU as tag via
ha->isp_ops->{lun_reset|target_reset}

[   30.160780] qla2xxx [0000:a0:00.1]-8038:9: Cable is unplugged...
[   69.984045] qla2xxx [0000:a0:00.0]-8009:8: DEVICE RESET ISSUED nexus=8:0:0 cmd=00000000b0d62f46.
[   69.992849] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
[   70.000680] PGD 0 P4D 0
[   70.003232] Oops: 0000 [#1] SMP PTI
[   70.006727] CPU: 2 PID: 6714 Comm: sg_reset Kdump: loaded Not tainted 4.18.0-67.el8.x86_64 #1
[   70.015258] Hardware name: NEC Express5800/T110j [N8100-2758Y]/MX32-PH0-NJ, BIOS F11 02/13/2019
[   70.024016] RIP: 0010:blk_mq_rq_cpu+0x9/0x10
[   70.028315] Code: 01 58 01 00 00 48 83 c0 28 48 3d 80 02 00 00 75 ab c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48
 8b 47 08 <8b> 40 40 c3 0f 1f 00 0f 1f 44 00 00 48 83 ec 10 48 c7 c6 20 6e 7c
[   70.047087] RSP: 0018:ffff99a481487d58 EFLAGS: 00010246
[   70.052322] RAX: 0000000000000000 RBX: ffffffffc041b08b RCX: 0000000000000000
[   70.059466] RDX: 0000000000000000 RSI: ffff8d10b6b16898 RDI: ffff8d10b341e400
[   70.066615] RBP: ffffffffc03a6bd0 R08: 0000000000000415 R09: 0000000000aaaaaa
[   70.073765] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8d10b341e528
[   70.080914] R13: ffff8d10aadefc00 R14: ffff8d0f64efa998 R15: ffff8d0f64efa000
[   70.088083] FS:  00007f90a201e540(0000) GS:ffff8d10b6b00000(0000) knlGS:0000000000000000
[   70.096188] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   70.101959] CR2: 0000000000000040 CR3: 0000000268886005 CR4: 00000000003606e0
[   70.109127] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   70.116277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   70.123425] Call Trace:
[   70.125896]  __qla2xxx_eh_generic_reset+0xb1/0x220 [qla2xxx]
[   70.131572]  scsi_ioctl_reset+0x1f5/0x2a0
[   70.135600]  scsi_ioctl+0x18e/0x397
[   70.139099]  ? sd_ioctl+0x7c/0x100 [sd_mod]
[   70.143287]  blkdev_ioctl+0x32b/0x9f0
[   70.146954]  ? __check_object_size+0xa3/0x181
[   70.151323]  block_ioctl+0x39/0x40
[   70.154735]  do_vfs_ioctl+0xa4/0x630
[   70.158322]  ? syscall_trace_enter+0x1d3/0x2c0
[   70.162769]  ksys_ioctl+0x60/0x90
[   70.166104]  __x64_sys_ioctl+0x16/0x20
[   70.169859]  do_syscall_64+0x5b/0x1b0
[   70.173532]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[   70.178587] RIP: 0033:0x7f90a1b3445b
[   70.182183] Code: 0f 1e fa 48 8b 05 2d aa 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00
 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd a9 2c 00 f7 d8 64 89 01 48
[   70.200956] RSP: 002b:00007fffdca88b68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   70.208535] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f90a1b3445b
[   70.215684] RDX: 00007fffdca88b84 RSI: 0000000000002284 RDI: 0000000000000003
[   70.222833] RBP: 00007fffdca88ca8 R08: 00007fffdca88b84 R09: 0000000000000000
[   70.229981] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffdca88b84
[   70.237131] R13: 0000000000000000 R14: 000055ab09b0bd28 R15: 0000000000000000
[   70.244284] Modules linked in: nft_chain_route_ipv4 xt_CHECKSUM nft_chain_nat_ipv4 ipt_MASQUERADE nf_nat_ipv4 nf_nat nf_conntrack_ipv4
 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 nft_counter nft_compat tun bridge stp llc nf_tables nfnetli
nk devlink sunrpc vfat fat intel_rapl intel_pmc_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm wmi_bmof iTCO_wdt iTCO_
vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ipmi_ssif intel_cstate intel_uncore intel_rapl_perf ipmi_si jo
ydev pcspkr ipmi_devintf sg wmi ipmi_msghandler video acpi_power_meter acpi_pad mei_me i2c_i801 mei ip_tables ext4 mbcache jbd2 sr_mod cd
rom sd_mod qla2xxx ast i2c_algo_bit drm_kms_helper nvme_fc syscopyarea sysfillrect uas sysimgblt fb_sys_fops nvme_fabrics ttm
[   70.314805]  usb_storage nvme_core crc32c_intel scsi_transport_fc ahci drm libahci tg3 libata megaraid_sas pinctrl_cannonlake pinctrl_
intel
[   70.327335] CR2: 0000000000000040

Fixes: 9cf2bab6 ("block: kill request ->cpu member")
Signed-off-by: NHimanshu Madhani <hmadhani@marvell.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Commit 7f147f9b ("scsi: qla2xxx: Fix N2N target discovery with Local
loop") fixed N2N target discovery for local loop.  However, same code is
used for FC-AL discovery as well. Added check to make sure we are bypassing
area and domain check only in N2N topology for target discovery.

Fixes: 7f147f9b ("scsi: qla2xxx: Fix N2N target discovery with Local loop")
Cc: stable@vger.kernel.org # 5.0+
Signed-off-by: NQuinn Tran <qtran@marvell.com>
Signed-off-by: NHimanshu Madhani <hmadhani@marvell.com>
Reviewed-by: NEwan D. Milne <emilne@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since scsi_device_quiesce() skips SCSI devices that have another state than
RUNNING, OFFLINE or TRANSPORT_OFFLINE, scsi_device_resume() should not
complain about SCSI devices that have been skipped. Hence this patch.  This
patch avoids that the following warning appears during resume:

WARNING: CPU: 3 PID: 1039 at blk_clear_pm_only+0x2a/0x30
CPU: 3 PID: 1039 Comm: kworker/u8:49 Not tainted 5.0.0+ #1
Hardware name: LENOVO 4180F42/4180F42, BIOS 83ET75WW (1.45 ) 05/10/2013
Workqueue: events_unbound async_run_entry_fn
RIP: 0010:blk_clear_pm_only+0x2a/0x30
Call Trace:
 ? scsi_device_resume+0x28/0x50
 ? scsi_dev_type_resume+0x2b/0x80
 ? async_run_entry_fn+0x2c/0xd0
 ? process_one_work+0x1f0/0x3f0
 ? worker_thread+0x28/0x3c0
 ? process_one_work+0x3f0/0x3f0
 ? kthread+0x10c/0x130
 ? __kthread_create_on_node+0x150/0x150
 ? ret_from_fork+0x1f/0x30

Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Martin Steigerwald <martin@lichtvoll.de>
Cc: <stable@vger.kernel.org>
Reported-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Tested-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Fixes: 3a0a5299 ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>