linux-kernel - Re: [PATCH v2 1/1] gpio: add sloppy logic analyzer using polling

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]

Date:   Mon, 20 Sep 2021 11:45:01 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] gpio: add sloppy logic analyzer using polling

On Mon, Sep 20, 2021 at 11:30 AM Wolfram Sang
<wsa+renesas@...g-engineering.com> 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