On Mon, Sep 20, 2021 at 11:30 AM Wolfram Sang
<wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote:
> thanks for the prompt review again!
You're welcome!
...
> > > + /* upper limit is arbitrary */
> >
> > Not really. I believe if the upper limit is > PAGE_SIZE, you would get
> > -ENOMEM with much higher chances. So, I think the comment should be
> > amended,
>
> ? Dunno, maybe it is not arbitrary that it is < PAGE_SIZE but other than
> that the value I chose is arbitrary. There is no technical reason for
> 2048.
I understand, but the comment is a bit misleading. My proposal is to
extend / amend the comment to point the upper-upper limit out. Perhaps
you need to rename "upper" for your case, or use a different word for
the PAGE_SIZE limit. Up to you.
> > > + if (count > 2048 || count & 1)
> > > + return -EINVAL;
...
> > > + if (ret < 0) {
> >
> > > + dev_err(dev, "error naming the GPIOs: %d\n", ret);
> > > + return ret;
> > > + }
> >
> > Perhaps
> >
> > return dev_err_probe() ?
>
> Reading strings from DT can be deferred? I don't think so.
There is a new development, i.e. the documentation for dev_err_probe()
is going to be amended to allow this. But I can't quickly find a patch
in mailing list with the related discussion.
> > And I think it might be split into two conditionals with
> > distinguishable error messages.
>
> I think "something is wrong with the names" is helpful enough for the
> user.
...
> > > + [ -n "$cur_cpu" ] && fail "CPU$isol_cpu requested but CPU$cur_cpu already isolated"
> >
> > For the sake of style (handle errors on the error) I would use
> >
> > [ -z "..." ] || fail ...
>
> I'll think about it. On first glimpse, this doesn't look more readable
> to me. "if this is true then do that" is super readable in my book. But
> yes, when calling external programs, I need '||' anyhow, true.
My point here, that in shell the usual pattern for error handling is
like '... || fail ...' And this is almost a regular style in your very
code.
--
With Best Regards,
Andy Shevchenko
