linux-kernel - Re: [PATCH v2] drm/panel: boe-bf060y8m-aj0: transition to mipi

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: <CAD=FV=XwczaG+FTBv_VxoR=GxNsXemCehkMc_V2=DDoXAepZoA@mail.gmail.com>
Date: Tue, 1 Apr 2025 08:06:55 -0700
From: Doug Anderson <dianders@...omium.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Tejas Vipin <tejasvipin76@...il.com>, neil.armstrong@...aro.org, 
	maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de, 
	airlied@...il.com, simona@...ll.ch, quic_jesszhan@...cinc.com, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	asrivats@...hat.com
Subject: Re: [PATCH v2] drm/panel: boe-bf060y8m-aj0: transition to mipi_dsi
 wrapped functions

Hi,

On Mon, Mar 31, 2025 at 6:52 PM Dmitry Baryshkov
<dmitry.baryshkov@....qualcomm.com> wrote:
>
> > > ...although I think you said that the DRM framework ignores errors
> > > from prepare() and still calls unprepare(). I guess this is in
> > > panel_bridge_atomic_pre_enable() where drm_panel_prepare()'s error
> > > code is ignored?
> >
>
> Hmm... Most of the drivers ignore the results of the drm_panel_prepare()
> / _unprepare() / _enable() / _disable(), but then the framework handles
> error values of the callbacks and skips calling the corresponding
> en/dis callback if the previous call has failed. Which means I was
> incorrect here.

Oh, right. LOL, that was even me adding that code in commit
d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
drm_panel"). It wasn't my intention there to work around the fact that
the panel_bridge ignores the error, but it's a happy accident. I guess
that means that the warning:

dev_warn(panel->dev, "Skipping unprepare of already unprepared panel\n");

...would also happen any time a panel prepare returned an error code
that was ignored by the bridge. That seems OK-ish to me even if the
comment above the warning doesn't list that as one of the reasons the
warning might be printed. I didn't test this myself, but assuming I
got it right does anyone want to submit a patch to add this reason to
the comment? ...or, maybe even better, we could fix the panel bridge
code to not call the panel unprepare if the prepare failed...

tl;dr for Tejas in this patch is that I still think he should spin his
patch to fix it so the regulators get disabled in the error case.

-Doug