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 B0DE4D74976 for ; Fri, 19 Dec 2025 09:55:02 +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=lLAToM4vXYl2Fk0i65uKXkKio3mzy30inkIA9FUKzC8=; b=aDNLi+JarTLHwyMnlh27xTrSOn tzgyGxf3nkxrQjb01lEKtUEfCk+hND13m4Ba8zyCX10Y8GukVZJkHMTAabGRDerPBFdnHk1TyYhl1 HX7hor4xela9/BceIdG78GsmSPMbJhD02j+rMpS12V1vMYf3Ur6f75qjy2ILJA+cleabh1XjWlWyR wVuKfurWQlqaUdgc5oG8lIbODo2ZozeYsTgHqlc6Z0X1rJp0p45hA5+zLAta9PwsYSKHtWXAdX/T0 SfRKsbsDTCLGw3FUTIImW/KLDXRNP7WfOPbj9D4D5R6lqXqobe14FER5C65NlqycAHLAWKn/sxCgb nS5hP24g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vWXCM-00000009zUG-2qdm; Fri, 19 Dec 2025 09:54:58 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vWXCL-00000009zTR-2lqB; Fri, 19 Dec 2025 09:54:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 40C4F60052; Fri, 19 Dec 2025 09:54:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D23DC4CEF1; Fri, 19 Dec 2025 09:54:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766138095; bh=lLAToM4vXYl2Fk0i65uKXkKio3mzy30inkIA9FUKzC8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=teXlBuee2SGaO5gKVF903njhhJJyujvg1pKd00OAnL4abuUsJGZgjZ/0ok7vhvth2 bcU+XqvTdsUyWpkZpecWy100vQ079+cxQeWRi+28eSuxcQrmBsLYtlz8WUeWJfVcUq +RSFqfo+R8zPY9wxRSVJOku2ErSx+BR2ZCiVm+A8ItqaKkKKlUy9gBMgtux8Nv7KL2 36u+gOWyi0sgXtCiS2eR5uhq+yjpSWREwBllUfGexMuL23TknUzZrPf8XTKmynGAA8 1YQnPj5YlHg8F3o877ew2QqD0hGZ++OqK+GF6FOX8VBhoy97Wb2Ohwj90JxEb6WA+M rkKF3JhaRlT8A== Date: Fri, 19 Dec 2025 10:54:53 +0100 From: Maxime Ripard To: Dmitry Baryshkov Cc: Daniel Stone , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Sandy Huang , Heiko =?utf-8?Q?St=C3=BCbner?= , Andy Yan , Chen-Yu Tsai , Samuel Holland , Dave Stevenson , =?utf-8?B?TWHDrXJh?= Canal , Raspberry Pi Kernel Maintenance , Liu Ying , Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , Marijn Suijten , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org Subject: Re: [PATCH v3 00/11] drm/connector: hdmi: limit infoframes per driver capabilities Message-ID: <20251219-honest-slim-crab-02e932@houat> References: <20250929-gregarious-worm-of-memory-c5354d@houat> <20251003-uptight-echidna-of-stamina-815305@houat> <2a5fitdzr2bz235fj6rvqzxr6ckszkjbazjfszlvnizdh2cvbt@w3ypjo7vahhs> <20251201-enlightened-zebu-from-asgard-5a20be@houat> <5dyhjur3hkhvtlwrl4h2m342byor7f3ssvkunj4cggnhbhlmnb@l2mfz7ypjj37> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha384; protocol="application/pgp-signature"; boundary="pxgyrzpu3xrfoz5s" Content-Disposition: inline In-Reply-To: <5dyhjur3hkhvtlwrl4h2m342byor7f3ssvkunj4cggnhbhlmnb@l2mfz7ypjj37> 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 --pxgyrzpu3xrfoz5s Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v3 00/11] drm/connector: hdmi: limit infoframes per driver capabilities MIME-Version: 1.0 On Sat, Dec 06, 2025 at 01:28:14PM +0200, Dmitry Baryshkov wrote: > On Mon, Dec 01, 2025 at 06:01:56PM +0100, Maxime Ripard wrote: > > On Fri, Nov 21, 2025 at 07:09:01PM +0200, Dmitry Baryshkov wrote: > > > > So it's not really impossible, you just need some hardware and a da= y's > > > > worth of work. > > > >=20 > > > > There's no reason these should get a pass, it's breaking the spec f= or no > > > > reason. > > > >=20 > > > > > > For SPD, It's really not clear to me why atomic_check should do= that in > > > > > > the first place. Your initial concern was about exposing infofr= ames in > > > > > > debugfs that wouldn't be used by the driver. > > > > > >=20 > > > > > > If the driver doesn't register a debugfs file for SPD, and igno= res > > > > > > whatever is in the atomic state, what's should we force drivers= to do > > > > > > that? > > > > >=20 > > > > > I really don't think that drivers should mess up with debugfs on = their > > > > > own. Making atomic_check() disable the unsupported InfoFrames mak= es the > > > > > picture perfect: the DRM no longer tries to program them to the > > > > > hardware, DebugFS files stay empty, so the whole state becomes > > > > > consistent. > > > >=20 > > > > In the "bridge has no access to infoframes" case, there's really no > > > > infoframe. An empty file is "the infoframe can be there but isn't u= sed", > > > > not "we don't have access to it and can't report them". Only drivers > > > > have those infos. > > > >=20 > > > > If we do split up write_infoframe into multiple functions though, I > > > > guess we could create the debugfs file only if the function pointer= is > > > > set, which removes drivers' involvement if you don't like that. > > >=20 > > > I'm fine with not using HDMI connector framework for lt9611uxc. > > > Likewise, I think, it's fine to have empty files for the infoframes > > > which are not being sent over the wire for any reason (hw not support= ing > > > it is one of the reasons). > >=20 > > I can't think of any other example in the kernel where an empty file > > means that the driver doesn't support something. >=20 > Okay. So we need to sort out implementing the split write_infoframes in > drm_bridge_connector. Any suggestions there? I'm asking, because I don't > want to end up exploding it. I guess it's only really a problem if we want to make it const, but we don't have to? We could just as well allocate the structure directly at probe with a drmm helper and fill it as we need to. Maxime --pxgyrzpu3xrfoz5s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaUUg7AAKCRAnX84Zoj2+ dvkCAYDaU48ga79KBvkIgWW7cnrj0Ae2GfJE5Y2GVVoq0UjRWC1zmLdmNFkjoQil PD3wip4BgKf036443KTFOFktbqXWVW+vD37BVUvEwYqWrRwP+AK/8QBWIjjg9BKx PWhjchksXg== =penr -----END PGP SIGNATURE----- --pxgyrzpu3xrfoz5s--