FAILED: patch "[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale" failed to apply to 5.13-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.13-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 3769e4c0af5b82c8ea21d037013cb9564dfaa51f Mon Sep 17 00:00:00 2001
From: Wayne Lin <[email protected]>
Date: Wed, 16 Jun 2021 11:55:01 +0800
Subject: [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale
topology
[Why]
After unplug/hotplug hub from the system, userspace might start to clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi() to release stale VCPI of those ports which are not relating to current topology, we have chane to wrongly clear active payload table entry for current topology.
E.g.
We have allocated VCPI 1 in current payload table and we call drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id() tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we want to allocate a new payload stream, it will find ID 1 is available by drm_dp_mst_assign_payload_id(). However, ID 1 is being used
[How]
Check target sink is relating to current topology or not before doing any payload table update.
Searching upward to find the target sink's relevant root branch device. If the found root branch device is not the same root of current topology, don't update payload table.
Changes since v1:
* Change debug macro to use drm_dbg_kms() instead
* Amend the commit message to add Cc tag.
drivers/gpu/drm/drm_dp_mst_topology.c +29 -0
@@ -94,6 +94,9 @@ static int drm_dp_mst_register_i2c_bus(struct drm_dp_mst_port *port);static void drm_dp_mst_unregister_i2c_bus (struct drm_dp_mst_port *port);static void drm_dp_mst_kick_tx (struct drm_dp_mst_topology_mgr *mgr); +static bool drm_dp_mst_port_downstream_of_branch (struct drm_dp_mst_port *port, +struct drm_dp_mst_branch *branch); +#define DBG_PREFIX "[dp_mst]"#define DP_STR (x) [DP_ ## x] = #x
@@ -3366,6 +3369,7 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)struct drm_dp_mst_port *port;int i, j;int cur_slots =1 ; +bool skip;mutex_lock (&mgr->payload_lock);for (i =0 ; i < mgr->max_payloads; i++) {
@@ -3380,6 +3384,14 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) port = container_of(vcpi, struct drm_dp_mst_port, vcpi); +mutex_lock (&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch (port, mgr->mst_primary); +mutex_unlock (&mgr->lock); + +if (skip) { +drm_dbg_kms ("Virtual channel %d is not in current topology\n" , i); +continue ; + }/* Validated ports don't matter if we're releasing * VCPI */
@@ -3479,6 +3491,7 @@ int drm_dp_update_payload_part2(struct drm_dp_mst_topology_mgr *mgr)struct drm_dp_mst_port *port;int i;int ret =0 ; +bool skip;mutex_lock (&mgr->payload_lock);for (i =0 ; i < mgr->max_payloads; i++) {
@@ -3488,6 +3501,13 @@ int drm_dp_update_payload_part2(struct drm_dp_mst_topology_mgr *mgr) port = container_of(mgr->proposed_vcpis[i], struct drm_dp_mst_port, vcpi); +mutex_lock (&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch (port, mgr->mst_primary); +mutex_unlock (&mgr->lock); + +if (skip) +continue ; +drm_dbg_kms (mgr->dev,"payload %d %d\n" , i, mgr->payloads[i].payload_state);if (mgr->payloads[i].payload_state ==DP_PAYLOAD_LOCAL ) { ret =drm_dp_create_payload_step2 (mgr, port, mgr->proposed_vcpis[i]->vcpi, &mgr->payloads[i]);
@@ -4574,9 +4594,18 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots);void drm_dp_mst_deallocate_vcpi (struct drm_dp_mst_topology_mgr *mgr,struct drm_dp_mst_port *port) { +bool skip; +if (!port->vcpi.vcpi)return ; +mutex_lock (&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch (port, mgr->mst_primary); +mutex_unlock (&mgr->lock); + +if (skip) +return ; +drm_dp_mst_put_payload_id (mgr, port->vcpi.vcpi); port->vcpi.num_slots =0 ; port->vcpi.pbn =0 ;
[AMD Official Use Only]
Hi Greg,
Really thanks for your time. About failing to apply below patches to stable tree:3769e4c0af5b82c8ea21d037013cb9564dfaa51f
[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
35d3e8cb35e75450f87f87e3d314e2d418b6954b
[PATCH] drm/dp_mst: Do not set proposed vcpi directly
There was an immediate following patch to correct the issue caused by above patches:24ff3dc18b99c4b912ab1746e803ddb3be5ced4c
[PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()
In other words, these three patches should be committed at the same time. Sorry for any inconvenience it brought. Please advise me if there is anything else to do for having these patches applied to stable tree. Really thanks for your help.
Regards,
Wayne
Quoted 133 lines
-----Original Message-----
From: [email protected] <[email protected]>
Sent: Thursday, July 15, 2021 8:17 PM
To: Lin, Wayne <[email protected]>; [email protected]
Cc: [email protected]
Subject: FAILED: patch "[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale" failed to apply to 5.13-stable treeThe patch below does not apply to the 5.13-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
3769e4c0af5b82c8ea21d037013cb9564dfaa51fMon Sep 17 00:00:00 2001
From: Wayne Lin <[email protected]>
Date: Wed, 16 Jun 2021 11:55:01 +0800
Subject: [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology[Why]
After unplug/hotplug hub from the system, userspace might start to clear stale payloads gradually. If we calldrm_dp_mst_deallocate_vcpi()to release stale VCPI of those ports which are not relating to current topology, we have chane to wrongly clear active payload table entry for current topology.E.g.
We have allocated VCPI 1 in current payload table and we calldrm_dp_mst_deallocate_vcpi()to clean VCPI 1 in stale topology. Indrm_dp_mst_deallocate_vcpi(), it will calldrm_dp_mst_put_payload_id()tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we want to allocate a new payload stream, it will find ID 1 is available bydrm_dp_mst_assign_payload_id(). However, ID 1 is being used[How]
Check target sink is relating to current topology or not before doing any payload table update. Searching upward to find the target sink's relevant root branch device.
If the found root branch device is not the same root of current topology, don't update payload table.Changes since v1:
* Change debug macro to usedrm_dbg_kms()instead
* Amend the commit message to add Cc tag.Signed-off-by Wayne Lin <[email protected]>Signed-off-by Lyude Paul <[email protected]>Link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2Fmsgid%2F20210616
035501.3776-3- Wayne.Lin%40amd.com&data=04%7C01%7CWayne.Lin%40amd.com%7C231171835e1e4d40019a08d9478c7553%7C3dd8961fe488 4e608e11a82d994e183d%7C0%7C0%7C637619490858271159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ry%2FBe6oKXqA51GAiVYSsl4RqIoGZ%2BT9%2FsVbqMD1OlXc%3D&r eserved=0Reviewed-by Lyude Paul <[email protected]>drivers/gpu/drm/drm_dp_mst_topology.c +0
-0@@ -94,6 +94,9 @@ static int drm_dp_mst_register_i2c_bus(struct drm_dp_mst_port *port); static void
drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port); static voiddrm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);drivers/gpu/drm/drm_dp_mst_topology.c +4
-0+static bool drm_dp_mst_port_downstream_of_branch (struct drm_dp_mst_port *port, +struct drm_dp_mst_branch *branch); +#define DBG_PREFIX "[dp_mst]"#define DP_STR (x) [DP_ ## x] = #x@@ -3366,6 +3369,7 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)struct drm_dp_mst_port *port;int i, j;int cur_slots =1 ; +bool skip;mutex_lock (&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { @@ -3380,6 +3384,14 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr*mgr)
port = container_of(vcpi, structdrm_dp_mst_port,
vcpi);drivers/gpu/drm/drm_dp_mst_topology.c +9
-0+mutex_lock (&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch (port, mgr->mst_primary); +mutex_unlock (&mgr->lock); + +if (skip) { +drm_dbg_kms ("Virtual channel %d is not in current topology\n" , i); +continue ; + }/* Validated ports don't matter if we're releasing * VCPI */ @@ -3479,6 +3491,7 @@ int drm_dp_update_payload_part2(struct drm_dp_mst_topology_mgr *mgr)struct drm_dp_mst_port *port;int i;int ret =0 ; +bool skip;mutex_lock (&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { @@ -3488,6 +3501,13 @@ int drm_dp_update_payload_part2(struct
drm_dp_mst_topology_mgr*mgr)port = container_of(mgr->proposed_vcpis[i], struct drm_dp_mst_port, vcpi);drivers/gpu/drm/drm_dp_mst_topology.c +7
-0+mutex_lock (&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch (port, mgr->mst_primary); +mutex_unlock (&mgr->lock); + +if (skip) +continue ; +drm_dbg_kms (mgr->dev,"payload %d %d\n" , i, mgr->payloads[i].payload_state);if (mgr->payloads[i].payload_state ==DP_PAYLOAD_LOCAL ) { ret = drm_dp_create_payload_step2(mgr, port, mgr->proposed_vcpis[i]->vcpi, &mgr->payloads[i]); @@ -4574,9 +4594,18 @@
EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots);
void drm_dp_mst_deallocate_vcpi(structdrm_dp_mst_topology_mgr*mgr,
structdrm_dp_mst_port*port)
{drivers/gpu/drm/drm_dp_mst_topology.c +9
-0+bool skip; +if (!port->vcpi.vcpi)return ; +mutex_lock (&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch (port, mgr->mst_primary); +mutex_unlock (&mgr->lock); + +if (skip) +return ; +drm_dp_mst_put_payload_id (mgr, port->vcpi.vcpi); port->vcpi.num_slots =0 ; port->vcpi.pbn =0 ;
[email protected]
maintainerQuoted 11 lines · Wayne
[AMD Official Use Only]
Hi Greg,
Really thanks for your time. About failing to apply below patches to stable tree:
3769e4c0af5b82c8ea21d037013cb9564dfaa51f
[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
35d3e8cb35e75450f87f87e3d314e2d418b6954b
[PATCH] drm/dp_mst: Do not set proposed vcpi directly
Quoted 7 lines
There was an immediate following patch to correct the issue caused by above patches:
24ff3dc18b99c4b912ab1746e803ddb3be5ced4c
[PATCH] drm/dp_mst: Add missing drm parameters to recently added call todrm_dbg_kms()In other words, these three patches should be committed at the same time. Sorry for any inconvenience it brought. Please advise me if there is anything else to do for having these patches applied to stable tree. Really thanks for your help.
These commits do not apply to the current stable trees, so please submit backports of them for how ever far back you wish to see them, so that we can apply them.
thanks,
greg k-h
[AMD Official Use Only]
Quoted 25 lines
-----Original Message-----
From: [email protected] <[email protected]>
Sent: Friday, July 16, 2021 1:28 AM
To: Lin, Wayne <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: FAILED: patch "[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale" failed to apply to 5.13-stable treeQuoted 17 lines · Wayne
[AMD Official Use Only]
Hi Greg,
Really thanks for your time. About failing to apply below patches to stable tree:
3769e4c0af5b82c8ea21d037013cb9564dfaa51f
[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
35d3e8cb35e75450f87f87e3d314e2d418b6954b
[PATCH] drm/dp_mst: Do not set proposed vcpi directlyThere was an immediate following patch to correct the issue caused by above patches:
24ff3dc18b99c4b912ab1746e803ddb3be5ced4c
[PATCH] drm/dp_mst: Add missing drm parameters to recently added call todrm_dbg_kms()
Quoted 6 lines
Quoted 3 lines
In other words, these three patches should be committed at the same time. Sorry for any inconvenience it brought. Please advise me if there is anything else to do for having these patches applied to stable tree. Really thanks for your help.
These commits do not apply to the current stable trees, so please submit backports of them for how ever far back you wish to see them, so that we can apply them.
Hi Greg,
I see. Thanks for your time! Will do.
Regards,
Wayne
Quoted 4 lines
thanks,
greg k-h