linux-kernel - Re: [PATCH v2] drm/panel: raydium-rm692e5: 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: <CAA8EJpr_HYkXnP3XR9LpDhi1xkQfE_CKJzfzGrO5qd_pQYtiOw@mail.gmail.com>
Date: Thu, 20 Jun 2024 17:54:30 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Tejas Vipin <tejasvipin76@...il.com>, neil.armstrong@...aro.org, 
	quic_jesszhan@...cinc.com, maarten.lankhorst@...ux.intel.com, 
	mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com, daniel@...ll.ch, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] drm/panel: raydium-rm692e5: transition to mipi_dsi
 wrapped functions

On Thu, 20 Jun 2024 at 17:42, Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Wed, Jun 19, 2024 at 12:23 AM Tejas Vipin <tejasvipin76@...il.com> wrote:
> >
> >
> >
> > On 6/19/24 12:06 PM, Dmitry Baryshkov wrote:
> > > On Wed, Jun 19, 2024 at 09:03:49AM GMT, Tejas Vipin wrote:
> > >> Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce
> > >> mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
> > >> ("drm/mipi-dsi: wrap more functions for streamline handling") for the
> > >> raydium rm692e5 panel.
> > >>
> > >> Signed-off-by: Tejas Vipin <tejasvipin76@...il.com>
> > >> ---
> > >> Changes in v2:
> > >>     - Change rm692e5_on to return void and take mipi_dsi_multi_context
> > >>       as an argument.
> > >>     - Remove unnecessary warnings.
> > >>     - More efficient error handling in rm692e5_prepare
> > >>
> > >> v1: https://lore.kernel.org/all/20240615093758.65431-1-tejasvipin76@gmail.com/
> > >> ---
> > >>  drivers/gpu/drm/panel/panel-raydium-rm692e5.c | 237 ++++++++----------
> > >>  1 file changed, 99 insertions(+), 138 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm692e5.c b/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> > >> index 21d97f6b8a2f..9936bda61af2 100644
> > >> --- a/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> > >> +++ b/drivers/gpu/drm/panel/panel-raydium-rm692e5.c
> > >
> > >>  static int rm692e5_prepare(struct drm_panel *panel)
> > >>  {
> > >>      struct rm692e5_panel *ctx = to_rm692e5_panel(panel);
> > >>      struct drm_dsc_picture_parameter_set pps;
> > >> -    struct device *dev = &ctx->dsi->dev;
> > >> -    int ret;
> > >> +    struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> > >>
> > >> -    ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> > >> -    if (ret < 0) {
> > >> -            dev_err(dev, "Failed to enable regulators: %d\n", ret);
> > >> -            return ret;
> > >> -    }
> > >> +    dsi_ctx.accum_err = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> > >> +    if (dsi_ctx.accum_err)
> > >> +            return dsi_ctx.accum_err;
> > >
> > > int ret, please. Let's leave dsi_ctx.accum_err for DSI errors only.
> > > LGTM otherwise.
> >
> > Is this really necessary seeing how regulator_bulk_enable returns
> > 0 on success anyways? It saves creating a new variable for a single
> > check. In case you do think its necessary, should it be changed in
> > himax_hx83102 too?
>
> Right. I made the same choice as Tejas did when I wrote commit
> a2ab7cb169da ("drm/panel: himax-hx83102: use wrapped MIPI DCS
> functions"). In that commit message, I wrote:
>
> It can also be noted that hx83102_prepare() has a mix of things that
> can take advantage of _multi calls and things that can't. The cleanest
> seemed to be to use the multi_ctx still but consistently use the
> "accum_err" variable for error returns, though that's definitely a
> style decision with pros and cons.
>
> In my mind trying to juggle half the cases having the error in "ret"
> and half in the DSI context was a recipe for getting mixed up and
> returning the wrong error. On the other hand, it felt awkward using
> the "dsi_ctx.accum_err". In the end I felt that the extra awkwardness
> was worth it if it meant that I was less likely to "return ret" when
> the error code was actually in "dsi_ctx.accum_err"...

Fair point.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>


-- 
With best wishes
Dmitry