6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gil Fine gil.fine@linux.intel.com
[ Upstream commit ccd845021147dc8257a05ed8f5a7f9c61a9101e3 ]
According to USB4 Connection Manager guide, after DisplayPort tunnel was setup, the DPRX capabilities read is performed by the DPTX. According to VESA spec, this shall be completed within 5 seconds after the DisplayPort tunnel was setup. Hence, if the bit: DPRX Capabilities Read Done, was not set to '1' by this time, we timeout and fail calculating DisplayPort tunnel consumed bandwidth.
Signed-off-by: Gil Fine gil.fine@linux.intel.com Signed-off-by: Mika Westerberg mika.westerberg@linux.intel.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/thunderbolt/tunnel.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c index 6fffb2c82d3d1..4f09216b70f90 100644 --- a/drivers/thunderbolt/tunnel.c +++ b/drivers/thunderbolt/tunnel.c @@ -1196,17 +1196,13 @@ static int tb_dp_consumed_bandwidth(struct tb_tunnel *tunnel, int *consumed_up, /* * Then see if the DPRX negotiation is ready and if yes * return that bandwidth (it may be smaller than the - * reduced one). Otherwise return the remote (possibly - * reduced) caps. + * reduced one). According to VESA spec, the DPRX + * negotiation shall compete in 5 seconds after tunnel + * established. We give it 100ms extra just in case. */ - ret = tb_dp_wait_dprx(tunnel, 150); - if (ret) { - if (ret == -ETIMEDOUT) - ret = tb_dp_read_cap(tunnel, DP_REMOTE_CAP, - &rate, &lanes); - if (ret) - return ret; - } + ret = tb_dp_wait_dprx(tunnel, 5100); + if (ret) + return ret; ret = tb_dp_read_cap(tunnel, DP_COMMON_CAP, &rate, &lanes); if (ret) return ret;