linux-kernel - Re: [PATCH v6] drm/dp: clamp PWM bit count to advertised MIN and MAX 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aIIB3G6WEEzldXEn@hovoldconsulting.com>
Date: Thu, 24 Jul 2025 11:50:20 +0200
From: Johan Hovold <johan@...nel.org>
To: Neil Armstrong <neil.armstrong@...aro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
	Christopher Obbard <christopher.obbard@...aro.org>,
	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,
	Rui Miguel Silva <rui.silva@...aro.org>,
	Abel Vesa <abel.vesa@...aro.org>
Subject: Re: [PATCH v6] drm/dp: clamp PWM bit count to advertised MIN and MAX
 capabilities

On Thu, Jul 24, 2025 at 11:42:38AM +0200, Neil Armstrong wrote:
> On 24/07/2025 11:32, Dmitry Baryshkov wrote:
> > On Thu, 24 Jul 2025 at 12:08, <neil.armstrong@...aro.org> wrote:
> >> On 20/05/2025 10:06, Johan Hovold wrote:
> >>> On Fri, Apr 04, 2025 at 02:24:32PM +0100, Christopher Obbard wrote:
> >>>> On Fri, 4 Apr 2025 at 09:54, Johan Hovold <johan@...nel.org> wrote:
> >>>>> On Fri, Apr 04, 2025 at 08:54:29AM +0100, Christopher Obbard wrote:
> >>>>>> On Mon, 31 Mar 2025 at 09:33, Johan Hovold <johan@...nel.org> wrote:

> >>>>>>>> +     /*
> >>>>>>>> +      * Per VESA eDP Spec v1.4b, section 3.3.10.2:
> >>>>>>>> +      * If DP_EDP_PWMGEN_BIT_COUNT is less than DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN,
> >>>>>>>> +      * the sink must use the MIN value as the effective PWM bit count.
> >>>>>>>> +      * Clamp the reported value to the [MIN, MAX] capability range to ensure
> >>>>>>>> +      * correct brightness scaling on compliant eDP panels.
> >>>>>>>> +      */
> >>>>>>>> +     pn = clamp(pn, pn_min, pn_max);
> >>>>>>>
> >>>>>>> You never make sure that pn_min <= pn_max so you could end up with
> >>>>>>> pn < pn_min on broken hardware here. Not sure if it's something you need
> >>>>>>> to worry about at this point.
> >>
> >> I'm trying to figure out what would be the behavior in this case ?
> >>
> >> - Warn ?
> >> - pn_max = pn_min ?
> >> - use BIT_COUNT as-is and ignore MIN/MAX ?
> >> - pm_max = max(pn_min, pn_max); pm_min = min(pn_min, pn_max); ?
> >> - reverse clamp? clamp(pn, pn_max, pn_min); ?
> >> - generic clamp? clamp(pn, min(pn_min, pn_max), max(pn_min, pn_max)); ?
> > 
> > Per the standard, the min >= 1 and max >= min. We don't need to bother
> > about anything here.
> 
> Yeah, I agree. But I think a:
> if (likely(pn_min <= pn_max))
> is simple and doesn't cost much...

> >> Or just bail out ?

Yeah, just bail out. If we ever run into broken hardware like this, we
can determine some workaround then.

Johan