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: <CACr-zFDUMzb+jKcBc1SfpsOiQsAJJ0jsPdS-vcA=OXy-K3pfQQ@mail.gmail.com>
Date: Sun, 30 Mar 2025 19:05:43 +0100
From: Christopher Obbard <christopher.obbard@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, Johan Hovold <johan@...nel.org>, 
	Rui Miguel Silva <rui.silva@...aro.org>, Abel Vesa <abel.vesa@...aro.org>
Subject: Re: [PATCH v5] drm/dp: clamp PWM bit count to advertised MIN and MAX capabilities

Hi Dmitry,

On Sun, 30 Mar 2025 at 18:56, Dmitry Baryshkov
<dmitry.baryshkov@....qualcomm.com> wrote:
>
> On Sun, Mar 30, 2025 at 06:49:40PM +0100, Christopher Obbard wrote:
> > According to the eDP specification (VESA Embedded DisplayPort Standard
> > v1.4b, Section 3.3.10.2), if the value of DP_EDP_PWMGEN_BIT_COUNT is
> > less than DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, the sink is required to use
> > the MIN value as the effective PWM bit count.
> >
> > This commit updates the logic to clamp the reported
> > DP_EDP_PWMGEN_BIT_COUNT to the range defined by
> > DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN and _CAP_MAX. As part of this change,
> > the behavior is modified such that reading _CAP_MIN and _CAP_MAX
> > registers is now required to succeed. Before reading these registers
> > was optional.
>
> Describe why, not what. Something like 'is now required to succeed,
> otherwise bl->max value can end up being not set, although
> drm_edp_backlight_probe_max() returned success'.
>
> LGTM otherwise.

Amazing. We got there eventually!
I updated the commit message around this change to be:

    As part of this change, the behavior is modified such that reading both
    _CAP_MIN and _CAP_MAX registers is now required to succeed, otherwise
    bl->max value could end up being not set although
    drm_edp_backlight_probe_max() returned success.


I will wait for more feedback for few days before sending the next version.


Cheers!

Chris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ