Received-SPF: pass (google.com: domain of linux-kernel+bounces-160286-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid>
 <87pludq2g0.fsf@intel.com> <CAD=FV=W+Pcr+voBkcfeE_UC+ukN_hLXgoqMk0watROWRXe_2dg@mail.gmail.com>
 <8734r85tcf.fsf@intel.com>
In-Reply-To: <8734r85tcf.fsf@intel.com>
From: Doug Anderson <dianders@chromium.org>
Date: Fri, 26 Apr 2024 08:28:30 -0700
Message-ID: <CAD=FV=XNbRauayNFNOODm-aaaLy2_vJk8OW-mR_XmLv505RtGA@mail.gmail.com>
Subject: Re: [PATCH] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org, 
	Javier Martinez Canillas <javierm@redhat.com>, Neil Armstrong <neil.armstrong@linaro.org>, 
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, linus.walleij@linaro.org, 
	Cong Yang <yangcong5@huaqin.corp-partner.google.com>, 
	lvzhaoxiong@huaqin.corp-partner.google.com, Hsin-Yi Wang <hsinyi@google.com>, 
	Sam Ravnborg <sam@ravnborg.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>, 
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, 
	Thomas Zimmermann <tzimmermann@suse.de>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Apr 26, 2024 at 3:09=E2=80=AFAM Jani Nikula <jani.nikula@linux.inte=
l.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 =3D 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 =3D 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 =3D {
>                 .dsi =3D 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