linux-kernel - Re: [PATCH v3 16/19] drm/amd/display: Add parameter to control ALLM behavior

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADnq5_Nrni6_Y7BCn9GH-aF2A1iOjgbr4Ebouf76Qogtb_v3zQ@mail.gmail.com>
Date: Tue, 10 Feb 2026 14:17:15 -0500
From: Alex Deucher <alexdeucher@...il.com>
To: Tomasz Pakuła <tomasz.pakula.oficjalny@...il.com>
Cc: Harry Wentland <harry.wentland@....com>, alexander.deucher@....com, sunpeng.li@....com, 
	maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de, 
	airlied@...il.com, simona@...ll.ch, siqueira@...lia.com, 
	dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, bernhard.berger@...il.com, 
	michel.daenzer@...lbox.org, daniel@...ishbar.org, admin@...1337.dev
Subject: Re: [PATCH v3 16/19] drm/amd/display: Add parameter to control ALLM behavior

On Tue, Feb 10, 2026 at 1:44 PM Tomasz Pakuła
<tomasz.pakula.oficjalny@...il.com> wrote:
>
> On Fri, 2026-02-06 at 17:04 -0500, Alex Deucher wrote:
> >
> > Also, maybe a per connector kms property would be preferable.  Then
> > you could change it per display.
> >
> > Alex
>
> I've dealt with all Harry's comments but wanted to make sure I
> understand properly. Do you mean, that the two settings should be a
> connector property like VRR_ENABLED? I understand the intent and I think
> in some time, it would be best to have these exposed in compositor
> settings but how would a user control this until then?
>
> Would it suffice to fire IOCTLs from a third-party tool like LACT where
> support for this could be added in a short time?
>
> I made it a module property in the first place, because I thought such
> settings are pretty set-and-forget and module properties are just easy
> to set :)
>
> Still, I think the defaults are sane. If I have to spend some more time
> to get the connector properties working, I could send the patches with
> the module properties ripped out for now.

My understanding is that these are something the compositor would like
to manage.  I'd like to avoid adding module parameters if we can help
it because they usually cause more trouble than they help due to
unforeseen interactions with other features or "conventional wisdom"
blindly followed which leads to a bad user experience.

Alex