New workaround added to specification, requiring bit 15 of
GEN8_CHICKEN_DCPR_1 to be programed before power well 1 is enabled.

BSpec: 54369
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211028230449.115832-1-jose.souza@intel.com

This reverts commit 1f61f065.

Now we are supporting selective fetch for biplanar formats.
We can revert WA patch which forced using full fetch for biplanar
formats.
Signed-off-by: NJouni Högander <jouni.hogander@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021101024.13112-3-jouni.hogander@intel.com

Biplanar formats are using two planes (Y and UV). This patch adds handling
of Y selective fetch area by utilizing existing linked plane mechanism.
Also UV plane Y offset configuration is modified according to Bspec.
Signed-off-by: NJouni Högander <jouni.hogander@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021101024.13112-2-jouni.hogander@intel.com

By using the modifier plane capability flags to encode the modifiers'
CCS type and tiling attributes, it becomes simpler to the check for
any of these capabilities when providing the list of supported
modifiers.

This also allows distinguishing modifiers on future platforms where
platforms with the same display version support different modifiers. An
example is DG2 and ADLP, both being D13, where DG2 supports only F and X
tiling, while ADLP supports only Y and X tiling. With the
INTEL_PLANE_CAP_TILING_* flags added in this patch we can provide
the correct modifiers for each platform.

v2:
- Define PLANE_HAS_* with macros instead of an enum. (Jani)
- Rename PLANE_HAS_*_ANY to PLANE_HAS_*_MASK. (Jani)
- Rename PLANE_HAS_* to INTEL_PLANE_CAP_*.
- Set the CCS_RC_CC cap only for DISPLAY_VER >= 12.
- Set the TILING_Y cap only for DISPLAY_VER < 13 || ADLP.
- Simplify the SKL plane cap display version checks and move them
  to a separate function.

Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027125150.2891371-1-imre.deak@intel.com

Variables of enum types can contain only the values listed at the enums
definition, so don't store bitmasks in intel_plane_caps enum variables.

Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026161517.2694067-3-imre.deak@intel.com

Remove the MC CCS plane capability on GEN<12, since it's not present
there. This didn't cause a problem, since the display version check
filtered out the MC CCS modifiers before GEN12.

Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026161517.2694067-2-imre.deak@intel.com

Backmerge to get the DP 2.0 MST changes merged to drm-next. This also
syncs us up to v5.15-rc7.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Our lane power down defines already include the necessary shift,
don't shift them a second time.

Fortunately we masked off the correct bits, so we accidentally
left all lanes powered up all the time.

Bits 8-11 where we end up writing our misdirected lane mask are
documented as MBZ, but looks like you can actually write there
so they're not read only bits. No idea what side effect the
bogus register write might have.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4151Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-17-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Looks like we never updated intel_bios_is_port_dp_dual_mode() when
the VBT port mapping became erratic on modern platforms. This
is causing us to look up the wrong child device and thus throwing
the heuristic off (ie. we might end looking at a child device for
a genuine DP++ port when we were supposed to look at one for a
native HDMI port).

Fix it up by not using the outdated port_mapping[] in
intel_bios_is_port_dp_dual_mode() and rely on
intel_bios_encoder_data_lookup() instead.

Cc: stable@vger.kernel.org
Tested-by: NRandy Dunlap <rdunlap@infradead.org>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025142147.23897-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

PSR2 is supported in transcoder A and B on Alderlake-P.

v2:
- explicity checking for transcoder A and B to avoid invalid transcoder

BSpec: 49185
Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jouni Hogander <jouni.hogander@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com> # v2
Link: https://patchwork.freedesktop.org/patch/msgid/20211027180545.55660-1-jose.souza@intel.com

The PPS, RC_RANGE_PARAM, and RC_BUF_THRESH logging are clearly for
debugging, and should not be info level messages.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027135900.6329-1-jani.nikula@intel.com

Add FourCCs for 10- and 12-bit red formats with padding to 16 bits.
They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10
and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the
same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern
permutations).

These formats are not used by any kernel driver at this point, but need
to be exposed to applications by libcamera, which uses DRM FourCCs for
pixel formats.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com

* eDP support in DP sub-driver (for newer SoCs with native eDP output)
* dpu irq handling cleanup
* CRC support for making igt happy
* Support for NO_CONNECTOR bridges
* dsi: 14nm phy support for msm8953
* mdp5: support for msm8x53, sdm450, sdm632
* various smaller fixes and cleanups
Signed-off-by: NDave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsH9EwcpqGNNRJeL99NvFFjHX3SUg+nTYu0dHG5U9+QuA@mail.gmail.com

The msm next tree is based on rc3, so let's just backmerge rc7 before pulling it in.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Merge tag 'topic/amdgpu-dp2.0-mst-2021-10-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

UAPI Changes:
Nope!

Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is

Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...

Driver Changes:
...and then add support for taking advantage of this for 128b/132b links on DP
2.0 for amdgpu
Signed-off-by: NDave Airlie <airlied@redhat.com>
From: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf8e724cc0c8803d58a8d730fd6883c991376a76.camel@redhat.com

Need to guard some things with CONFIG_DRM_AMD_DC_DCN.

Fixes: 41724ea2 ("drm/amd/display: Add DP 2.0 MST DM Support")
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027223914.1776061-1-alexander.deucher@amd.com

Now that the bigjoiner state readout/computation has been
made to do the right thing nuke the related state checker
quirk.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-10-ville.syrjala@linux.intel.com

Try to make bigjoiner pipes less special.

The main things here are that each pipe now does full
clock computation/readout with its own shared_dpll reference.
Also every pipe's cpu_transcoder always points correctly
at the master transcoder.

Due to the above changes state readout is now complete
and all the related hacks can go away. The actual modeset
sequence code is still a mess, but I think in order to clean
that up properly we're probably going to have to redesign
the modeset logic to treat transcoders vs. pipes separately.
That is going to require significant amounts of work.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-9-ville.syrjala@linux.intel.com

Read out cpu_transcoder correctly for the bigjoiner slave pipes.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-8-ville.syrjala@linux.intel.com

The PPS SDP is fed into the transcoder whereas the DSC
block is (or at least can be) per pipe. Let's split these
into two distinct operations in an effort to untagle the
bigjoiner mess where we have two pipes feeding a single
transcoder.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-7-ville.syrjala@linux.intel.com

Rewrite intel_crtc_copy_uapi_to_hw_state_nomodeset() in a
slightly more straightforward manner.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-6-ville.syrjala@linux.intel.com

Add a helper to determine the master crtc for bigjoiner usage.
Also name the variables consistently.
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-5-ville.syrjala@linux.intel.com

Let's disable planes on all pipes affected by the modeset before
we start doing the actual modeset. This means we have less
random planes enabled during the modeset, and it also mirrors
what we already do when enabling pipes on skl+ since we enable
planes on all pipes as the very last step. As a bonus we also
nuke a bunch og bigjoiner special casing.

I've occasionally pondered about going even furher here and
doing the pre_plane_update() stuff for all pipes first, then
actually disabling the planes, and finally running the rest
of the modeset sequence. This would potentially allow
parallelizing all the extra vblank waits across multiple pipes,
and would make the plane disable even more atomic. But let's
go one step a time here.

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-4-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Disabling planes in the middle of the modeset seuqnece does not make
sense since userspace can anyway disable planes before the modeset
even starts. So when the modeset seuqence starts the set of enabled
planes is entirely arbitrary. Trying to sprinkle the plane disabling
into the modeset sequence just means more randomness and potential
for hard to reproduce bugs.

So it makes most sense to just disable all planes first so that the
rest of the modeset sequence remains identical regardless of which
planes happen to be enabled by userspace at the time.

This reverts commit 84030adb.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

PSR2 apparently requires some planes to be enabled for some
silly reason, and so we are now trying to turn PSR off before
planes go off. Except during a full modeset that is handled
less clearly through reorganization of the modeset sequence.
That is not great as it makes the code mode complex, and
prevents us from doing nice things such as just turning off
all the planes at the very start of the modeset. So let's
move the PSR pre_plane_update() thing to a spot where it
will handle both full modesets and everything else.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-2-ville.syrjala@linux.intel.comReviewed-by: NJouni Högander <jouni.hogander@intel.com>

The asm/iosf_mbi.h header is x86-only. Let's make IOSF_MBI kconfig
selection conditional to x86 and provide a header with stubs for other
architectures. This helps getting i915 available for other
architectures in future.
Signed-off-by: NMullati, Siva <siva.mullati@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022192756.1228354-1-siva.mullati@intel.com

Merge tag 'amd-drm-next-5.16-2021-10-22' of https://gitlab.freedesktop.org/agd5f/linux into drm-next

amd-drm-next-5.16-2021-10-22:

amdgpu:
- PSP fix for resume
- XGMI fixes
- Interrupt fix in device tear down
- Renoir USB-C DP alt mode fix for resume
- DP 2.0 fixes
- Yellow Carp display fixes
- Misc display fixes
- RAS fixes
- IP Discovery enumeration fixes
- VGH fixes
- SR-IOV fixes
- Revert ChromeOS workaround in display code
- Cyan Skillfish fixes

amdkfd:
- Fix error handling in gpu memory allocation
- Fix build warnings with some configs
- SVM fixes
Signed-off-by: NDave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022183112.4574-1-alexander.deucher@amd.com

Alderlake-P was getting 'max time under evasion' messages when PSR2
is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
period of time longer than VBLANK_EVASION_TIME_US.

For PSR1 we had the same issue so intel_psr_wait_for_idle() was
implemented to wait for PSR1 to get into idle state but nothing was
done for PSR2.

For PSR2 we can't only wait for idle state as PSR2 tends to keep
into sleep state(ready to send selective updates).
Waiting for any state below deep sleep proved to be effective in
avoiding the evasion messages and also not wasted a lot of time.

v2:
- dropping the additional wait_for loops, only the _wait_for_atomic()
is necessary
- waiting for states below EDP_PSR2_STATUS_STATE_DEEP_SLEEP

v3:
- dropping intel_wait_for_condition_atomic() function

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005231851.67698-1-jose.souza@intel.com

Some randconfig builds fail when drm/drm_bridge.h is not included
implicitly in this file:

drivers/gpu/drm/msm/dp/dp_parser.c:279:25: error: implicit declaration of function 'devm_drm_panel_bridge_add' [-Werror,-Wimplicit-function-declaration]
        parser->panel_bridge = devm_drm_panel_bridge_add(dev, panel);

Fixes: 4b296d15 ("drm/msm/dp: Allow attaching a drm_panel")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211026083254.3396322-1-arnd@kernel.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

Clang warns:

drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:162:6: error: variable 'commit' is uninitialized when used here [-Werror,-Wuninitialized]
        if (commit)
            ^~~~~~
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:106:32: note: initialize the variable 'commit' to silence this warning
        struct drm_crtc_commit *commit;
                                      ^
                                       = NULL
1 error generated.

The assignment and use of commit in the main body of
dpu_crtc_set_crc_source() were removed from v1 to v2 but the call to
drm_crtc_commit_put() at the end was not. Do that now so there is no
more warning.

Fixes: 78d9b458 ("drm/msm/dpu: Add CRC support for DPU")
Link: https://github.com/ClangBuiltLinux/linux/issues/1493Reported-by: N"kernelci.org bot" <bot@kernelci.org>
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211026142435.3606413-1-nathan@kernel.orgSigned-off-by: NRob Clark <robdclark@chromium.org>

The intermediate value 1000000 * 10 * 9671 overflows 32 bits, so force
promotion to a bigger type.

From the logs:

[drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available -580783288

v2: Use mul_u32_u32() (Ville)

Fixes: 48efd014 ("drm/i915/dp: add max data rate calculation for UHBR rates")
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026093407.11381-1-jani.nikula@intel.com

[Why]
Add DP2 MST and debugfs support

[How]
Update the slot info based on the link encoding format
Reviewed-by: N"Lin, Wayne" <Wayne.Lin@amd.com>
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-5-lyude@redhat.com

[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.

[How]
- add encoding type, logging, mst update/reduce payload functions

Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine whether to increase/reduce
payloads.

v2:
* add DP_UNKNOWN_ENCODING handling
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: N"Lin, Wayne" <Wayne.Lin@amd.com>
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-4-lyude@redhat.com

8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.

In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.

v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check

v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
  atomic drivers (this is a temporary workaround and should be removed when
  we are moving out the non atomic driver helpers)

v4:
*fixed typo and formatting

v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: NFangzhi Zuo <Jerry.Zuo@amd.com>
[v5 nitpicks]
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-3-lyude@redhat.com

This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-2-lyude@redhat.com

Commit 11086054 ("mm/secretmem: use refcount_t instead of atomic_t")
attempted to fix the problem of secretmem_users wrapping to zero and
allowing suspend once again.

But it was reverted in commit 87066fdd ("Revert 'mm/secretmem: use
refcount_t instead of atomic_t'") because of the problems it caused - a
refcount_t was not semantically the right type to use.

Instead prevent secretmem_users from wrapping to zero by forbidding new
users if the number of users has wrapped from positive to negative.
This stops a long way short of reaching the necessary 4 billion users
where it wraps to zero again, so there's no need to be clever with
special anti-wrap types or checking the return value from atomic_inc().
Signed-off-by: NMatthew Wilcox (Oracle) <willy@infradead.org>
Cc: Jordy Zomer <jordy@pwning.systems>
Cc: Kees Cook <keescook@chromium.org>,
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit efafec27 ("spi: Fix tegra20 build with CONFIG_PM=n") already
fixed the build without PM support once.  There was an alternative fix
by Guenter in commit 2bab9409 ("spi: tegra20-slink: Declare runtime
suspend and resume functions conditionally"), and Mark then merged the
two correctly in ffb1e76f ("Merge tag 'v5.15-rc2' into spi-5.15").

But for some inexplicable reason, Mark then merged things _again_ in
commit 59c4e190 ("Merge tag 'v5.15-rc3' into spi-5.15"), and screwed
things up at that point, and the __maybe_unused attribute on
tegra_slink_runtime_resume() went missing.

Reinstate it, so that alpha (and other architectures without PM support)
builds cleanly again.

Btw, this is another prime example of how random back-merges are not
good.  Just don't do them.  Subsystem developers should not merge my
tree in any normal circumstances.  Both of those merge commits pointed
to above are bad: even the one that got the merge result right doesn't
even mention _why_ it was done, and the one that got it wrong is
obviously broken.
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull ARM fixes from Russell King:

 - Fix clang-related relocation warning in futex code

 - Fix incorrect use of get_kernel_nofault()

 - Fix bad code generation in __get_user_check() when kasan is enabled

 - Ensure TLB function table is correctly aligned

 - Remove duplicated string function definitions in decompressor

 - Fix link-time orphan section warnings

 - Fix old-style function prototype for arch_init_kprobes()

 - Only warn about XIP address when not compile testing

 - Handle BE32 big endian for keystone2 remapping

* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: 9148/1: handle CONFIG_CPU_ENDIAN_BE32 in arch/arm/kernel/head.S
  ARM: 9141/1: only warn about XIP address when not compile testing
  ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype
  ARM: 9138/1: fix link warning with XIP + frame-pointer
  ARM: 9134/1: remove duplicate memcpy() definition
  ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned
  ARM: 9132/1: Fix __get_user_check failure with ARM KASAN images
  ARM: 9125/1: fix incorrect use of get_kernel_nofault()
  ARM: 9122/1: select HAVE_FUTEX_CMPXCHG

Pull libata fix from Damien Le Moal:
 "A single fix in this pull request addressing an invalid error code
  return in the sata_mv driver (from Zheyu)"

* tag 'libata-5.15-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
  ata: sata_mv: Fix the error handling of mv_chip_id()