On some machines hole_end can be small enough to cause subtraction
overflow. On the other side (addr + 2 * min_alignment) can overflow
in case of mock tests. This patch should handle both cases.

Fixes: e1c5f754 ("drm/i915: Avoid overflow in computing pot_hole loop termination")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3674Signed-off-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624113528.2159210-1-andrzej.hajda@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit ab3edc67)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We employ a "waitboost" heuristic to detect when userspace is stalled
waiting for results from earlier execution. Under latency sensitive work
mixed between the gpu/cpu, the GPU is typically under-utilised and so
RPS sees that low utilisation as a reason to downclock the frequency,
causing longer stalls and lower throughput. The user left waiting for
the results is not impressed.

On applying commit 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv
workaround") it was observed that deinterlacing h264 on Haswell
performance dropped by 2-5x. The reason being that the natural workload
was not intense enough to trigger RPS (using HW evaluation intervals) to
upclock, and so it was depending on waitboosting for the throughput.

Commit 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
changes the composition of dma-resv from keeping a single write fence +
multiple read fences, to a single array of multiple write and read
fences (a maximum of one pair of write/read fences per context). The
iteration order was also changed implicitly from all-read fences then
the single write fence, to a mix of write fences followed by read
fences. It is that ordering change that belied the fragility of
waitboosting.

Currently, a waitboost is inspected at the point of waiting on an
outstanding fence. If the GPU is backlogged such that we haven't yet
stated the request we need to wait on, we force the GPU to upclock until
the completion of that request. By changing the order in which we waited
upon requests, we ended up waiting on those requests in sequence and as
such we saw that each request was already started and so not a suitable
candidate for waitboosting.

Instead of asking whether to boost each fence in turn, we can look at
whether boosting is required for the dma-resv ensemble prior to waiting
on any fence, making the heuristic more robust to the order in which
fences are stored in the dma-resv.
Reported-by: NThomas Voegtle <tv@lio96.de>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6284
Fixes: 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NKarolina Drobnik <karolina.drobnik@intel.com>
Tested-by: NThomas Voegtle <tv@lio96.de>
Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/07e05518d9f6620d20cc1101ec1849203fe973f9.1657289332.git.karolina.drobnik@intel.com
(cherry picked from commit 394e2b57)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmio access, thereby serialising with the GDRST.

Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with
i915 selftest/hangcheck.

Cc: stable@vger.kernel.org  # v4.4 and upper
Fixes: 7938d615 ("drm/i915: Flush TLBs before releasing backing store")
Reported-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Tested-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Reviewed-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NChris Wilson <chris.p.wilson@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com>
Acked-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e59a7c45dd919a530256b9ac721ac6ea86c0677.1657639152.git.mchehab@kernel.org
(cherry picked from commit 33da9789)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no other GT state changes at the same time as the actual reset.

Cc: stable@vger.kernel.org # v4.4 and upper
Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NAndi Shyti <andi.shyti@intel.com>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Acked-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e0a2d894e77aed7c2e36b0d1abdc7dbac3011729.1657639152.git.mchehab@kernel.org
(cherry picked from commit 336561a9)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If we encounter some monster sized local-memory page that exceeds the
maximum sg length (UINT32_MAX), ensure that don't end up with some
misaligned address in the entry that follows, leading to fireworks
later. Also ensure we have some coverage of this in the selftests.

v2(Chris):
  - Use round_down consistently to avoid udiv errors
v3(Nirmoy):
  - Also update the max_segment in the selftest

Fixes: f701b16d ("drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Nirmoy Das <nirmoy.das@linux.intel.com>
Reviewed-by: NNirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220711085859.24198-1-matthew.auld@intel.com
(cherry picked from commit bc99f120)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

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

Fixes: be1cb55a ("drm/i915/gt: Keep a no-frills swappable copy of the default context state")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220708094104.GL2316@kadam
(cherry picked from commit d50f5a10)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

In vma destruction, the following race may occur:

Thread 1:	    		  Thread 2:
i915_vma_destroy();

  ...
  list_del_init(vma->vm_link);
  ...
  mutex_unlock(vma->vm->mutex);
				  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.

However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().

v2: Fix a typo in the commit message (Andi Shyti)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4f ("drm/i915: Remove the vm open count")

Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: NNirmoy Das <nirmoy.das@intel.con>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620123659.381772-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit 1926a6b7)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The only difference between the ADL S and P GuC FWs is the HWConfig
support. ADL-N does not support HWConfig, so we should use the same
binary as ADL-S, otherwise the GuC might attempt to fetch a config
table that does not exist. ADL-N is internally identified as an ADL-P,
so we need to special-case it in the FW selection code.

Fixes: 7e28d0b2 ("drm/i915/adl-n: Enable ADL-N platform")
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220621233005.3952293-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 971e4a97)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit cea9ed61)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

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

Fixes: 97ea6565 ("drm/i915/gvt: Parse default state to update reg whitelist")
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/Ysftoia2BPUyqVcD@kiliAcked-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Always run fbdev removal first to remove simpledrm via sysfb_disable().
This clears the internal state.

The later call to drm_aperture_detach_drivers() then does nothing.
Otherwise, with drm_aperture_detach_drivers() running first, the call to
sysfb_disable() uses inconsistent state.

Example backtrace show below:

  BUG: KASAN: use-after-free in device_del+0x79/0x5f0
  Read of size 8 at addr ffff888108185050 by task systemd-udevd/311
  CPU: 0 PID: 311 Comm: systemd-udevd Tainted: G            E     5.19.0-rc2-1-default+ #1689
  Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
  Call Trace:
    device_del+0x79/0x5f0
    platform_device_del.part.0+0x19/0xe0
    platform_device_unregister+0x1c/0x30
    sysfb_disable+0x2d/0x70
    remove_conflicting_framebuffers+0x1c/0xf0
    remove_conflicting_pci_framebuffers+0x130/0x1a0
    drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
    mgag200_pci_probe+0x2d/0x140 [mgag200]
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Fixes: 873eb3b1 ("fbdev: Disable sysfb device registration when removing conflicting FBs")
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Changcheng Deng <deng.changcheng@zte.com.cn>
Reviewed-by: NZack Rusin <zackr@vmware.com>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit c9cad937.

This is part of a revert of the following commits:
commit 708d19d9 ("drm/amdgpu: move internal vram_mgr function into the C file")
commit 5e3f1e77 ("drm/amdgpu: fix start calculation in amdgpu_vram_mgr_new")
commit c9cad937 ("drm/amdgpu: add drm buddy support to amdgpu")

[WHY]
Few users reported garbaged graphics as soon as x starts,
reverting until this can be resolved.
Signed-off-by: NArunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220708093047.492662-3-Arunpravin.PaneerSelvam@amd.comReviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

This patch ensures that the clock notifier is unregistered
when driver probe is returning error.

Fixes: df8eb569 ("i2c: Add driver for Cadence I2C controller")
Signed-off-by: NSatish Nagireddy <satish.nagireddy@getcruise.com>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NMichal Simek <michal.simek@amd.com>
Signed-off-by: NWolfram Sang <wsa@kernel.org>

Fix exynos-bus NULL pointer dereference by correctly using the local
generated freq_table to output the debug values instead of using the
profile freq_table that is not used in the driver.
Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Fixes: b5d281f6 ("PM / devfreq: Rework freq_table to be local to devfreq struct")
Cc: stable@vger.kernel.org
Signed-off-by: NChristian Marangi <ansuelsmth@gmail.com>
Acked-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>

Fix a kernel NULL pointer dereference reported by gpio kselftests.

linereq_free() can be called as part of the cleanup of a failed request,
at which time the desc for a line may not have been determined, so it
is unsafe to dereference without a check.

Add a check prior to dereferencing the line desc.

Fixes: 2068339a ("gpiolib: cdev: Add hardware timestamp clock type")
Signed-off-by: NKent Gibson <warthog618@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Use the fbcon_info_from_console() wrapper which was added to kernel
v5.19 with commit 409d6c95 ("fbcon: Introduce wrapper for console->fb_info lookup").
Signed-off-by: NHelge Deller <deller@gmx.de>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Verify that the fbdev or drm driver correctly adjusted the virtual
screen sizes. On failure report the failing driver and reject the screen
size change.
Signed-off-by: NHelge Deller <deller@gmx.de>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org # v5.4+

Fix small typo which causes the mask for the 'precharge1' setting
to be used with the 'precharge2' value.
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Acked-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220706184133.210888-1-ezequiel@vanguardiasur.com.ar

We need to prevent that users configure a screen size which is smaller than the
currently selected font size. Otherwise rendering chars on the screen will
access memory outside the graphics memory region.

This patch adds a new function fbcon_modechange_possible() which
implements this check and which later may be extended with other checks
if necessary.  The new function is called from the FBIOPUT_VSCREENINFO
ioctl handler in fbmem.c, which will return -EINVAL if userspace asked
for a too small screen size.
Signed-off-by: NHelge Deller <deller@gmx.de>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org # v5.4+

Prevent that users set a font size which is bigger than the physical screen.
It's unlikely this may happen (because screens are usually much larger than the
fonts and each font char is limited to 32x32 pixels), but it may happen on
smaller screens/LCD displays.
Signed-off-by: NHelge Deller <deller@gmx.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org # v4.14+

Need get the new fence when we replace the old one.

Fixes: 047a1b87 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: Nxinhui pan <xinhui.pan@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220707080241.20060-1-xinhui.pan@amd.comSigned-off-by: NChristian König <christian.koenig@amd.com>

In vma destruction, the following race may occur:

Thread 1:	    		  Thread 2:
i915_vma_destroy();

  ...
  list_del_init(vma->vm_link);
  ...
  mutex_unlock(vma->vm->mutex);
				  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.

However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().

v2: Fix a typo in the commit message (Andi Shyti)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4f ("drm/i915: Remove the vm open count")

Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
Acked-by: NNirmoy Das <nirmoy.das@intel.con>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620123659.381772-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit 1926a6b7)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The only difference between the ADL S and P GuC FWs is the HWConfig
support. ADL-N does not support HWConfig, so we should use the same
binary as ADL-S, otherwise the GuC might attempt to fetch a config
table that does not exist. ADL-N is internally identified as an ADL-P,
so we need to special-case it in the FW selection code.

Fixes: 7e28d0b2 ("drm/i915/adl-n: Enable ADL-N platform")
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220621233005.3952293-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 971e4a97)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If drm_connector_init fails, intel_connector_free will be called to take
care of proper free. So it is necessary to drop the refcount of port
before intel_connector_free.

Fixes: 091a4f91 ("drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624130406.17996-1-jose.souza@intel.comSigned-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit cea9ed61)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Select the new implementation of CHACHA20 for S390 when available.
It is faster than the generic software implementation, but also prevents
some linker errors in certain situations.
Reported-by: Nkernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/linux-kernel/202207030630.6SZVkrWf-lkp@intel.com/Signed-off-by: NVladis Dronov <vdronov@redhat.com>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Various accelerated software implementation Kconfig values for S390 were
mistakenly placed into drivers/crypto/Kconfig, even though they're
mainly just SIMD code and live in arch/s390/crypto/ like usual. This
gives them the very unusual dependency on CRYPTO_HW, which leads to
problems elsewhere.

This patch fixes the issue by moving the Kconfig values for non-hardware
drivers into the usual place in crypto/Kconfig.
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

66e4c8d9 ("net: warn if transport header was not set") added
a check that triggers a warning in r8169, see [0].

The commit referenced in the Fixes tag refers to the change from
which the patch applies cleanly, there's nothing wrong with this
commit. It seems the actual issue (not bug, because the warning
is harmless here) was introduced with bdfa4ed6
("r8169: use Giant Send").

[0] https://bugzilla.kernel.org/show_bug.cgi?id=216157

Fixes: 8d520b4d ("r8169: work around RTL8125 UDP hw bug")
Reported-by: NErhard F. <erhard_f@mailbox.org>
Tested-by: NErhard F. <erhard_f@mailbox.org>
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/1b2c2b29-3dc0-f7b6-5694-97ec526d51a0@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Seems to break hibernation.  Disable for now until we can root
cause it.

Fixes: 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216119Acked-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Was dropped when we converted to the generic helpers.

Fixes: 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
Acked-by: NEvan Quan <evan.quan@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

usbnet_write_cmd_async() mixed up which buffers
need to be freed in which error case.

v2: add Fixes tag
v3: fix uninitialized buf pointer

Fixes: 877bd862 ("usbnet: introduce usbnet 3 command helpers")
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20220705125351.17309-1-oneukum@suse.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

This will allow the trace event to know the full size of the data
intended to be copied and silence read overflow checks.
Reported-by: NJohn Garry <john.garry@huawei.com>
Suggested-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NKeith Busch <kbusch@kernel.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Add the quirk.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216049Reported-by: NChris Egolf <cegolf@ugholf.net>
Signed-off-by: NKeith Busch <kbusch@kernel.org>
Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

Image.dx gets wrong value because of missing '()'.

If xres == logo->width and n == 1, image.dx = -16.
Signed-off-by: NGuiling Deng <greens9@163.com>
Fixes: 3d8b1933 ("fbdev: fbmem: add config option to center the bootup logo")
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: NHelge Deller <deller@gmx.de>

Referenced commit prepared the code for upcoming extension that allows mlx5
to offload police action attached to flower classifier. However, with
regard to existing matchall classifier offload validation should be
reversed as FLOW_ACTION_CONTINUE is the only supported notexceed police
action type. Fix the problem by allowing FLOW_ACTION_CONTINUE for police
action and extend scan_tc_matchall_fdb_actions() to only allow such actions
with matchall classifier.

Fixes: d97b4b10 ("flow_offload: reject offload for all drivers with invalid police parameters")
Signed-off-by: NVlad Buslov <vladbu@nvidia.com>
Acked-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent device will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has already been marked as present.
As the result, the IOMMU probing process will be aborted.

On the contrary, when any alias device is hot-removed from the system,
for example, by writing to /sys/bus/pci/devices/.../remove, the shared
RID2PASID will be cleared without any notifications to other devices.
As the result, any DMAs from those rest devices are blocked.

Sharing pasid table among PCI alias devices could save two memory pages
for devices underneath the PCIe-to-PCI bridges. Anyway, considering that
those devices are rare on modern platforms that support VT-d in scalable
mode and the saved memory is negligible, it's reasonable to remove this
part of immature code to make the driver feasible and stable.

Fixes: ef848b7e ("iommu/vt-d: Setup pasid entry for RID2PASID support")
Reported-by: NChenyi Qiang <chenyi.qiang@intel.com>
Reported-by: NEthan Zhao <haifeng.zhao@linux.intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: NKevin Tian <kevin.tian@intel.com>
Reviewed-by: NEthan Zhao <haifeng.zhao@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220623065720.727849-1-baolu.lu@linux.intel.com
Link: https://lore.kernel.org/r/20220625133430.2200315-2-baolu.lu@linux.intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>

Notifier calling chain uses priority to determine the execution
order of the notifiers or listeners registered to the chain.
PCI bus device hot add utilizes the notification mechanism.

The current code sets low priority (INT_MIN) to Intel
dmar_pci_bus_notifier and postpones DMAR decoding after adding
new device into IOMMU. The result is that struct device pointer
cannot be found in DRHD search for the new device's DMAR/IOMMU.
Subsequently, the device is put under the "catch-all" IOMMU
instead of the correct one. This could cause system hang when
device TLB invalidation is sent to the wrong IOMMU. Invalidation
timeout error and hard lockup have been observed and data
inconsistency/crush may occur as well.

This patch fixes the issue by setting a positive priority(1) for
dmar_pci_bus_notifier while the priority of IOMMU bus notifier
uses the default value(0), therefore DMAR decoding will be in
advance of DRHD search for a new device to find the correct IOMMU.

Following is a 2-step example that triggers the bug by simulating
PCI device hot add behavior in Intel Sapphire Rapids server.

echo 1 > /sys/bus/pci/devices/0000:6a:01.0/remove
echo 1 > /sys/bus/pci/rescan

Fixes: 59ce0515 ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Cc: stable@vger.kernel.org # v3.15+
Reported-by: NZhang, Bernice <bernice.zhang@intel.com>
Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: NYian Chen <yian.chen@intel.com>
Link: https://lore.kernel.org/r/20220521002115.1624069-1-yian.chen@intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>

ldma_clk_disable() calls both:
	clk_disable_unprepare(d->core_clk);
	reset_control_assert(d->rst);

So, should devm_reset_control_get_optional() fail, core_clk should not
be prepare_enable'd before it, otherwise it will never be
disable_unprepare'd.

Reorder the code to handle the error handling path as expected.

Fixes: 32d31c79 ("dmaengine: Add Intel LGM SoC DMA support.")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/18504549bc4d2b62a72a02cb22a2e4d8e6a58720.1653241224.git.christophe.jaillet@wanadoo.frSigned-off-by: NVinod Koul <vkoul@kernel.org>

The DEFINE_SPINLOCK() macro shouldn't be used for dynamically allocated
spinlocks. The lockdep warns about this and disables locking validator.
Fix the warning by making lock static.

 INFO: trying to register non-static key.
 The code is fine but needs lockdep annotation, or maybe
 you didn't initialize this object before use?
 turning off the locking correctness validator.
 Hardware name: Radxa ROCK Pi 4C (DT)
 Call trace:
  dump_backtrace.part.0+0xcc/0xe0
  show_stack+0x18/0x6c
  dump_stack_lvl+0x8c/0xb8
  dump_stack+0x18/0x34
  register_lock_class+0x4a8/0x4cc
  __lock_acquire+0x78/0x20cc
  lock_acquire.part.0+0xe0/0x230
  lock_acquire+0x68/0x84
  _raw_spin_lock_irqsave+0x84/0xc4
  add_desc+0x44/0xc0
  pl330_get_desc+0x15c/0x1d0
  pl330_prep_dma_cyclic+0x100/0x270
  snd_dmaengine_pcm_trigger+0xec/0x1c0
  dmaengine_pcm_trigger+0x18/0x24
  ...

Fixes: e5887103 ("dmaengine: pl330: fix descriptor allocation fail")
Signed-off-by: NDmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/r/20220520181432.149904-1-dmitry.osipenko@collabora.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Instead of counting the child nodes in the device tree, hardcode the
number of ports in the driver itself.  The counting won't work at all
if an ethernet port is marked as disabled, e.g. because it is not
connected on the board at all.

It turns out that the LAN9662 and LAN9668 use the same switching IP
with the same synthesis parameters. The only difference is that the
output ports are not connected. Thus, we can just hardcode the
number of physical ports to 8.

Fixes: db8bcaad ("net: lan966x: add the basic lan966x driver")
Signed-off-by: NMichael Walle <michael@walle.cc>
Reviewed-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
Link: https://lore.kernel.org/r/20220704153654.1167886-1-michael@walle.ccSigned-off-by: NJakub Kicinski <kuba@kernel.org>

commit 72f2ecb7 ("ACPI: bus: Set CPPC _OSC bits for all and
when CPPC_LIB is supported") added support for claiming to
support CPPC in _OSC on non-Intel platforms.

This unfortunately caused a regression on a vartiety of AMD
platforms in the field because a number of AMD platforms don't set
the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support.

As these AMD platforms already claim CPPC support via a dedicated
MSR from `X86_FEATURE_CPPC`, use this enable this feature rather
than requiring the `_OSC` on platforms with a dedicated MSR.

If there is additional breakage on the shared memory designs also
missing this _OSC, additional follow up changes may be needed.

Fixes: 72f2ecb7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported")
Reported-by: NPerry Yuan <perry.yuan@amd.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>