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 0EB46C44501 for ; Wed, 15 Jul 2026 08:51:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: 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=qCXCuR71/7ld5fnjtnlVmFnztWKJMWhQGvsU4ArYfYA=; b=vS0an0wSa8vNEFu/+4rROOcoSh 7WRRCG5+4q3iMOpzW0vZmpDjjtsVpfqOKcnNoOkJ8i6rZxvmFeM1b96AK9stFGShMbHcYeLUXkPcb Zi3Cx9ynTP4KXrEaULhfFV7u4037zty7aYBETcxT9YD6SErt4VC2IhTMru9Gxpt4VU2Vz6aHcifdD pvJy29y2uf/5VTiMD4my9J+leR5bjN5riMAAc9fqdiZUULjRzwfEDQxJfsFguTA1Js4fdlOklV3p4 OTzP83qvswJyi0/EAsqh+mcFfPHpoLNPPLV/sILBHhGc1DrF7Tn7K6eyTpXMyPM9kgIkc9ZOucvuu zr6PQPUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjvKY-0000000ECwM-291W; Wed, 15 Jul 2026 08:51:02 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wjvKW-0000000ECw9-3C2U; Wed, 15 Jul 2026 08:51:00 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 3BDDA410A0; Wed, 15 Jul 2026 08:51:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DF18F1F00A3A; Wed, 15 Jul 2026 08:50:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784105460; bh=qCXCuR71/7ld5fnjtnlVmFnztWKJMWhQGvsU4ArYfYA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VQhVquvDAc+PivI/GgyNFhFfn9k464FvW3H7RbaIZZXJBVbfy+eex8r/WHi4TJk8J nUL2aLzEqlYTz+ATctm79EbpCBG7U4OgJ4oawXt7ct5zFYF3C3D959gyOSC7H26lok QSlTykWXAyKwN2JFke23qMOalptkbylWE6cCIZ/PLbIciu34ADYoQi2+MXDlwvsDSA r5H9jPjuair7oq48ERmBQIdSCsrJPpwAAgfXDZJGu6WgKffYanuzqDOXDQOEhacYIt YwoN7xM4UUAnXVLzszXu5o1aFEreAgIbT43mjXvljwwaSdEmt9wnbHFjCXLdj9Mq7Z uRnRYUqajBIAQ== Date: Wed, 15 Jul 2026 10:50:55 +0200 From: Maxime Ripard To: Cristian Ciocaltea Cc: Dmitry Baryshkov , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Sandy Huang , Heiko =?utf-8?Q?St=C3=BCbner?= , Andy Yan , Daniel Stone , Dave Stevenson , =?utf-8?B?TWHDrXJh?= Canal , Raspberry Pi Kernel Maintenance , kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Subject: Re: [PATCH v8 02/39] drm/connector: Add caps-based HDMI connector init helper Message-ID: <20260715-fair-opalescent-rhino-c6407b@houat> References: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com> <20260702-dw-hdmi-qp-scramb-v8-2-d79890d00b6a@collabora.com> <20260707-illegal-tuna-of-force-1c06e3@houat> <737678ab-f082-4a0e-b453-f403ba141437@collabora.com> <80374deb-3246-413f-a043-66bcdb438ab1@collabora.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="z6feftgsn6dp6gmq" Content-Disposition: inline In-Reply-To: <80374deb-3246-413f-a043-66bcdb438ab1@collabora.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --z6feftgsn6dp6gmq Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v8 02/39] drm/connector: Add caps-based HDMI connector init helper MIME-Version: 1.0 On Fri, Jul 10, 2026 at 01:27:37PM +0300, Cristian Ciocaltea wrote: > On 7/8/26 1:11 PM, Cristian Ciocaltea wrote: > > Hi Maxime, > >=20 > > On 7/7/26 7:10 PM, Maxime Ripard wrote: > >> On Fri, Jul 03, 2026 at 10:31:55PM +0300, Cristian Ciocaltea wrote: > >>> Hi Dmitry, > >>> > >>> Thanks for your quick review! > >>> > >>> On 7/3/26 5:05 PM, Dmitry Baryshkov wrote: > >>>> On Thu, Jul 02, 2026 at 05:46:15PM +0300, Cristian Ciocaltea wrote: > >>>>> In preparation for adding HDMI 2.x source capabilities, introduce s= truct > >>>>> drm_connector_hdmi_caps and a new drmm_connector_hdmi_init_with_cap= s() > >>>>> helper. > >>>>> > >>>>> The existing drmm_connector_hdmi_init() helper currently takes > >>>>> individual capability arguments such as supported_formats and max_b= pc. > >>>>> Adding more HDMI-specific arguments to that function would not scale > >>>>> well, so move those values into a dedicated capabilities structure = and > >>>>> implement the existing helper as a wrapper around the new caps-based > >>>>> interface. > >>>> > >>>> I think, it was an intention of Maxime: make sure that every driver = is > >>>> forced to provide some values here. With the struct-based init it is > >>>> easy to overlook or to ommit a value. > >>> > >>> Agreed that the struct-based init loses the compile-time guarantee th= at every > >>> argument is explicitly provided - that's a real downside. =20 > >>> > >>> I'd argue it's recoverable, though: the init helper validates the man= datory > >>> fields, so a driver that omits a required value gets rejected at init= time > >>> rather than silently misconfigured. The "you must provide sane value= s" property > >>> is expected to be preserved, just enforced at runtime instead of by t= he > >>> compiler.=20 > >> > >> Yeah, I don't think we can win with C here. Rust might, but we're > >> probably a long way from that. > >> > >>> The main motivation for the struct is scalability/maintainability as = we add HDMI > >>> 2.x capabilities: new fields go into the struct rather than growing t= he helper's > >>> argument list, so existing callers don't need churny signature update= s on every > >>> extension. > >>> > >>> FWIW, in the previous revision we discussed addressing the concern wi= th a > >>> callback instead. Sadly, I had to discard that approach, as it prove= d not > >>> flexible enough, e.g. drm_bridge_connector_init() computes caps dynam= ically, and > >>> would have required either stateful callbacks, or storing redundant/t= emporary > >>> cap data in driver-private structures just to satisfy the callback. > >> > >> I just realized something reviewing your patch: we don't necessarily > >> need an extra argument or a callback, we can just put these fields into > >> drm_hdmi_connector_funcs directly, and then validate them in init. > >=20 > > If I understand correctly, we should drop the drm_connector_hdmi_caps s= truct > > introduced by this patch and move all its fields into drm_hdmi_connecto= r_funcs. > >=20 > > In that case, how should we proceed with drmm_connector_hdmi_init()?=20 >=20 > Actually, this brings us to the callback issue: we cannot compute caps > dynamically, as it only works with static data, since funcs is supposed t= o be > immutable. Does it? The core and helpers must consider it immutable but it doesn't have to. drm_bridge_connector for example could totally allocate it and dynamically create it based on the bridge capabilities. > Moreover, we would end up with some redundancy, as most of these input fi= elds, > after validation, would be stored (altered or not) directly in > drm_connector/drm_connector_hdmi structs. I mean, part of the conversion would obviously be to remove the redundant fields. --z6feftgsn6dp6gmq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaldJ7wAKCRAnX84Zoj2+ dj33AX0ZUsd0ZtnCvNBfTVx1xc4lSlqSv96jF6MDRJm86n/BZPlTwIJXMW8LPOHp JGjDi6IBf2x6ikh1LwU7GSjP2yjVDjaxBerQjTbrwYyl3BAD2SowFtEHHWKJpUMH YvcCar5zdQ== =VuTq -----END PGP SIGNATURE----- --z6feftgsn6dp6gmq--