--- /dev/null
+From bf552083916a7f8800477b5986940d1c9a31b953 Mon Sep 17 00:00:00 2001
+From: hongao <hongao@uniontech.com>
+Date: Thu, 11 Nov 2021 11:32:07 +0800
+Subject: drm/amdgpu: fix set scaling mode Full/Full aspect/Center not works on vga and dvi connectors
+
+From: hongao <hongao@uniontech.com>
+
+commit bf552083916a7f8800477b5986940d1c9a31b953 upstream.
+
+amdgpu_connector_vga_get_modes missed function amdgpu_get_native_mode
+which assign amdgpu_encoder->native_mode with *preferred_mode result in
+amdgpu_encoder->native_mode.clock always be 0. That will cause
+amdgpu_connector_set_property returned early on:
+if ((rmx_type != DRM_MODE_SCALE_NONE) &&
+ (amdgpu_encoder->native_mode.clock == 0))
+when we try to set scaling mode Full/Full aspect/Center.
+Add the missing function to amdgpu_connector_vga_get_mode can fix this.
+It also works on dvi connectors because
+amdgpu_connector_dvi_helper_funcs.get_mode use the same method.
+
+Signed-off-by: hongao <hongao@uniontech.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+@@ -827,6 +827,7 @@ static int amdgpu_connector_vga_get_mode
+
+ amdgpu_connector_get_edid(connector);
+ ret = amdgpu_connector_ddc_get_modes(connector);
++ amdgpu_get_native_mode(connector);
+
+ return ret;
+ }
--- /dev/null
+From 6c34bd4532a3f39952952ddc102737595729afc4 Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+Date: Mon, 18 Oct 2021 17:34:17 +0300
+Subject: drm/i915/dp: Ensure sink rate values are always valid
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Imre Deak <imre.deak@intel.com>
+
+commit 6c34bd4532a3f39952952ddc102737595729afc4 upstream.
+
+Atm, there are no sink rate values set for DP (vs. eDP) sinks until the
+DPCD capabilities are successfully read from the sink. During this time
+intel_dp->num_common_rates is 0 which can lead to a
+
+intel_dp->common_rates[-1] (*)
+
+access, which is an undefined behaviour, in the following cases:
+
+- In intel_dp_sync_state(), if the encoder is enabled without a sink
+ connected to the encoder's connector (BIOS enabled a monitor, but the
+ user unplugged the monitor until the driver loaded).
+- In intel_dp_sync_state() if the encoder is enabled with a sink
+ connected, but for some reason the DPCD read has failed.
+- In intel_dp_compute_link_config() if modesetting a connector without
+ a sink connected on it.
+- In intel_dp_compute_link_config() if modesetting a connector with a
+ a sink connected on it, but before probing the connector first.
+
+To avoid the (*) access in all the above cases, make sure that the sink
+rate table - and hence the common rate table - is always valid, by
+setting a default minimum sink rate when registering the connector
+before anything could use it.
+
+I also considered setting all the DP link rates by default, so that
+modesetting with higher resolution modes also succeeds in the last two
+cases above. However in case a sink is not connected that would stop
+working after the first modeset, due to the LT fallback logic. So this
+would need more work, beyond the scope of this fix.
+
+As I mentioned in the previous patch, I don't think the issue this patch
+fixes is user visible, however it is an undefined behaviour by
+definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable.
+
+v2: Clear the default sink rates, before initializing these for eDP.
+
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
+References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298
+Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Acked-by: Jani Nikula <jani.nikula@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com
+(cherry picked from commit 3f61ef9777c0ab0f03f4af0ed6fd3e5250537a8d)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dp.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp.c
++++ b/drivers/gpu/drm/i915/display/intel_dp.c
+@@ -154,6 +154,12 @@ static void vlv_steal_power_sequencer(st
+ enum pipe pipe);
+ static void intel_dp_unset_edid(struct intel_dp *intel_dp);
+
++static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp)
++{
++ intel_dp->sink_rates[0] = 162000;
++ intel_dp->num_sink_rates = 1;
++}
++
+ /* update sink rates from dpcd */
+ static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
+ {
+@@ -4678,6 +4684,9 @@ intel_edp_init_dpcd(struct intel_dp *int
+ */
+ intel_psr_init_dpcd(intel_dp);
+
++ /* Clear the default sink rates */
++ intel_dp->num_sink_rates = 0;
++
+ /* Read the eDP 1.4+ supported link rates. */
+ if (intel_dp->edp_dpcd[0] >= DP_EDP_14) {
+ __le16 sink_rates[DP_MAX_SUPPORTED_RATES];
+@@ -7779,6 +7788,8 @@ intel_dp_init_connector(struct intel_dig
+ return false;
+
+ intel_dp_set_source_rates(intel_dp);
++ intel_dp_set_default_sink_rates(intel_dp);
++ intel_dp_set_common_rates(intel_dp);
+
+ intel_dp->reset_link_params = true;
+ intel_dp->pps_pipe = INVALID_PIPE;
--- /dev/null
+From abae9164a421bc4a41a3769f01ebcd1f9d955e0e Mon Sep 17 00:00:00 2001
+From: Jeremy Cline <jcline@redhat.com>
+Date: Wed, 25 Nov 2020 15:26:47 -0500
+Subject: drm/nouveau: Add a dedicated mutex for the clients list
+
+From: Jeremy Cline <jcline@redhat.com>
+
+commit abae9164a421bc4a41a3769f01ebcd1f9d955e0e upstream.
+
+Rather than protecting the nouveau_drm clients list with the lock within
+the "client" nouveau_cli, add a dedicated lock to serialize access to
+the list. This is both clearer and necessary to avoid lockdep being
+upset with us when we need to iterate through all the clients in the
+list and potentially lock their mutex, which is the same class as the
+lock protecting the entire list.
+
+Cc: stable@vger.kernel.org # 5.4+
+Signed-off-by: Jeremy Cline <jcline@redhat.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
+Tested-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-3-jcline@redhat.com
+Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_drm.c | 10 ++++++----
+ drivers/gpu/drm/nouveau/nouveau_drv.h | 5 +++++
+ 2 files changed, 11 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
++++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
+@@ -557,6 +557,7 @@ nouveau_drm_device_init(struct drm_devic
+ nvkm_dbgopt(nouveau_debug, "DRM");
+
+ INIT_LIST_HEAD(&drm->clients);
++ mutex_init(&drm->clients_lock);
+ spin_lock_init(&drm->tile.lock);
+
+ /* workaround an odd issue on nvc1 by disabling the device's
+@@ -654,6 +655,7 @@ nouveau_drm_device_fini(struct drm_devic
+ nouveau_cli_fini(&drm->client);
+ nouveau_cli_fini(&drm->master);
+ nvif_parent_dtor(&drm->parent);
++ mutex_destroy(&drm->clients_lock);
+ kfree(drm);
+ }
+
+@@ -1086,9 +1088,9 @@ nouveau_drm_open(struct drm_device *dev,
+
+ fpriv->driver_priv = cli;
+
+- mutex_lock(&drm->client.mutex);
++ mutex_lock(&drm->clients_lock);
+ list_add(&cli->head, &drm->clients);
+- mutex_unlock(&drm->client.mutex);
++ mutex_unlock(&drm->clients_lock);
+
+ done:
+ if (ret && cli) {
+@@ -1114,9 +1116,9 @@ nouveau_drm_postclose(struct drm_device
+ nouveau_abi16_fini(cli->abi16);
+ mutex_unlock(&cli->mutex);
+
+- mutex_lock(&drm->client.mutex);
++ mutex_lock(&drm->clients_lock);
+ list_del(&cli->head);
+- mutex_unlock(&drm->client.mutex);
++ mutex_unlock(&drm->clients_lock);
+
+ nouveau_cli_fini(cli);
+ kfree(cli);
+--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
++++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
+@@ -142,6 +142,11 @@ struct nouveau_drm {
+
+ struct list_head clients;
+
++ /**
++ * @clients_lock: Protects access to the @clients list of &struct nouveau_cli.
++ */
++ struct mutex clients_lock;
++
+ u8 old_pm_cap;
+
+ struct {
--- /dev/null
+From f55aaf63bde0d0336c3823bb3713bd4a464abbcf Mon Sep 17 00:00:00 2001
+From: Jeremy Cline <jcline@redhat.com>
+Date: Wed, 25 Nov 2020 15:26:48 -0500
+Subject: drm/nouveau: clean up all clients on device removal
+
+From: Jeremy Cline <jcline@redhat.com>
+
+commit f55aaf63bde0d0336c3823bb3713bd4a464abbcf upstream.
+
+The postclose handler can run after the device has been removed (or the
+driver has been unbound) since userspace clients are free to hold the
+file open as long as they want. Because the device removal callback
+frees the entire nouveau_drm structure, any reference to it in the
+postclose handler will result in a use-after-free.
+
+To reproduce this, one must simply open the device file, unbind the
+driver (or physically remove the device), and then close the device
+file. This was found and can be reproduced easily with the IGT
+core_hotunplug tests.
+
+To avoid this, all clients are cleaned up in the device finalization
+rather than deferring it to the postclose handler, and the postclose
+handler is protected by a critical section which ensures the
+drm_dev_unplug() and the postclose handler won't race.
+
+This is not an ideal fix, since as I understand the proposed plan for
+the kernel<->userspace interface for hotplug support, destroying the
+client before the file is closed will cause problems. However, I believe
+to properly fix this issue, the lifetime of the nouveau_drm structure
+needs to be extended to match the drm_device, and this proved to be a
+rather invasive change. Thus, I've broken this out so the fix can be
+easily backported.
+
+This fixes with the two previous commits CVE-2020-27820 (Karol).
+
+Cc: stable@vger.kernel.org # 5.4+
+Signed-off-by: Jeremy Cline <jcline@redhat.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
+Tested-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-4-jcline@redhat.com
+Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_drm.c | 30 ++++++++++++++++++++++++++++++
+ 1 file changed, 30 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
++++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
+@@ -628,6 +628,7 @@ fail_alloc:
+ static void
+ nouveau_drm_device_fini(struct drm_device *dev)
+ {
++ struct nouveau_cli *cli, *temp_cli;
+ struct nouveau_drm *drm = nouveau_drm(dev);
+
+ if (nouveau_pmops_runtime()) {
+@@ -652,6 +653,24 @@ nouveau_drm_device_fini(struct drm_devic
+ nouveau_ttm_fini(drm);
+ nouveau_vga_fini(drm);
+
++ /*
++ * There may be existing clients from as-yet unclosed files. For now,
++ * clean them up here rather than deferring until the file is closed,
++ * but this likely not correct if we want to support hot-unplugging
++ * properly.
++ */
++ mutex_lock(&drm->clients_lock);
++ list_for_each_entry_safe(cli, temp_cli, &drm->clients, head) {
++ list_del(&cli->head);
++ mutex_lock(&cli->mutex);
++ if (cli->abi16)
++ nouveau_abi16_fini(cli->abi16);
++ mutex_unlock(&cli->mutex);
++ nouveau_cli_fini(cli);
++ kfree(cli);
++ }
++ mutex_unlock(&drm->clients_lock);
++
+ nouveau_cli_fini(&drm->client);
+ nouveau_cli_fini(&drm->master);
+ nvif_parent_dtor(&drm->parent);
+@@ -1108,6 +1127,16 @@ nouveau_drm_postclose(struct drm_device
+ {
+ struct nouveau_cli *cli = nouveau_cli(fpriv);
+ struct nouveau_drm *drm = nouveau_drm(dev);
++ int dev_index;
++
++ /*
++ * The device is gone, and as it currently stands all clients are
++ * cleaned up in the removal codepath. In the future this may change
++ * so that we can support hot-unplugging, but for now we immediately
++ * return to avoid a double-free situation.
++ */
++ if (!drm_dev_enter(dev, &dev_index))
++ return;
+
+ pm_runtime_get_sync(dev->dev);
+
+@@ -1124,6 +1153,7 @@ nouveau_drm_postclose(struct drm_device
+ kfree(cli);
+ pm_runtime_mark_last_busy(dev->dev);
+ pm_runtime_put_autosuspend(dev->dev);
++ drm_dev_exit(dev_index);
+ }
+
+ static const struct drm_ioctl_desc
--- /dev/null
+From aff2299e0d81b26304ccc6a1ec0170e437f38efc Mon Sep 17 00:00:00 2001
+From: Jeremy Cline <jcline@redhat.com>
+Date: Wed, 25 Nov 2020 15:26:46 -0500
+Subject: drm/nouveau: use drm_dev_unplug() during device removal
+
+From: Jeremy Cline <jcline@redhat.com>
+
+commit aff2299e0d81b26304ccc6a1ec0170e437f38efc upstream.
+
+Nouveau does not currently support hot-unplugging, but it still makes
+sense to switch from drm_dev_unregister() to drm_dev_unplug().
+drm_dev_unplug() calls drm_dev_unregister() after marking the device as
+unplugged, but only after any device critical sections are finished.
+
+Since nouveau isn't using drm_dev_enter() and drm_dev_exit(), there are
+no critical sections so this is nearly functionally equivalent. However,
+the DRM layer does check to see if the device is unplugged, and if it is
+returns appropriate error codes.
+
+In the future nouveau can add critical sections in order to truly
+support hot-unplugging.
+
+Cc: stable@vger.kernel.org # 5.4+
+Signed-off-by: Jeremy Cline <jcline@redhat.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
+Tested-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-2-jcline@redhat.com
+Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
++++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
+@@ -794,7 +794,7 @@ nouveau_drm_device_remove(struct drm_dev
+ struct nvkm_client *client;
+ struct nvkm_device *device;
+
+- drm_dev_unregister(dev);
++ drm_dev_unplug(dev);
+
+ dev->irq_enabled = false;
+ client = nvxx_client(&drm->client.base);
--- /dev/null
+From 5591c8f79db1729d9c5ac7f5b4d3a5c26e262d93 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 25 Oct 2021 13:53:53 +0200
+Subject: drm/udl: fix control-message timeout
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 5591c8f79db1729d9c5ac7f5b4d3a5c26e262d93 upstream.
+
+USB control-message timeouts are specified in milliseconds and should
+specifically not vary with CONFIG_HZ.
+
+Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)")
+Cc: stable@vger.kernel.org # 3.4
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Link: https://patchwork.freedesktop.org/patch/msgid/20211025115353.5089-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/udl/udl_connector.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/udl/udl_connector.c
++++ b/drivers/gpu/drm/udl/udl_connector.c
+@@ -30,7 +30,7 @@ static int udl_get_edid_block(void *data
+ ret = usb_control_msg(udl->udev,
+ usb_rcvctrlpipe(udl->udev, 0),
+ (0x02), (0x80 | (0x02 << 5)), bval,
+- 0xA1, read_buff, 2, HZ);
++ 0xA1, read_buff, 2, 1000);
+ if (ret < 1) {
+ DRM_ERROR("Read EDID byte %d failed err %x\n", i, ret);
+ kfree(read_buff);
parisc-sticon-fix-reverse-colors.patch
cfg80211-call-cfg80211_stop_ap-when-switch-from-p2p_go-type.patch
drm-amd-display-update-swizzle-mode-enums.patch
+drm-udl-fix-control-message-timeout.patch
+drm-nouveau-add-a-dedicated-mutex-for-the-clients-list.patch
+drm-nouveau-use-drm_dev_unplug-during-device-removal.patch
+drm-nouveau-clean-up-all-clients-on-device-removal.patch
+drm-i915-dp-ensure-sink-rate-values-are-always-valid.patch
+drm-amdgpu-fix-set-scaling-mode-full-full-aspect-center-not-works-on-vga-and-dvi-connectors.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
