linux-kernel - Re: [PATCH] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write

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: <CAD=FV=XNbRauayNFNOODm-aaaLy2_vJk8OW-mR_XmLv505RtGA@mail.gmail.com>
Date: Fri, 26 Apr 2024 08:28:30 -0700
From: Doug Anderson <dianders@...omium.org>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: dri-devel@...ts.freedesktop.org, 
	Javier Martinez Canillas <javierm@...hat.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, linus.walleij@...aro.org, 
	Cong Yang <yangcong5@...qin.corp-partner.google.com>, 
	lvzhaoxiong@...qin.corp-partner.google.com, Hsin-Yi Wang <hsinyi@...gle.com>, 
	Sam Ravnborg <sam@...nborg.org>, Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()

Hi,

On Fri, Apr 26, 2024 at 3:09 AM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>
> > 2. Accept that a slightly less efficient handling of the error case
> > and perhaps a less intuitive API, but avoid the goto.
> >
> > Essentially you could pass in "ret" and have the function be a no-op
> > if an error is already present. Something like this:
> >
> > void mipi_dsi_dcs_write_buffer_multi(struct mipi_dsi_device *dsi,
> > const void *data, size_t len, int *accum_ret)
> > {
> >   if (*accum_ret)
> >     return;
> >
> >   *accum_ret = mipi_dsi_dcs_write_buffer(dsi, data, len);
>
> No reason you couldn't do error logging here
>
>         if (*accum_ret)
>                 dev_err(...)

Yup, exactly. This is probably best.


> > }
> >
> > ...and then the caller:
> >
> > int ret;
> >
> > ret = 0;
> > mipi_dsi_dcs_write_seq_multi(dsi, HX83102_SETSPCCMD, 0xcd, &ret);
> > mipi_dsi_dcs_write_seq_multi(dsi, HX83102_SETMIPI, 0x84, &ret);
> > mipi_dsi_dcs_write_seq_multi(dsi, HX83102_SETSPCCMD, 0x3f, &ret);
> > mipi_dsi_dcs_write_seq_multi(dsi, HX83102_SETVDC, 0x1b, 0x04, &ret);
> > if (ret)
> >   goto some_cmd_failed;
> >
> > This has similar properties to solution #1.
>
> I like this option the best, for the simple reason that the caller side
> is aware of what's going on, there's no magic control flow happening,
> and they can add error handling in the middle if they so choose.

Sounds good to me. I went back and forth a bit between solution #1 and
this and I see the benefits of both. If folks like this one I think we
should run with it. Certainly it's better than the current hidden
return.



> I don't find this unintuitive, but if it helps, you could conceivably
> add a context parameter:
>
>         struct mipi_dsi_seq_context context = {
>                 .dsi = dsi,
>         };
>
>         mipi_dsi_dcs_write_seq(&context, HX83102_SETSPCCMD, 0xcd);
>         ...
>
>         if (context.ret)
>                 ...
>
> And even have further control in the context whether to log or keep
> going or whatever.

I agree there are some benefits of adding the extra "context"
abstraction and we can go that way if you want, but I lean towards the
simplicity of just passing in the accumulated return value like I did
in my example.


I'll try to write up patches and see if I can post them later today.

-Doug