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=WxYoFYefdZ4PQ=QF5aHpeWoC3qM1b5d2vf_qBH90ZMQw@mail.gmail.com>
Date: Fri, 26 Apr 2024 08:35:24 -0700
From: Doug Anderson <dianders@...omium.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>, dri-devel@...ts.freedesktop.org, 
	Javier Martinez Canillas <javierm@...hat.com>, Neil Armstrong <neil.armstrong@...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 Thu, Apr 25, 2024 at 8:03 PM Dmitry Baryshkov
<dmitry.baryshkov@...aro.org> wrote:
>
> On Thu, Apr 25, 2024 at 10:04:49AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 25, 2024 at 1:19 AM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> > >
> > > > @@ -279,6 +281,8 @@ enum mipi_dsi_dcs_tear_mode {
> > > >
> > > >  ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi,
> > > >                                 const void *data, size_t len);
> > > > +ssize_t mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi,
> > > > +                                      const void *data, size_t len);
> > > >  ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd,
> > > >                          const void *data, size_t len);
> > > >  ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
> > > > @@ -317,14 +321,10 @@ int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi,
> > > >  #define mipi_dsi_generic_write_seq(dsi, seq...)                                \
> > > >       do {                                                                   \
> > > >               static const u8 d[] = { seq };                                 \
> > > > -             struct device *dev = &dsi->dev;                                \
> > > >               int ret;                                                       \
> > > > -             ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));           \
> > > > -             if (ret < 0) {                                                 \
> > > > -                     dev_err_ratelimited(dev, "transmit data failed: %d\n", \
> > > > -                                         ret);                              \
> > > > +             ret = mipi_dsi_generic_write_chatty(dsi, d, ARRAY_SIZE(d));    \
> > > > +             if (ret < 0)                                                   \
> > > >                       return ret;                                            \
> > > > -             }                                                              \
> > > >       } while (0)
>
>
> Reading the thread makes me wonder whether we should be going into
> slightly other direction:
>
> Add __must_check() to mipi_dsi_ writing functions,
>
> #define mipi_dsi_dcs_whatever_write(dsi, cmd, seq...)   \
>         ({                                              \
>                 static const u8 d[] = { cmd, seq };     \
>                 mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d));    \
>         })
>
> Then in panel drivers we actually have to explicitly handle the return
> code (either by dropping to the error label or by just returning an
> error).

Given the sheer number of init commands needed by some panels (see
j606f_boe_init_sequence() for instance) I'm still convinced that we
want something that allows people to write their init code in a way
that's not quite so verbose. It sounds as if Jani is OK w/ the
proposal of using the "accumulated return value" (proposal #2 I had).
I'm hoping you're OK w/ that too...

-Doug