From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E363C2BA83 for ; Sun, 9 Feb 2020 18:10:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 649CB20733 for ; Sun, 9 Feb 2020 18:10:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581271837; bh=KBfdYkY2Hv2nOagMLSoOYDky5QFExKfE/afdxzTsCls=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=DbbH99gmHB0FavZYoKEEfpYB9GggH3+L/YkSasCNZ1c/gq8HLO6fII0GAzI2rhxOl PsSwm5lp5/30ZoQTrJOvAMfbWQxlco823eh15rLzQnnbWZn5xbiRXYiZg3x1MsRF+L heYJXmv0pQIaOoDnJwW7j3WTyYbpHJ677IXIG9Q8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727408AbgBISKg (ORCPT ); Sun, 9 Feb 2020 13:10:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:51704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727388AbgBISKg (ORCPT ); Sun, 9 Feb 2020 13:10:36 -0500 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9D1DB20715; Sun, 9 Feb 2020 18:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581271835; bh=KBfdYkY2Hv2nOagMLSoOYDky5QFExKfE/afdxzTsCls=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Wrv5FXali5ocCiuv7vjoQxScivwv/ZU/lvg5G4cVT0Q6HWSKS+yk8TVAxWRIADOIM WTSA2KTdFh+E4et86HsB2bcbgUfJcLmTa1rgVRz/3MmpWzi97jXJpQx2VZdM2wsOHW KN1nq9h/OnZxBx9LHzmNn1ca3qTinqhumnsBKkec= Date: Sun, 9 Feb 2020 13:10:34 -0500 From: Sasha Levin To: gregkh@linuxfoundation.org Cc: Wayne.Lin@amd.com, lyude@redhat.com, stable@vger.kernel.org Subject: Re: FAILED: patch "[PATCH] drm/dp_mst: Remove VCPI while disabling topology mgr" failed to apply to 5.5-stable tree Message-ID: <20200209181034.GK3584@sasha-vm> References: <158124846315195@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <158124846315195@kroah.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Sun, Feb 09, 2020 at 12:41:03PM +0100, gregkh@linuxfoundation.org wrote: > >The patch below does not apply to the 5.5-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 . > >thanks, > >greg k-h > >------------------ original commit in Linus's tree ------------------ > >>From 64e62bdf04ab8529f45ed0a85122c703035dec3a Mon Sep 17 00:00:00 2001 >From: Wayne Lin >Date: Thu, 5 Dec 2019 17:00:43 +0800 >Subject: [PATCH] drm/dp_mst: Remove VCPI while disabling topology mgr > >[Why] > >This patch is trying to address the issue observed when hotplug DP >daisy chain monitors. > >e.g. >src-mstb-mstb-sst -> src (unplug) mstb-mstb-sst -> src-mstb-mstb-sst >(plug in again) > >Once unplug a DP MST capable device, driver will call >drm_dp_mst_topology_mgr_set_mst() to disable MST. In this function, >it cleans data of topology manager while disabling mst_state. However, >it doesn't clean up the proposed_vcpis of topology manager. >If proposed_vcpi is not reset, once plug in MST daisy chain monitors >later, code will fail at checking port validation while trying to >allocate payloads. > >When MST capable device is plugged in again and try to allocate >payloads by calling drm_dp_update_payload_part1(), this >function will iterate over all proposed virtual channels to see if >any proposed VCPI's num_slots is greater than 0. If any proposed >VCPI's num_slots is greater than 0 and the port which the >specific virtual channel directed to is not in the topology, code then >fails at the port validation. Since there are stale VCPI allocations >from the previous topology enablement in proposed_vcpi[], code will fail >at port validation and reurn EINVAL. > >[How] > >Clean up the data of stale proposed_vcpi[] and reset mgr->proposed_vcpis >to NULL while disabling mst in drm_dp_mst_topology_mgr_set_mst(). > >Changes since v1: >*Add on more details in commit message to describe the issue which the >patch is trying to fix > >Signed-off-by: Wayne Lin >[added cc to stable] >Signed-off-by: Lyude Paul >Link: https://patchwork.freedesktop.org/patch/msgid/20191205090043.7580-1-Wayne.Lin@amd.com >Cc: # v3.17+ Context conflict because we don't have f79489074c59 ("drm/dp_mst: Clear all payload id tables downstream when initializing") in older kernels. Cleaned up and queued for 5.5-4.4. -- Thanks, Sasha