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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 55758D5E156 for ; Tue, 16 Dec 2025 13:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Feq9PPDTr7/W6ztDEedIXD9uT8zzvdkSZ6bxl7K25xI=; b=hwoIlUfcvELAIdyiAEXsthoQU5 7YpSMLVpcttFkJHvuKJokGQxu9FervZVXuutApN2IyFvokFPf9BOGnrAgH2TcCxnrow0envqQDO4j fTmSC9tSBEeTQqHAaiEjtv2IDnbU4xsOfelF0Rr5QlPAfPeLSRYwXr3cP9K8udkpX5P2R2I2nE47r MN8LUyrv4yh97aAYMK0JCsTNumB/lYPM2RvjVs/A1Ti7Z8GNyiLg5qiJJ3zI2RaBOfrhpi1dGCcIe h72Os+X+LQm1LpKXUfxNZ1wfPPpu8q6KbCh7RvR0sZIEsNkAnGP4D5lxnaAZoSzEiQbddzjneMFfh W2SimeKQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vVVQv-00000005IUr-3mBM; Tue, 16 Dec 2025 13:49:45 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vVVQu-00000005IU8-2vP7; Tue, 16 Dec 2025 13:49:44 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 8DD4A6017F; Tue, 16 Dec 2025 13:49:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A093C4CEF1; Tue, 16 Dec 2025 13:49:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765892983; bh=YfLQ27amlUSOROYLrmwTzJ9E/8AgqpTLSS/yS8wBt6o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ms/EcseV+s20wmc1lLhYwDx89gIvClg2PrymIGMeUbwNDiD4SnOmW78o0LBiCBxlO BdxeF2Dz7vNPLlHk6H9c/Loage+PF2nosiRONlDlgQCWHyIinBjfz+mmT27iulavfd BuE/G7U+oUbo+mnBfw6ESY6cd3Q41neeo7IYkgSIPk07g5OM0wIZnaF/AK+WLm6cgJ GmCyNXU3kAhE/wGxDlMtotwE9co/euW0U0pWBSlyqKeVL94wQyOekYMU9/93Cs6rqR ujWcxuOybxnttG5mv4zj6LB+Bfu8R3ei8lyxE/EthGDt30dEmVf0CTtlhobbfgREOI OXMYvMAHdg9pw== Date: Tue, 16 Dec 2025 14:49:39 +0100 From: Maxime Ripard To: Luca Ceresoli 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 , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-samsung-soc@vger.kernel.org Subject: Re: [PATCH 06/26] drm/bridge: add devm_drm_of_find_bridge Message-ID: <20251216-cute-bandicoot-of-authority-3c492a@penduick> 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-6-0db98a7fe474@bootlin.com> <20251201-thick-jasmine-oarfish-1eceb0@houat> <20251215-mottled-dexterous-marmot-c69ad3@penduick> MIME-Version: 1.0 In-Reply-To: X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6287448762501947399==" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org --===============6287448762501947399== Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="65zjs456orcupskh" Content-Disposition: inline --65zjs456orcupskh Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 06/26] drm/bridge: add devm_drm_of_find_bridge MIME-Version: 1.0 On Mon, Dec 15, 2025 at 03:11:21PM +0100, Luca Ceresoli wrote: > Hi Maxime, >=20 > On Mon Dec 15, 2025 at 11:35 AM CET, Maxime Ripard wrote: > [...] > >> > Additionally, as a matter of fact there are currently drivers storing > >> > bridge pointers. The next_bridge is the most common case. Code using > >> > drm_bridge_connector_init() for example can store up to eight of the= m, but > >> > individual drivers are the hardest to hunt for. > >> > > >> > I can see these (potential) tools to handle this (not mutually exclu= sive): > >> > > >> > 1. remove drm_bridge pointers pointing to other bridges > >> > 2. check whether a bridge (say B) still exists before any dereferen= ce > >> > to B->another_bridge: that's drm_bridge_enter/exit() > >> > 3. let owners of bridge pointers be notified when a bridge is unplu= gged, > >> > so they can actively put their reference and clear their pointer > >> > > >> > For item 1, I think the drm_of_bridge_attach() idea quoted above wou= ld > >> > work, at least for the simple cases where bridge drivers use the > >> > next_bridge only for attach. A next_bridge pointer in struct drm_bri= dge is > >> > not even needed in that case, the pointer would be computed from OF = when > >> > needed and not stored. I can do an experiment and send a first serie= s, do > >> > you think it would be useful? > >> > >> I had a look and, while the implementation should be simple, only a few > >> drivers could benefit right now. The majority fall into one of these > >> categories: > >> > >> * drivers using drm_of_find_panel_or_bridge() or *_of_get_bridge() > >> (maybe 60-80% of all drivers, those will have to wait for the panel > >> improvements) > >> * drivers using the next_bridge pointer for more than just attach > >> * drivers doing more complicated stuff > >> > >> I think your "put next_bridge in __drm_bridge_free" idea would fit wel= l the > >> 2nd category and perhaps also the 1st one. For the 3rd category we'd n= eed > >> something different, e.g. a per-driver .destroy callback. > > > > Yep, that's fine. We should optimize for the common case, with an escape > > hatch. That's exactly what we are talking about here. >=20 > Not sure why, but it's taking a while before I grasp your ideas about this > series and meld them with mine. I hopefully got a clear POV now, so based > on it my plan is to rework this series to: >=20 > * keep drm_of_find_bridge() but renamed to of_drm_get_bridge(), and keep > patches 1-5 (with the changes suggested by you and Louis, nothing big > and all already sent in v2) I don't think we should use that name, but on principle, yes. > * not add devm_drm_of_find_bridge() Yep. > * add next_bridge pointer to struct drm_bridge and call > drm_bridge_put(bridge->next_bridge) in __drm_bridge_free, document it We don't have to at this point, you can add next_bridge to the drm_bridge pointer if you want, but I don't consider it a prerequisite. If we don't we would have to create drm_bridge_funcs->destroy implemnentations to give up the driver pointer reference though. Your call. > * convert patches 7-26 to use bridge->next_bridge where applicable, > or to do something different when needed Depending on your decision above, we'd need to either convert them to use drm_bridge->next_bridge or create a destroy hook for them. Either way is fine for me. > * maybe remove part of patches 7-26 just to reduce spam and rework effort > in case of further iterations, to send them separately once the approa= ch > is accepted >=20 > Does it look OK? Yep Maxime --65zjs456orcupskh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaUFjcwAKCRAnX84Zoj2+ dgzkAYDvA9yfAoN5qn3Uuq31rvBMPARdeaGJP/R7L/afEIqfYpW00Xnt3rcpsKVt DvfNFYwBf0vpoxbPBiXv/KJmjkwFaLmGNHmvjyicK5vGQGOUo5Kn5EA6cWvB5aoe s/Mjb6G3Dw== =yqem -----END PGP SIGNATURE----- --65zjs456orcupskh-- --===============6287448762501947399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic --===============6287448762501947399==--