From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (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 AA094315776 for ; Mon, 24 Nov 2025 16:44:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764002668; cv=none; b=Eru+aom2DXD7pnfYQesw03DeK3VrnAoPQzJILohezWmcMhtjkuKfUaTy6ynbH5nAiUoVduexAcIPwyz8RMftS/rE+KBo9UBOiFxObdfh9HP2kWwrl6vepsNaLoQJ52gYvSbQERN2ReH+egIwLFnRxJJ1EINR7lOjt5P0aMhBKFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764002668; c=relaxed/simple; bh=uSemw84f5ckyGShXecvyFgO27QOKWBIVsqm1RZd2KFA=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=bf/zOmqLp7llbKS+qBinHU5M2zgw12p/KwEXspMCRSQkTa7+o3XD2VvxJPxF4TMH8gSCPFcWzP0xchZg+kzk2koOzXwvS9wJR3QyVO42TxSpy1cBik6sT7ONcM9tqJC3/4sykhGkZrltVzm8Mbq2hn0+FkQOItb8CxNohhTI5XI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=KrEWDBIw; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="KrEWDBIw" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 472BEC139B2; Mon, 24 Nov 2025 16:44:02 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id B7547606FC; Mon, 24 Nov 2025 16:44:24 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 1410710371A8F; Mon, 24 Nov 2025 17:44:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1764002662; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=8VxkXwHyVWJtMQb4rGcL9+DawEiYCDxx29eMOS81RRA=; b=KrEWDBIww4g7nDza6Zc7hbr+ZoXaAgKnm9t/c7uQL8DjmTM4Lqn6U4mOBDG5vMoUDsvrd2 z/Sp/kXw6JnOSTYIFsmfxY3UrknEd6H/JIDub3AwK87pZ+UJrv5fYOmUNSbSYDq4WsP5v0 oneufTmETBFZmFUh0DxP15w3p8E74Qylz6WR0Fur6qK4EEAxebJte+/MSikZrha0b/9Gls WRJzAXFmzZG7qJu0L63Dv+MuAQdNPhwTUxava0scvHSMJ7nqGhN0bidohpBwZuGxE/Vr0T 7wEt+C6kFsdbn3+p0AzKRiI549ZbqiSwVxZK8aOtKlYFNJxrJuYIWVmjCUBcsA== Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 24 Nov 2025 17:44:09 +0100 Message-Id: Subject: Re: [PATCH 04/26] drm/bridge: make of_drm_find_bridge() a wrapper of drm_of_find_bridge() Cc: "Andrzej Hajda" , "Neil Armstrong" , "Robert Foss" , "Laurent Pinchart" , "Jonas Karlman" , "Jernej Skrabec" , "Maarten Lankhorst" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Jonathan Corbet" , "Alexey Brodkin" , "Phong LE" , "Liu Ying" , "Shawn Guo" , "Sascha Hauer" , "Pengutronix Kernel Team" , "Fabio Estevam" , "Adrien Grassein" , "Laurent Pinchart" , "Tomi Valkeinen" , "Kieran Bingham" , "Geert Uytterhoeven" , "Magnus Damm" , "Kevin Hilman" , "Jerome Brunet" , "Martin Blumenstingl" , "Chun-Kuang Hu" , "Philipp Zabel" , "Matthias Brugger" , "AngeloGioacchino Del Regno" , "Anitha Chrisanthus" , "Edmund Dea" , "Inki Dae" , "Seung-Woo Kim" , "Kyungmin Park" , "Krzysztof Kozlowski" , "Alim Akhtar" , "Hui Pu" , "Thomas Petazzoni" , , , , , , , , , , "Anusha Srivatsa" To: "Maxime Ripard" From: "Luca Ceresoli" X-Mailer: aerc 0.20.1 References: <20251119-drm-bridge-alloc-getput-drm_of_find_bridge-v1-0-0db98a7fe474@bootlin.com> <20251119-drm-bridge-alloc-getput-drm_of_find_bridge-v1-4-0db98a7fe474@bootlin.com> In-Reply-To: X-Last-TLS-Session-Version: TLSv1.3 Hi, +Cc Anusha On Mon Nov 24, 2025 at 11:22 AM CET, Maxime Ripard wrote: > Hi, > > On Wed, Nov 19, 2025 at 02:05:35PM +0100, Luca Ceresoli wrote: >> of_drm_find_bridge() is identical to drm_of_find_bridge() except it does >> not increment the refcount. Rewrite it as a wrapper and put the bridge >> being returned so the behaviour is still the same. >> >> Signed-off-by: Luca Ceresoli > > Kind of the same comment than on the TODO. Is it worth doing that patch > when we could just remove it at the end of the series? This series is not converting all users I'm afraid. There are still some drivers to convert, but not a big deal. The main user to be converted is drm_of_find_panel_or_bridge(), which is very tricky, and in turn it is used by devm_drm_of_get_bridge(). We discussed this in the past and the conclusion was a rework of the drm_panel lifetime was needed to be able to properly replace drm_of_find_panel_or_bridge(). A drm_panel rework had started very well with devm_drm_panel_alloc() that got upstreamed by Anusha, but I'm not sure if it has made further progress after that. So AFAICT the plan is still "People will gradually switch to the new API over time", and the deprecated of_drm_find_bridge() will be removed after that. Does it still make sense to you? Maxime, Anusha, are you aware of any steps forward about dynamic panel lifetime, after devm_drm_panel_alloc()? >> @@ -1460,19 +1460,11 @@ EXPORT_SYMBOL(drm_of_find_bridge); >> */ >> struct drm_bridge *of_drm_find_bridge(struct device_node *np) >> { >> - struct drm_bridge *bridge; >> - >> - mutex_lock(&bridge_lock); >> + struct drm_bridge *bridge =3D drm_of_find_bridge(np); >> >> - list_for_each_entry(bridge, &bridge_list, list) { >> - if (bridge->of_node =3D=3D np) { >> - mutex_unlock(&bridge_lock); >> - return bridge; >> - } >> - } >> + drm_bridge_put(bridge); > > And if it does make sense to keep that patch, we should add a comment > here to document why we are doing this. OK, what about: /** * We need to emulate the original semantice of of_drm_find_bridge(), which * was not getting any bridge reference. Being now based on * drm_of_find_bridge() which gets a reference, put it before returning. */ Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com