linux-kernel - Re: [PATCH v3 00/11] drm/connector: hdmi: limit infoframes per driver capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251201-enlightened-zebu-from-asgard-5a20be@houat>
Date: Mon, 1 Dec 2025 18:01:56 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Daniel Stone <daniel@...ishbar.org>, 
	Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Sandy Huang <hjc@...k-chips.com>, Heiko Stübner <heiko@...ech.de>, 
	Andy Yan <andy.yan@...k-chips.com>, Chen-Yu Tsai <wens@...e.org>, 
	Samuel Holland <samuel@...lland.org>, Dave Stevenson <dave.stevenson@...pberrypi.com>, 
	Maíra Canal <mcanal@...lia.com>, Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>, 
	Liu Ying <victor.liu@....com>, Rob Clark <robin.clark@....qualcomm.com>, 
	Dmitry Baryshkov <lumag@...nel.org>, Abhinav Kumar <abhinav.kumar@...ux.dev>, 
	Jessica Zhang <jessica.zhang@....qualcomm.com>, Sean Paul <sean@...rly.run>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, linux-sunxi@...ts.linux.dev, 
	linux-arm-msm@...r.kernel.org, freedreno@...ts.freedesktop.org
Subject: Re: [PATCH v3 00/11] drm/connector: hdmi: limit infoframes per
 driver capabilities

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 day's
> > worth of work.
> > 
> > There's no reason these should get a pass, it's breaking the spec for no
> > reason.
> > 
> > > > 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 infoframes in
> > > > debugfs that wouldn't be used by the driver.
> > > > 
> > > > If the driver doesn't register a debugfs file for SPD, and ignores
> > > > whatever is in the atomic state, what's should we force drivers to do
> > > > that?
> > > 
> > > I really don't think that drivers should mess up with debugfs on their
> > > own. Making atomic_check() disable the unsupported InfoFrames makes the
> > > picture perfect: the DRM no longer tries to program them to the
> > > hardware, DebugFS files stay empty, so the whole state becomes
> > > consistent.
> > 
> > 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 used",
> > not "we don't have access to it and can't report them". Only drivers
> > have those infos.
> > 
> > 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.
> 
> 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 supporting
> it is one of the reasons).

I can't think of any other example in the kernel where an empty file
means that the driver doesn't support something.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)