From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 7D1CA261B71 for ; Mon, 24 Aug 2026 14:15:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787580940; cv=none; b=MabbPDWgJ84CMvPPFC0Zcsk6mp+kGczATWUzI5fI1uXtmjL4DgpKekQzgMooCkRPr+cpGp/DwwuIrldxWlcVy1jahNQJt1LCALF9W7uXBb6HjvKupAqm/SidsFvnJICDJVcS59TtqS8i3ZabuZy+hYF5HFIw2kk/0S6OyL/BjJU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787580940; c=relaxed/simple; bh=XlXJ0Ie1QBHm5RA3LqI0KK7iOkr6C4/TB9zu2NQ9UvQ=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=Nw6UQrYf9i5M+urVZydp/qGEAAv0ushY5rT9IfRedaAOFDEPL/yBghSZGA82rF8/FlxInGrsIUKxLZp7hmOTxtoHYPMiEag8E1NgccGKe6jPLBo7e2kD1H3d0GJ9pONgv6E46bikOI0zFfQ5EcacIQ+74fop/37w/xoFt7thT/s= 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=SMAlbzKZ; arc=none smtp.client-ip=185.246.84.56 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="SMAlbzKZ" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 72B751A17F1; Mon, 24 Aug 2026 14:15:34 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 284EC5FFC1; Mon, 24 Aug 2026 14:15:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 8C3F111C7960F; Mon, 24 Aug 2026 16:15:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1787580928; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=fDfp3NHZrd988nm512Rv8Wp1AlDvw7budIHe/KVemzQ=; b=SMAlbzKZtIDsTBVND+4uH39mO4f15QMchLezjx0xEb3e5uw1HDbfBrJeU4oTTHB7B32DD3 gHLyPPoEE4X8Xz3HGwRWTN7Z1i08zGU039VKvxJQeMIMbvAD5irvlN6MOIuzS8q9ro5D5s w0iPc/1uWiRDO14kpbAMgSQ/68K/5juDDyIY+pfYf5FICqhMdTCEooOmXhHpVRDwjPH+BS feyCEV1+1JmSvfshmjKYHq1Pi38BXuw+4QQDZo3+euQsMHZu8p3PiCD8WLXkT4irRTPss5 ASxL5dzsR6SZ3GCfxGJb74n1Xue0YrArAMF212YKZQnVVtqvZ80i3YWCwuKNBA== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org 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 Aug 2026 16:15:18 +0200 Message-Id: Cc: "Maarten Lankhorst" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Andrzej Hajda" , "Neil Armstrong" , "Robert Foss" , "Laurent Pinchart" , "Jonas Karlman" , "Jernej Skrabec" , "Jessica Zhang" , "Linus Walleij" , "Inki Dae" , "Jagan Teki" , "Marek Szyprowski" , "Dmitry Baryshkov" , "Hui Pu" , "Ian Ray" , "Thomas Petazzoni" , , To: "Maxime Ripard" , "Luca Ceresoli" From: "Luca Ceresoli" Subject: Re: [PATCH 03/11] drm: of: drm_of_find_panel_or_bridge: prioritize the bridge, not the panel X-Mailer: aerc 0.22.0 References: <20260814-drm-bridge-every-panel-v1-0-19cd5277cc8d@bootlin.com> <20260814-drm-bridge-every-panel-v1-3-19cd5277cc8d@bootlin.com> <20260817-wonderful-helpful-falcon-db81c9@houat> <20260824-bouncy-papaya-cat-2c2073@houat> In-Reply-To: <20260824-bouncy-papaya-cat-2c2073@houat> X-Last-TLS-Session-Version: TLSv1.3 Hi Maxime, On Mon Aug 24, 2026 at 10:16 AM CEST, Maxime Ripard wrote: > On Mon, Aug 17, 2026 at 02:23:05PM +0200, Luca Ceresoli wrote: >> > That being said, if we do create a panel_bridge for every panel, why d= o >> > we still need drm_of_find_panel_or_bridge()? We'll only really need >> > of_drm_find_bridge(), no? >> >> Yes, in the long term we can get rid of drm_of_find_panel_or_bridge(), b= ut >> not in the short term due to the above mentioned drivers, and others whi= ch >> use it in "creative" ways. >> >> The point is about the transition. This patch was an attempt to convert = at >> once all the many drivers which use the most common pattern: >> >> | drm_of_find_panel_or_bridge(..., &panel, &bridge); >> | if (panel) >> | bridge =3D drm_panel_bridge_add(); >> >> to then fix manually the remaining drivers (patches 6-11). >> >> But this approach doesn't fly due to the legacy users of >> drm_of_find_panel_or_bridge() as mentioned above. >> >> So what about this other approach instead: >> >> 1. leave drm_of_find_panel_or_bridge() as is (it's already deprecated a= nyway) >> 2. keep patch 5 (which "breaks" mayt drivers which would create an addi= tional >> panel_bridge) >> 3. perhaps add a warning when an additional bridge is created for the >> some panel >> 4. *in the same series*, manually convert *all* drivers to use >> of_drm_find_bridge() or of_drm_get_bridge_by_endpoint() -- like patc= hes >> 6-11, but done on all drivers >> 5. apply the series atomically, because it wouldn't be bisectable betwe= en >> items 2 and 4 >> >> Your opinion? > > If we look at the drivers causing us troubles, fsl-ldb, samsung-dsim, > tc358767 and waveshare-dsi can be converted directly to > devm_drm_of_get_bridge(). > > mcde-dsi is a mess and would be hard to fix indeed, but since it's the > only really troublesome one, maybe we can just duplicate the code in the > driver and drop / rewrite the common code however we see fit. Note there are many more drivers than those converted by patches 6-11 of this series (see cover letter). So it would be a lot more work. But based on your reply I assume you approve the 5-point plan above. Please let me know if my understanding is incorrect. Also note my plan is to try converting all drivers, definitely removing all calls to drm_panel_bridge_add() and variants but not necessarily drm_of_find_panel_or_bridge(), which then might exist for a longer time. I'll see how things go as I look at drivers one my one. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com