From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E07C726B0BD; Thu, 13 Feb 2025 15:24:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739460270; cv=none; b=bftg9lDiVtMR2nsUIIOhQuR9KXZH48YUk7MJnu839FlEFlx6z3DwSSm9QehVot/p+hkelt9VaFSr8NNSlU1PjX3zpkCO1m3QMlpp7eGJCFh3wyfSeLu8A2lKZTCtUA3Jkn1CWRD0HODyIKBC9C/qqVfJl/cWS6tfA/jrHp+b/ro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739460270; c=relaxed/simple; bh=FzvThIZlLZyXYVAzU6lfcBrhK3PqTKCjkzDlrRR8cEQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nkjDLmDwmrcysqpWh5xkT3bepD1Fm3Lw95fB4b8ePZOmT3KsxvXmlVe04ntQn6KQ/g7QAh0PK5IpkXG/ho0Gdk4k0w+PfUX+Y5ahqtYg7EpHZC7CAhxcdQdaO7hpffn0M3MdTPw54LgLAzfkaBVyub2rJY/zZhaqvJW+Td/iahg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=tcU4CB0p; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="tcU4CB0p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DBF8C4CED1; Thu, 13 Feb 2025 15:24:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1739460269; bh=FzvThIZlLZyXYVAzU6lfcBrhK3PqTKCjkzDlrRR8cEQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tcU4CB0pM3h6xfxyZOTuVjZjzlcUGgwV8HpNRIUy1m7i9a3QsKYq8s2wd0YWyUir0 kXYWeimHpcaR5Vm/EPm2KfshAjPDiwnCyOsgTLkkPk6VmwLI0scPAx0T+hmFQj182y S1YgGe4TCMk5tk2r4kD6w24ZHoulQ9PUE8vRHowU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Hans Verkuil , Farblos , Dmitry Baryshkov , Sasha Levin Subject: [PATCH 6.6 062/273] gpu: drm_dp_cec: fix broken CEC adapter properties check Date: Thu, 13 Feb 2025 15:27:14 +0100 Message-ID: <20250213142409.805355516@linuxfoundation.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250213142407.354217048@linuxfoundation.org> References: <20250213142407.354217048@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hans Verkuil [ Upstream commit 6daaae5ff7f3b23a2dacc9c387ff3d4f95b67cad ] If the hotplug detect of a display is low for longer than one second (configurable through drm_dp_cec_unregister_delay), then the CEC adapter is unregistered since we assume the display was disconnected. If the HPD went low for less than one second, then we check if the properties of the CEC adapter have changed, since that indicates that we actually switch to new hardware and we have to unregister the old CEC device and register a new one. Unfortunately, the test for changed properties was written poorly, and after a new CEC capability was added to the CEC core code the test always returned true (i.e. the properties had changed). As a result the CEC device was unregistered and re-registered for every HPD toggle. If the CEC remote controller integration was also enabled (CONFIG_MEDIA_CEC_RC was set), then the corresponding input device was also unregistered and re-registered. As a result the input device in /sys would keep incrementing its number, e.g.: /sys/devices/pci0000:00/0000:00:08.1/0000:e7:00.0/rc/rc0/input20 Since short HPD toggles are common, the number could over time get into the thousands. While not a serious issue (i.e. nothing crashes), it is not intended to work that way. This patch changes the test so that it only checks for the single CEC capability that can actually change, and it ignores any other capabilities, so this is now safe as well if new caps are added in the future. With the changed test the bit under #ifndef CONFIG_MEDIA_CEC_RC can be dropped as well, so that's a nice cleanup. Signed-off-by: Hans Verkuil Reported-by: Farblos Reviewed-by: Dmitry Baryshkov Fixes: 2c6d1fffa1d9 ("drm: add support for DisplayPort CEC-Tunneling-over-AUX") Tested-by: Farblos Link: https://patchwork.freedesktop.org/patch/msgid/361bb03d-1691-4e23-84da-0861ead5dbdc@xs4all.nl Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin --- drivers/gpu/drm/display/drm_dp_cec.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_cec.c b/drivers/gpu/drm/display/drm_dp_cec.c index ae39dc7941903..868bf53db66ce 100644 --- a/drivers/gpu/drm/display/drm_dp_cec.c +++ b/drivers/gpu/drm/display/drm_dp_cec.c @@ -310,16 +310,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid) if (!aux->transfer) return; -#ifndef CONFIG_MEDIA_CEC_RC - /* - * CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by - * cec_allocate_adapter() if CONFIG_MEDIA_CEC_RC is undefined. - * - * Do this here as well to ensure the tests against cec_caps are - * correct. - */ - cec_caps &= ~CEC_CAP_RC; -#endif cancel_delayed_work_sync(&aux->cec.unregister_work); mutex_lock(&aux->cec.lock); @@ -336,7 +326,9 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid) num_las = CEC_MAX_LOG_ADDRS; if (aux->cec.adap) { - if (aux->cec.adap->capabilities == cec_caps && + /* Check if the adapter properties have changed */ + if ((aux->cec.adap->capabilities & CEC_CAP_MONITOR_ALL) == + (cec_caps & CEC_CAP_MONITOR_ALL) && aux->cec.adap->available_log_addrs == num_las) { /* Unchanged, so just set the phys addr */ cec_s_phys_addr_from_edid(aux->cec.adap, edid); -- 2.39.5