It wasn't terribly clear from the bspec's wording, but after discussion
with the hardware folks, it turns out that we need to preserve the
pre-existing contents of the MBUS ABOX control register when
initializing a few specific bits.
Bspec: 49213
Bspec: 50096
Fixes: 4cb4585e5a ("drm/i915/icl: initialize MBus during display init")
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-1-matthew.d.roper@intel.com
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
We have to write quite a few registers when programming the
pipe scaler. Let's use intel_de_write_fw() for these to reduce
the lockdep overhead a bit. All plane registers (including plane
scaler) already do this.
We already had a few accidental intel_de_write_fw() in there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT}
bits in intel_connector->polled (the base setting), leading to
some confusing looking code to reset drm_connector->polled
(the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set
intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd
capable connectors, and then we don't need so many special
cases in the hotplug code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
No point in looping over all connectors for each hpd pin. Just loop
over each connector first and deal with each one's hpd pin. Then
loop over all the hpd pins to mark them as enabled again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
UAPI Changes:
- lima: Add support for heap buffers
Cross-subsystem Changes:
Core Changes:
- Implement mode_config mode_valid for memory constrained drivers
- Bus format negociation between bridges
- Consolidate fake vblank events for drivers without vblank interrupts
- drm/bufs: dma_alloc related cleanups
- drm/dp_mst: Various fixes
- drm/print: New drm_device based print helpers
- Thomas is a drm-misc maintainer now!
Driver Changes:
- DPMS cleanups for atomic drivers
- Removal of owner field in SPI tinydrm drivers
- Removal of explicit dependency on DT for tinydrm drivers
- Conversion to YAML schemas for DT bindings
- tidss: New driver
- virtio: various reworks and fixes
- Our usual dozen or so new panels or bridges
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXkEjOgAKCRDj7w1vZxhR
xeaDAQD+1MludG4RmfQhATe4jTsPC1r2x63OF2CA0ChMGHXJyQEA8qqQ+8y1Cd/u
PZ3PpcTl4qYYHgzJ6FwW7kDPTvlaZQE=
=IJAt
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2020-02-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.7:
UAPI Changes:
- lima: Add support for heap buffers
Cross-subsystem Changes:
Core Changes:
- Implement mode_config mode_valid for memory constrained drivers
- Bus format negociation between bridges
- Consolidate fake vblank events for drivers without vblank interrupts
- drm/bufs: dma_alloc related cleanups
- drm/dp_mst: Various fixes
- drm/print: New drm_device based print helpers
- Thomas is a drm-misc maintainer now!
Driver Changes:
- DPMS cleanups for atomic drivers
- Removal of owner field in SPI tinydrm drivers
- Removal of explicit dependency on DT for tinydrm drivers
- Conversion to YAML schemas for DT bindings
- tidss: New driver
- virtio: various reworks and fixes
- Our usual dozen or so new panels or bridges
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200210093421.xu4sofldm6wm6xq6@gilmour.lan
We are quite trigger happy in cleaning up the firmware blobs, as we do
so from several error/fini paths in GuC/HuC/uC code. We do have the
__uc_cleanup_firmwares cleanup function, which unwinds
__uc_fetch_firmwares and is already called both from the error path of
gem_init and from gem_driver_release, so let's stop cleaning up from
all the other paths.
The fact that we're not cleaning the firmware immediately means that
we can't consider firmware availability as an indication of
initialization success. A "LOADABLE" status has been added to
indicate that the initialization was successful, to be used to
selectively load HuC only if HuC init has completed (HuC init failure
is not considered a fatal error).
v2: s/ready_to_load/loadable (Michal), only run guc/huc_fini if the
fw is in loadable state
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-9-daniele.ceraolospurio@intel.com
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
restricted to running only if we have successfully fetched the required
blob(s) and are committed to using the microcontroller(s).
The only remaining thing that can go wrong in uc_init is the allocation
of GuC/HuC related objects; if we get such a failure better to bail out
immediately instead of wedging later, like we do for e.g.
intel_engines_init, since without objects we can't use the HW, including
not being able to attempt the firmware load.
While at it, remove the unneeded fw_cleanup call (this is handled
outside of gt_init) and add a probe failure injection point for testing.
Also, update the logs for <g/h>uc_init failures to probe_failure() since
they will cause the driver load to fail.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-8-daniele.ceraolospurio@intel.com
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
v2: move functions to guc_submission.h (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-7-daniele.ceraolospurio@intel.com
To be able to setup GuC submission functions during engine init we need
to commit to using GuC as soon as possible.
Currently, the only thing that can stop us from using the
microcontrollers once we've fetched the blobs is a fundamental
error (e.g. OOM); given that if we hit such an error we can't really
fall-back to anything, we can "officialize" the FW fetching completion
as the moment at which we're committing to using GuC.
To better differentiate this case, the uses_guc check, which indicates
that GuC is supported and was selected in modparam, is renamed to
wants_guc and a new uses_guc is introduced to represent the case were
we're committed to using the GuC. Note that uses_guc does still not imply
that the blob is actually loaded on the HW (is_running is the check for
that). Also, since we need to have attempted the fetch for the result
of uses_guc to be meaningful, we need to make sure we've moved away
from INTEL_UC_FIRMWARE_SELECTED.
All the GuC changes have been mirrored on the HuC for coherency.
v2: split fetch return changes and new macros to their own patches,
support HuC only if GuC is wanted, improve "used" state
description (Michal)
v3: s/wants_huc/uses_huc in uc_init_wopcm
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-6-daniele.ceraolospurio@intel.com
We want to map uC-level checks to GuC/HuC-level ones. The mapping from
the uC state to the GuC/HuC one follows the same pattern for all the
functions:
uc_xxx_guc() -> guc_is_yyy()
So we can easily use a macro to autogenerate the functions via macros by
passing in the 2 mapped states.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-5-daniele.ceraolospurio@intel.com
In a follow up patch we will rely on the fact that the status always
moves away from "SELECTED" after the fetch is attempted to decide what
to do with the GuC.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-4-daniele.ceraolospurio@intel.com
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
v2: do not go through ctx->vm->gt, use i915->gt instead
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-3-daniele.ceraolospurio@intel.com
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
v2: split guc_log_info changes to their own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-2-daniele.ceraolospurio@intel.com
The log struct is the only thing the function needs (apart from
the seq_file), so we can pass just that instead of the whole dev_priv.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-1-daniele.ceraolospurio@intel.com
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b6 ("drm/i915: Push the wakeref->count deferral to the backend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220123608.1666271-1-chris@chris-wilson.co.uk
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes: 793c226173 ("drm/i915/gt: Protect execlists_hold/unhold from new waiters")
Fixes: 32ff621fd7 ("drm/i915/gt: Allow temporary suspension of inflight requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220075025.1539375-1-chris@chris-wilson.co.uk
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediator itself. This is a first step.
v2:
- rebased onto gvt-staging (no conflicts)
Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200217163858.26496-1-julian.stecklina@cyberus-technology.de
If one of the synced crtcs needs a full modeset, we need
to make sure all the synced crtcs are forced a full
modeset.
v3:
* Remove ~BIT(cpu_trans) which is a nop (Ville)
* use get_new_crtc_state and remove error check (Ville)
v2:
* Add tiles based on cpu_trans check (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-3-manasi.d.navare@intel.com
This patch pushes out the computation of master and slave
transcoders in crtc states after encoder's compute_config hook.
This ensures that the assigned master slave crtcs have exact same
mode and timings which is a requirement for Port sync mode
to be enabled.
v3:
* Make crtc_state const, remove crtc state NULL init (Ville)
v2:
* Correct indentation
* Rename to intel_ddi_port_sync_transcoders (Ville)
* remove unwanted debug (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-2-manasi.d.navare@intel.com
Add an optional secondary encoder state compute hook. This gets
called after the normak .compute_config() has been called for
all the encoders in the state. Thus in the new hook we can rely
on all derived state populated by .compute_config() to be already
set up. Should be useful for MST and port sync master/slave
transcoder selection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-1-manasi.d.navare@intel.com
For dgfx, we do not need to reconfigure the IA/ring frequencies of the
main processors as they are distinct devices.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219130119.1457693-1-chris@chris-wilson.co.uk
Currently, we check that a new context has a clear set of general
purpose registers. Add a little bit of hostility by preempting our new
context and re-poisoning the GPR to ensure that there is no context
leakage from preemption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219123418.1447428-1-chris@chris-wilson.co.uk
On dgfx, we only use l3cc and not mocs, but we share the table
containing both register definitions with Tigerlake. This confuses our
selftest that verifies that both sets of registers do contain the values
in our tables after various events (idling, reset, activity etc).
When constructing the table of register definitions, also include the
flags for which registers are valid so that information is computed
centrally and available to all callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Brian Welty <brian.welty@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218162150.1300405-10-chris@chris-wilson.co.uk
Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.
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/20200214135058.7580-2-jani.nikula@intel.com
Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall. Move
irq_unintall() closer to the layer it belongs.
The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.
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/20200214135058.7580-1-jani.nikula@intel.com
spinlock_t is one case where the typedef is to be preferred over struct
spinlock.
Fixes: 42fb60de31 ("drm/i915/gem: Don't leak non-persistent requests on changing engines")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200217184219.15325-1-jani.nikula@intel.com
Always flush the tasklet if we have pending submissions in
wait_for_submit(), so that even if we see the HW has started before we
process its ack, when we return the execlists state is well defined.
Fixes: 06289949b8 ("drm/i915/selftests: Check for any sign of request starting in wait_for_submit()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218211215.1336341-1-chris@chris-wilson.co.uk
We only want to wait until the request has been submitted at least once;
that is it is either in flight, or has been.
References: fcf7df7aae ("drm/i915/selftests: Check for the error interrupt before we wait!")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218141305.1258394-1-chris@chris-wilson.co.uk
It's not clear whether this workaround is final yet, but the BSpec
indicates that userspace needs to set bit 9 of this register on demand:
"To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer
Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA"
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2501
Signed-off-by: Rafael Antognolli <rafael.antognolli@intel.com>
[mattrope: Tweaked comment while applying]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212191728.25227-1-rafael.antognolli@intel.com
Without selftests enabled, I915_SELFTEST_ONLY becomes a dummy,
generating a bare '0'. This causes the compiler to complain about a
useless line, and while we could use I915_SELFTEST_DECLARE instead, it
is a bit messier. Move the selftest-only code to a helper and make that
conditional on having selftests enabled.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200217095835.599827-1-chris@chris-wilson.co.uk
I know this is late; I've been travelling and, well, I've been
distracted.
This is just a few bug fixes and adding i2c support to the IPMB driver,
which is something I wanted from the beginning for it. It would be
nice for the people doing IPMB to get this in.
-corey
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE/Q1c5nzg9ZpmiCaGYfOMkJGb/4EFAl5B8nsACgkQYfOMkJGb
/4F0Vg//SsvGNoEVMbjXFEAq671fYslNLa1p7lEzvhoSFAFs0bOiu0LnEwkCGEof
k3alCw8RgWAchf16iQk3OEthdbMMJzA/6X7ec87uOXNUOpmZT/S5LaonOlPdA1GZ
p3qOrBdsy1VCptxVBRvv4dJFLSbiocd0ElunIKDzfwAPUXLkmHKklS9o2DmKD27F
CgXi/9cdRz6MleUubosKeG4WXEgsSmMmytjgRMqVpCA8QcG+4EKefLfqC7Iez5C4
Ol3rHOOUn/InXlHLyb1NR66s69J5CqdNt8yEZAAmc7PypnGt0Qc6RTPV2UI+CZ6/
ahJqpZmJ1vYeVJKyT9A6Bdy89uASk4y5+p72hXR4jaoRS4dHXTimmiJZHGGbEAXw
3u2qRRBvrbyi91+lpDXKV+Bp4le43J+dRVlaBW/xhipOqycwD1all4h6185jD7er
VEsrOcU2gd5AeMQ0OudRR6LvNcyS6XhF/DYC/lc1932ojLjTP4MNPbv8mFbIYN7d
JgbzvFTNCEs5x1+QHdXJ5thqv18n6OMAxIKSfJkm4ywojR0Rv1Oj7/Ov+yHJZ2s6
DBGMJhQJrQJWCXgWXQY/s+x5MSbDrlAUPWhUzKrv5BXJaqbq+fr+zYOJWW3v9q+a
FGXHQXBI8EwBLsVXASfwT5tf5GHj7QyKdV3qEWu+moZtdGBT6HE=
=y+e9
-----END PGP SIGNATURE-----
Merge tag 'for-linus-5.6-1' of https://github.com/cminyard/linux-ipmi
Pull IPMI update from Corey Minyard:
"Minor bug fixes for IPMI
I know this is late; I've been travelling and, well, I've been
distracted.
This is just a few bug fixes and adding i2c support to the IPMB
driver, which is something I wanted from the beginning for it"
* tag 'for-linus-5.6-1' of https://github.com/cminyard/linux-ipmi:
drivers: ipmi: fix off-by-one bounds check that leads to a out-of-bounds write
ipmi:ssif: Handle a possible NULL pointer reference
drivers: ipmi: Modify max length of IPMB packet
drivers: ipmi: Support raw i2c packet in IPMB
KVM documentation to rst format, which was very welcome.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJeRYe2AAoJEL/70l94x66DSdsH/31rMoISGbPReQNKDZtondwr
UNLYHBLau46OR5JiLaKDqRODi12CXwrB6KZyRtQg+PeU/aCaFqW09kDOtMdV4AMl
2bEl4VfUuClsGXBQL5WWsb+adaWxHBtRFPcaT0xMAE+JXxAvt2o7rstOydM4yB9f
vM9TqEP+oVGyqx0FsuCND+zu/qZqNOOqJ1eZCrzqZKwFS8lrjsYtBG4K8rfnvXnI
uGxFnbmZuJKpXpRgCebDdB98m0KEWfAs0S8aOO4NRfmymUBcjMeIeqQz0Mnt17xJ
Fz0KktwdGL28qJ+fnE51i/IBqCoBJL2BmIesSiGKVr1alpHA1ngKvUmcbtHkAXw=
=To92
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"Bugfixes and improvements to selftests.
On top of this, Mauro converted the KVM documentation to rst format,
which was very welcome"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (44 commits)
docs: virt: guest-halt-polling.txt convert to ReST
docs: kvm: review-checklist.txt: rename to ReST
docs: kvm: Convert timekeeping.txt to ReST format
docs: kvm: Convert s390-diag.txt to ReST format
docs: kvm: Convert ppc-pv.txt to ReST format
docs: kvm: Convert nested-vmx.txt to ReST format
docs: kvm: Convert mmu.txt to ReST format
docs: kvm: Convert locking.txt to ReST format
docs: kvm: Convert hypercalls.txt to ReST format
docs: kvm: arm/psci.txt: convert to ReST
docs: kvm: convert arm/hyp-abi.txt to ReST
docs: kvm: Convert api.txt to ReST format
docs: kvm: convert devices/xive.txt to ReST
docs: kvm: convert devices/xics.txt to ReST
docs: kvm: convert devices/vm.txt to ReST
docs: kvm: convert devices/vfio.txt to ReST
docs: kvm: convert devices/vcpu.txt to ReST
docs: kvm: convert devices/s390_flic.txt to ReST
docs: kvm: convert devices/mpic.txt to ReST
docs: kvm: convert devices/arm-vgit.txt to ReST
...
Robert Richter.
Debug options like DEBUG_TEST_DRIVER_REMOVE, KASAN and DEBUG_KMEMLEAK
unearthed issues with the lifespan of memory allocated by the EDAC
memory controller descriptor due to misdesigned memory freeing, done
partially by the EDAC core *and* the driver core, which is problematic
to say the least.
These two are minimal fixes to take care of stable - a proper rework is
following which cleans up that mess properly.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAl5I+WEACgkQEsHwGGHe
VUpcwA//aF6HO2nN+fMsfauVjTEdaElGKqTSzrByVjXjah5mDKH6RZlDandyhIe2
/Q2GYk/10ASin+FkDsc2mZ5nBcOS6rTS1avOvhlvc9xUYkzuXfvx2fZas9+81B4h
7xRrdXzU9S4ubHAkAt9oTXn2qoeq1THfJtudMh9imgmtA+qKSSTihCP4gVwuh65H
w91qxEIkxB5hBTxBtOI/vueTvBvvNfqyJ/nDh8uNRFAbPe//HwTwnrFhJmNBhyWD
S6vdYrV1UnBGZpPvS46jROmsrJgsKhGH4i7zkhS2a83CvXcyIvcPFbUHXUFCkHB6
NXeFZUIl70x5MeIElucd8g4z5vY14gY3s1mGJ/M1ErdiqQ96aGmlmh9DpArKvVqL
HhwAHmnhbgjR5cvdYiyyC+30ZDd6Xm/aZWYj4Ks8cMOSLGvFYSUaAfnYBaTBMhWF
S4JJBT0NBUTZhGMqr0Zyv0uOsqf+IB+63sNYI9sMR4m72noULTF2tN2tZZgkXmv8
QxdxwHzJ9V12ZEMhleyUx9eDPPrs5jWRoP2Io1Ws3DA1P82HqVfhsDbz1DObX2Mo
VLkXG462ANmC2hIdSr7P0uByWtRK8Nd+OMJeltK5SX2MMShQo6xO3QOkJNc7bd7X
9YZ0R9eqUlSjJcyTZZt4DUVRIzOaVOEjRZKy6wN+zNmSmo8Nock=
=UTcs
-----END PGP SIGNATURE-----
Merge tag 'edac_urgent_for_5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC fixes from Borislav Petkov:
"Two fixes for use-after-free and memory leaking in the EDAC core, by
Robert Richter.
Debug options like DEBUG_TEST_DRIVER_REMOVE, KASAN and DEBUG_KMEMLEAK
unearthed issues with the lifespan of memory allocated by the EDAC
memory controller descriptor due to misdesigned memory freeing, done
partially by the EDAC core *and* the driver core, which is problematic
to say the least.
These two are minimal fixes to take care of stable - a proper rework
is following which cleans up that mess properly"
* tag 'edac_urgent_for_5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
EDAC/sysfs: Remove csrow objects on errors
EDAC/mc: Fix use-after-free and memleaks during device removal
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAl5JdgMQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpg6eEAC7/f/ATcrAbQUjx8vsNS0UgtYB1LPdgga6
7MwYKnrzdWWZICOxOgRR4W//wXFRf3vUtmzF5MgGpzJzgeKuyv09Vz1PLcxkAcny
hu9NTQWu6xtxEGiYlfaSW7EQBRdb1876kzOyV+hTrkvQZ9CXcIAQHwjQPKqjqdlb
/j3l5GSjyO0npvsCqIWrsNoeSwfDOhFi+I3hHZutt3T0fPnjo6DGtXN7m4jhWzW/
U3S4yHxmLVDKzorDDMoTV2D8UGrpjQmRXD78QOpOJKO7ngr9OT69dcMH6TnDkUDb
a7O5l5k5DB+0QOQWk5IHJpMRRp3NdVHgnZhTJZaho8kuKoTLwteJFAprJTzHuuvC
BkTBYf1Ref9KT5YfaUcWI+rmq32LgRq8rRaJBF+vqGcOwJw6WRIuygGyZ8eJMItb
oOhsFEOKKDAILncxg5C61v2Sh4g+/YpQojyVCzJSb7UNjOMtDPgjEp2dDSa+/p84
detTqmlt5ZPYHFvsp/EHuGB6ohscsvKzZk+wlQvj4Wq3T7agSp9uljfiTmUdsmWn
69fs66HBvd3CNoOauSVXvI+rhdsgTMX0ptnjIiPYwE0RQtxptp+rPjOfuT4JdboM
AU8f0VKeer1kRPxVbka9YwgVrUw5JqgFkPu2aC9B+ao+4IAM96n6lJje/rC59zkf
eBclcnOlsQ==
=jy10
-----END PGP SIGNATURE-----
Merge tag 'block-5.6-2020-02-16' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Not a lot here, which is great, basically just three small bcache
fixes from Coly, and four NVMe fixes via Keith"
* tag 'block-5.6-2020-02-16' of git://git.kernel.dk/linux-block:
nvme: fix the parameter order for nvme_get_log in nvme_get_fw_slot_info
nvme/pci: move cqe check after device shutdown
nvme: prevent warning triggered by nvme_stop_keep_alive
nvme/tcp: fix bug on double requeue when send fails
bcache: remove macro nr_to_fifo_front()
bcache: Revert "bcache: shrink btree node cache after bch_btree_check()"
bcache: ignore pending signals when creating gc and allocator thread
Matt Roper