Update 5.4-lts to match Linux kernel v5.4.144

drm: Copy drm_wait_vblank to user before returning

[ Upstream commit fa0b1ef5f7a694f48e00804a391245f3471aa155 ]

[Why]
Userspace should get back a copy of drm_wait_vblank that's been modified
even when drm_wait_vblank_ioctl returns a failure.

Rationale:
drm_wait_vblank_ioctl modifies the request and expects the user to read
it back. When the type is RELATIVE, it modifies it to ABSOLUTE and updates
the sequence to become current_vblank_count + sequence (which was
RELATIVE), but now it became ABSOLUTE.
drmWaitVBlank (in libdrm) expects this to be the case as it modifies
the request to be Absolute so it expects the sequence to would have been
updated.

The change is in compat_drm_wait_vblank, which is called by
drm_compat_ioctl. This change of copying the data back regardless of the
return number makes it en par with drm_ioctl, which always copies the
data before returning.

[How]
Return from the function after everything has been copied to user.

Fixes IGT:kms_flip::modeset-vs-vblank-race-interruptible
Tested on ChromeOS Trogdor(msm)

Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210812194917.1703356-1-markyacoub@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event

On ARCTURUS and RENOIR, powerplay is not supported yet.
When plug in or unplug power jack, ACPI event will issue.
Then kernel NULL pointer BUG will be triggered.
Check for NULL pointers before calling.

Signed-off-by: Aaron Ma aaron.ma@canonical.com
Signed-off-by: Alex Deucher alexander.deucher@amd.com
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

Chase for latest MFCs to stable/13

Update checks for __FreeBSD_version[1] after MFCs to stable/13 were done.

[1] ((__FreeBSD_version < 1400000) && (__FreeBSD_version >= 1300512))

Co-authored-by: Bjoern A. Zeeb bz@FreeBSD.org

Chase for latest MFCs to stable/13

Update checks for __FreeBSD_version[1] after MFCs to stable/13 were d…

…one.

[1] ((__FreeBSD_version < 1400000) && (__FreeBSD_version >= 1300512))

Co-authored-by: Bjoern A. Zeeb <bz@FreeBSD.org>