Extract the g4x+ HDMI low level code to its own file,
leaving intel_hdmi.c to deal with higher level issues.
The infoframe support I decided to leave in intel_hdmi.c
since I think we need to move that as a whole to its own file.
It is after all used also for DP SDPs, so no longer HDMI
specific.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-7-ville.syrjala@linux.intel.com
Move the g4x+ DP code into a new file. This will leave mostly
platform agnostic code in intel_dp.c. Well, the misplaced phy
test stuff pretty much ruins that, but let's squint real hard
for now.
v2: Add comment exlaining which platforms are covered (Daniel)
Leave intel_dp_unused_lane_mask() be since it is pretty generic
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-6-ville.syrjala@linux.intel.com
By the specification the 0xF0000 - 0xF02FF range is only valid if the
LTTPR revision at 0xF0000 is at least 1.4. Disable the LTTPR support
otherwise.
Fixes: 7b2a4ab8b0 ("drm/i915: Switch to LTTPR transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-4-imre.deak@intel.com
By the specification the 0xF0000-0xF02FF range is only valid when the
DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so.
Trying to detect LTTPRs returned corrupted values for the above DPCD
range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD
revision 1.2 connected.
v2: Add the actual version check.
v3: Fix s/DRPX/DPRX/ typo.
Fixes: 7b2a4ab8b0 ("drm/i915: Switch to LTTPR transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317190149.4032966-1-imre.deak@intel.com
The spec requires to use at least 3.2ms for the AUX timeout period if
there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
spec update makes this more specific, by requiring a 3.2ms minimum
timeout period for the LTTPR detection reading the 0xF0000-0xF0007
range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout
we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on
some SKL systems with a WD19 dock on the link, which exposes an LTTPR
(see the References below). While this could have different reasons
besides the too short AUX timeout used, not detecting LTTPRs (and so not
using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum
timeout values.
v2: Add a comment about the g4x maximum timeout as well. (Ville)
Reported-by: Takashi Iwai <tiwai@suse.de>
Reported-and-tested-by: Santiago Zarate <santiago.zarate@suse.com>
Reported-and-tested-by: Bodo Graumann <mail@bodograumann.de>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
Fixes: b30edfd8d0 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-2-imre.deak@intel.com
Remove code for resetting frl related members from intel_disable_dp, as
this is not applicable for older platforms.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210309043915.1921-3-ankit.k.nautiyal@intel.com
Add intel_bios_encoder_data pointer to encoder, and use it for hdmi and
dp iboost. For starters, we only set the encoder->devdata for DDI
encoders, i.e. we can only use it for data that is used by DDI encoders.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4bc49244ce68e136e5b21db4c4e6554bec9ac0fb.1615998927.git.jani.nikula@intel.com
Stop caching the information in ddi_port_info. We're phasing out
ddi_port_info usage completely, and prefer using the VBT child device
information directly using the provided helpers.
v2:
- Remove supports_typec_usb & supports_tbt from ddi_vbt_port_info (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b04bd183e7554aeb4bc3962af90d63171aa32fc2.1615998927.git.jani.nikula@intel.com
Start using struct intel_bios_encoder_data directly. We'll start
sanitizing the child device data directly as well, instead of the cached
data in ddi_port_info[]. The one downside here is having to store a
non-const pointer back to intel_bios_encoder_data.
Eventually we'll be able to have a direct pointer from encoder to
intel_bios_encoder_data, removing the need to go through the
ddi_port_info[] array altogether. And we'll be able to remove all the
cached data in ddi_port_info[].
v2:
- Remove supports_dp and supports_edp from ddi_port_info too
- Add devdata != NULL check in intel_bios_is_port_edp()
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> # v1
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/061df32a012ff640060920fcd730fb23f8717ee8.1615998927.git.jani.nikula@intel.com
These will be exposed to the rest of the driver and replace other
functions. Everything will operate on the child devices.
v2:
- Rebased, removed stray blank line
- Also abstracted intel_bios_encoder_supports_crt (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2bd40ccc093796d16300742d1789d78ffac3c450.1615998927.git.jani.nikula@intel.com
Instead of initialing data directly in ddi_port_info array, create fake
child devices for default outputs when the VBT is missing. This makes
further unification of output handling easier.
This will make intel_bios_is_port_present() return true for the fake
child devices. This may cause subtle changes in a handful of places.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/91675b40a78bd04bf138598d979661257181880d.1615998927.git.jani.nikula@intel.com
There are two main cases where the default outputs are useful when the
VBT is missing:
- There are some DDI-platform Chromebooks out there that do not have a
VBT, which worked by coincidence because of the default outputs. The
machines need to continue to work.
- Early platform enabling when the VBT might not be available. (This
could be circumvented by using the i915.vbt_firmware parameter.)
Prepare for generating fake child devices for the default outputs by
limiting the number of outputs. We don't want to generate excessive
amounts of fake child devices. This could be perhaps be limited even
more in the future, but match what's possible on all DDI platforms.
Note that limiting the defaults to non-TypeC ports in commit
828ccb31cf ("drm/i915/icl: Add TypeC ports only if VBT is present") is
a more strict limit, and makes this a no-op on recent platforms.
v2: Rewrote commit message
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5c9c9743af1c7265a2c976d582b7a6685ec0c414.1615998927.git.jani.nikula@intel.com
Pre-DDI and non-CHV aren't using the information created here anyway, so
don't bother setting the defaults for them. This should be a
non-functional change, but is separated here to catch any regressions in
a single commit.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41526a4eee5fb0de8d7f1ffe4c09965b63ccbaa8.1615998927.git.jani.nikula@intel.com
One instance of DRM_DEBUG_KMS was leftover in dp_link_training, convert
it to the new shiny.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210310214845.29021-2-sean@poorly.run
This patch adds some newlines which are missing from debug messages.
This will prevent logs from being stacked up in dmesg.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210310214845.29021-1-sean@poorly.run
SAMPLE_OA parameter enables sampling of OA buffer and results in a call
to init the OA buffer which initializes the OA unit head/tail pointers.
The OA_EXPONENT parameter controls the periodicity of the OA reports in
the OA buffer and results in starting a hrtimer.
Before gen12, all use cases required the use of the OA buffer and i915
enforced this setting when vetting out the parameters passed. In these
platforms the hrtimer was enabled if OA_EXPONENT was passed. This worked
fine since it was implied that SAMPLE_OA is always passed.
With gen12, this changed. Users can use perf without enabling the OA
buffer as in OAR use cases. While an OAR use case should ideally not
start the hrtimer, we see that passing an OA_EXPONENT parameter will
start the hrtimer even though SAMPLE_OA is not specified. This results
in an uninitialized OA buffer, so the head/tail pointers used to track
the buffer are zero.
This itself does not fail, but if we ran a use-case that SAMPLED the OA
buffer previously, then the OA_TAIL register is still pointing to an old
value. When the timer callback runs, it ends up calculating a
wrong/large number of available reports. Since we do a spinlock_irq_save
and start processing a large number of reports, NMI watchdog fires and
causes a crash.
Start the timer only if SAMPLE_OA is specified.
v2:
- Drop SAMPLE OA check when appending samples (Ashutosh)
- Prevent read if OA buffer is not being sampled
Fixes: 00a7f0d715 ("drm/i915/tgl: Add perf support on TGL")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305210947.58751-1-umesh.nerlige.ramappa@intel.com
Rename a bunch of the skl+ watermark struct members to
have sensible names. Avoids me having to think what
plane_res_b/etc. means.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-7-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Make the code more typo proof by extracting small helpers that
do the "do we have enough DDB for the WM level?" checks in
a consistent manner.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-6-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Let's make all the "do we have enough DDB for this WM level?"
checks use min_ddb_alloc. To achieve that we need to populate
this for the transition watermarks as well.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
For non-transition watermarks we are supposed to check min_ddb_alloc
rather than plane_res_b when determining if we have enough DDB space
for it. A bit too much copy pasta made me check the wrong thing.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: df4a50a35e ("drm/i915: Zero out SAGV wm when we don't have enough DDB for it")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Say we have two planes enabled with watermarks configured
as follows:
plane A: wm0=enabled/can_sagv=false, wm1=enabled/can_sagv=true
plane B: wm0=enabled/can_sagv=true, wm1=disabled
This is possible since the latency we use to calculate
can_sagv may not be the same for both planes due to
skl_needs_memory_bw_wa().
In this case skl_crtc_can_enable_sagv() will see that
both planes have enabled at least one watermark level
with can_sagv==true, and thus proceeds to allow SAGV.
However, since plane B does not have wm1 enabled
plane A can't actually use it either. Thus we are
now running with SAGV enabled, but plane A can't
actually tolerate the extra latency it imposes.
To remedy this only allow SAGV on if the highest common
enabled watermark level for all active planes can tolerate
the extra SAGV latency.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-3-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
On HSW/BDW with VT-d active the first tile row scanned out
after the first async flip of the frame often ends up corrupted.
Whether the corruption happens or not depends on the scanline
on which the async flip happens, but the behaviour seems very
consistent. Ie. the same set of scanlines (which are most scanlines)
always show the corruption. And another set of scanlines (far less
of them) never shows the corruption.
I discovered that disabling the fetch-stride stretching
feature cures the corruption. This is some kind of TLB related
prefetch thing AFAIK. We already disable it on SNB primary
planes due to a documented workaround. The hardware folks
indicated that disabling this should be fine, so let's go
with that.
And while we're here, let's document the relevant bits on all
pre-skl platforms.
Fixes: 2a636e240c ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f13a ("drm/i915: Implement async flips for bdw")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210220103303.3448-1-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Let's check that we actually found the PLL before doing the
port_clock readout, just in case the hardware was severly
misprogrammed by the previous guy. Not sure the hw would
even survive such misprogramming without hanging but no
real harm in checking anyway.
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210310194351.6233-1-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Now that all the encoder clock stuff is uniformly abstracted
for all hsw+ platforms, let's extend icl_sanitize_encoder_pll_mapping()
to cover all of them.
Not sure there is a particular benefit in doing so, but less special
cases always makes me happy.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Support reading out the current state of the DDI clock.
Not sure we really want this. Seems a bit excessive just to
restore the debug print to icl_sanitize_encoder_pll_mapping()?
But maybe there's more use for it?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-6-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Move the *_get_ddi_pll() stuff into the encodet->get_config() hook.
There it neatly sits next to the matching .{enable,disable}_clock()
functions.
In order to avoid excessive boilerplate I changed the behaviour
such that all platforms now do the readout via
crtc_state->port_dpll[].
ICL+ TC is still a bit special due to TBTPLL not having a functional
.get_freq(). Should probably change that by adopting the LCPLL
approach, but that would require a fairly substantial rework of the
DPLL ID handling. So leave it for later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-5-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
All the other places we have use pipes instead of crtc indices
when tracking resource usage. Life is easier when we do it
the same way always, so switch the dpll mgr to using pipes as
well. Looks like it was actually mixing these up in some cases
so it would not even have worked correctly except when the
device has a contiguous set of pipes starting from pipe A.
Granted, that is the typical case but supposedly it may not
always hold on modern hw.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
The clock readout for DDI encoders needs to moved into the encoders.
To that end intel_dpll_readout_hw_state() needs to happen after
the encoder readout as otherwise it can't correctly populate
the PLL crtc_mask/active_mask bitmasks.
v2: Populate DPLL ref clocks before the encoder->get_config()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210225161225.30746-1-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Stop assuming intel_ddi_get_config() is all we need from the primary
encoder, and instead call it via the .get_config() vfunc. This
will allow customized .get_config() for the primary, which I plan
to use to handle the differences in the clock readout between various
platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
- Fix corner cases in the rxe reference counting cleanup that are causing
regressions in blktests for SRP
- Two kdoc fixes so W=1 is clean
- Missing error return in error unwind for mlx5
- Wrong lock type nesting in IB CM
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEfB7FMLh+8QxL+6i3OG33FX4gmxoFAmBCeEwACgkQOG33FX4g
mxohmQ/7Bnf52Ay59dqdQzc8nDPXMwQ5ejZke+MnYZG3j79UqNQrbEnLJ8Y2BlQU
IkpdTi8zUHm69GH7Ix9m/FsW52XFUuq2OEfGLvZNRUhi7hGEmc6llvfCK9y6a4Mt
VEpyo7vC4QvA1OvMBF3Zv91jylKPJt5U51OuRtbh+6eoS6oVm7ajjOay+USYT/kX
3zftTd6DUg6vpUP5j2WvjocgKUVGsh8GiyA3xC7u7AUTemcxvZ40wB535fLpn1JC
ObU8aiRKw0Ib5JbRukCFFBV13kmA3lnAEy0SktPVhIoeUnF0m1vNtAJrdnHsWPxW
lxtAXA3bN3oINhsEhnBllONKRxlqsUz7KT5bVAehsl8LENNLHhJWp0hwKawKK74K
5MAQ+P6CIW8TLMKeOcYMXBD2UiElc9sdhYsDliM7leclftwOO5gFI4WgTWrQwxvl
m+KewiByT6pzK7oyGvg9w/dl3y7atzy8y/7uMAfI2L6oL43z9yt24hHQTo3Z7UM7
/bbSas/yRbZujB7qE45c6NvwRFQk6mYTK0Is0huMWOLn0Zf0fVcy3um0q+OKQ7At
VS1Z7Fhy+ev1Lk764n5rmVUx8NWDlXkzwX7qk7SnQk7dWQ5lNFbziFDKmkiKgcAa
//oN0I/FbAM4FjhKImRzbXJiLdULxJCqpfQ5VXbUXlfXdpzjabY=
=j5ZU
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
"Nothing special here, though Bob's regression fixes for rxe would have
made it before the rc cycle had there not been such strong winter
weather!
- Fix corner cases in the rxe reference counting cleanup that are
causing regressions in blktests for SRP
- Two kdoc fixes so W=1 is clean
- Missing error return in error unwind for mlx5
- Wrong lock type nesting in IB CM"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/rxe: Fix errant WARN_ONCE in rxe_completer()
RDMA/rxe: Fix extra deref in rxe_rcv_mcast_pkt()
RDMA/rxe: Fix missed IB reference counting in loopback
RDMA/uverbs: Fix kernel-doc warning of _uverbs_alloc
RDMA/mlx5: Set correct kernel-doc identifier
IB/mlx5: Add missing error code
RDMA/rxe: Fix missing kconfig dependency on CRYPTO
RDMA/cm: Fix IRQ restore in ib_send_cm_sidr_rep
- Fix coding style issues (Jason Yan)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpcP2jyKd1g9yPm4TiXL039xtwCYFAmBCursACgkQiXL039xt
wCZWzw//aBKQN8oUisNVhzWnUOpXEFV1GfJPaqgdZv89fCSnC20ojxzxXG4bTVod
mnDvkYYAce3A8uLyACdt2iVdXCKF5LbiglkipqK6S4N/0DzoN4IBhgEtmNxMswjc
LwXTzG3R7lu6J2CQatk0uRd2QLVWBHkjyMWRBpg3ryYJoj2ROscWlCL86u3Kdwyh
2XKozHs+mTrDz7sOHeDlEfeJTF7AniN3Px6ajf0st0up5NIiZ70uuaHqhKMWuYji
4fnO2Pf2G0b9QaB6W7k0S/M2VGhmd+1h3psI9PJJ3glrKe3WsHRm9Akq8MF08vr7
UEvYqEPuU6/YJDEXJ3C22xEeN9HBfXgrX1qAf/1/mE9c1AGvIPNmQYp+xE1xSXzO
79GRPf1OrZLntJuQG9ir1BrhryehrynhH2dS0F1ByT2u/lYpGw9o+vu7rpnQ6DUR
sjnhJSCyzDMHdZPzaUldFaydEquDE5LohY2TQDeWtT6tBtkjIONj0YqGlm2IlzFL
OlM0YkjSd4fDlKIhMbP/Vm+ScAJfs3dR7cWwn3F3JIoDTZf5f4IAbsKCyPJ3wIHm
A0BEXs9bZ4MCmNPtZDuSGExnHs+te4yBoahkvw/84TG2PBJVOCDdB4F7noFu47vJ
1QvL7TiRTr782fqZQwSTUZZHxmc6NhZRySsXRIHBA4AyboPnnYk=
=oow8
-----END PGP SIGNATURE-----
Merge tag 'gcc-plugins-v5.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull gcc-plugins fixes from Kees Cook:
"Tiny gcc-plugin fixes for v5.12-rc2. These issues are small but have
been reported a couple times now by static analyzers, so best to get
them fixed to reduce the noise. :)
- Fix coding style issues (Jason Yan)"
* tag 'gcc-plugins-v5.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
gcc-plugins: latent_entropy: remove unneeded semicolon
gcc-plugins: structleak: remove unneeded variable 'ret'
Reed-Solomon roots that are unaligned to block size.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEJfWUX4UqZ4x1O2wixSPxCi2dA1oFAmBCgmkTHHNuaXR6ZXJA
cmVkaGF0LmNvbQAKCRDFI/EKLZ0DWlF9B/481eKdOYK5RLj6LneVf10niUACEN0G
tp8CeKh2wEcTjX+9pWxvigAE7FZnvD0sCts3eRCd8egkdV3L9uHyaCHU9V8iGP8L
dSjHXjbwbOumww5FY1ddx2ZiRImcU7YpEj5TrUZi2TyoAB2jOblDgaUt8jWsbppa
8miPUZi0Kp56Z5EsFJcT8dYbIlLfUpD/XfZ0hjqMoc9XZOeoGvYqpYX1pZgIfj2s
F23Dru858zqjv7OLmIgjzSgS0dZSwdLMUpKInaW1AipvNQpWSuh2DQdP7Ail3+yy
gUirpBjztoYCfqwpQTJpGnnb47tECYUXef6dI7xR5bXnyaX8CG5bRvVV
=a00f
-----END PGP SIGNATURE-----
Merge tag 'for-5.12/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"Fix DM verity target's optional Forward Error Correction (FEC) for
Reed-Solomon roots that are unaligned to block size"
* tag 'for-5.12/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm verity: fix FEC for RS roots unaligned to block size
dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmBCa2kQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpo5TEADb8p//Qr/Uv8hiVqvrMKoVbiJ+ZXB+Z+6k
ZMlcOryHWLbNOYYsA6soUygRkEFlFyUhfWJEvIYIr612s964+aD8cH9JhpPbGzkd
rTGUWeHXcW0is03AgEsq5SmjRO3zI+I0Ln2IMlePY+W8xwIL8jI3pf+LiI/gzJcG
sOxqgtS3zBzby3sU/9LDJfBCB4soqBcrp/6G6p2tK+gtVsud122LInl2/gGtXml4
AT15T1JaPbdnOCFXiy+GIK+AQiITfmPBiM+m7mh2LabxJNTDtYSrwh5rjKQjVpyi
N+AwVTeshzDbuoac6yuZSkLRPFfSPdgeefqCGNcpSjdJiJsvwQWHqf119CKYraLd
d2nOn4YRK4dtLWlu4bZkJCUC+KWQhCfQNAeu/ok9OQ7d6eKmigiDA+YlAf9NdymL
yknWzjjVxFwDKO/fGuOXq3kj/EW5JNgX1/esJAilVBojzavR9uu+fxVCvohEbc6I
hJ9hXijY1R3wmbJbpFRo8msKSifgaFVVrb2bKUbxtUI6er1mJ+dkAM8MeKf6+LTq
DLfyoD8o4F9+dJqHfRKIt+Pdgrm0nvcgxDPykAsX5vMoAwgeVIcyRK59wPOnTMWV
NaRabO85hEdkTTdAB10UB7Ix7PTNHGtCxfvb9mNnPDYMrHr8qolRfCzQW9nULzLi
ggVLgn2RLQ==
=Cd/Z
-----END PGP SIGNATURE-----
Merge tag 'block-5.12-2021-03-05' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
- NVMe fixes:
- more device quirks (Julian Einwag, Zoltán Böszörményi, Pascal
Terjan)
- fix a hwmon error return (Daniel Wagner)
- fix the keep alive timeout initialization (Martin George)
- ensure the model_number can't be changed on a used subsystem
(Max Gurtovoy)
- rsxx missing -EFAULT on copy_to_user() failure (Dan)
- rsxx remove unused linux.h include (Tian)
- kill unused RQF_SORTED (Jean)
- updated outdated BFQ comments (Joseph)
- revert work-around commit for bd_size_lock, since we removed the
offending user in this merge window (Damien)
* tag 'block-5.12-2021-03-05' of git://git.kernel.dk/linux-block:
nvmet: model_number must be immutable once set
nvme-fabrics: fix kato initialization
nvme-hwmon: Return error code when registration fails
nvme-pci: add quirks for Lexar 256GB SSD
nvme-pci: mark Kingston SKC2000 as not supporting the deepest power state
nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST.
rsxx: Return -EFAULT if copy_to_user() fails
block/bfq: update comments and default value in docs for fifo_expire
rsxx: remove unused including <linux/version.h>
block: Drop leftover references to RQF_SORTED
block: revert "block: fix bd_size_lock use"
Ville Syrjälä