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
signature.asc
Description: PGP signature
