Hi,
On Thu, Jun 10, 2021 at 4:01 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> On Fri, Jun 11, 2021 at 12:42 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> > On Thu, Jun 10, 2021 at 3:39 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
>
> > > #define mipi_dbi_command(dbi, cmd, seq...) \
> > > ({ \
> > > const u8 d[] = { seq }; \
> > > mipi_dbi_command_stackbuf(dbi, cmd, d, ARRAY_SIZE(d)); \
> > > })
> > >
> > > I'll fix up the include and apply then we can think about
> > > what to do with mipi_dbi_command().
> >
> > Are you sure that doesn't work? Isn't the return value of a macro the
> > last expression? In this case the return value of
> > mipi_dbi_command_stackbuf() should just flow through.
>
> w00t I didn't know that.
>
> And I like to think of the macro processor as essentially just
> inserting the content of the macro at the cursor.
>
> But arguably it *should* rather be fixed in this macro though?
> It is used in the same way in all other drivers as well.
You want the mipi_dbi_command() to do the error checking and print the
message? Two downsides:
1. What if someone didn't _want_ the message printed? They might want
to try to handle things more elegantly, like maybe fail the function?
2. Currently the mipi_dbi_command() macro doesn't have access to a
"dev" pointer so it wouldn't be able to print as nice of an error as
you can.
That being said, I wouldn't object to introducing a macro next to
mipi_dbi_command() that also takes a dev pointer, prints an error, and
doesn't return a value.
-Doug
