linux-kernel - Re: [PATCH] media: c8sectpfe: convert to gpio descriptors

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: <CAKdAkRRA7XATxHBALDf8Pd2SWQX_OPAYgCQmtJi5H1so_EJ7VA@mail.gmail.com>
Date:   Fri, 3 Feb 2023 15:10:55 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Arnd Bergmann <arnd@...nel.org>,
        Patrice Chotard <patrice.chotard@...s.st.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Hugues Fruchet <hugues.fruchet@...com>,
        linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: c8sectpfe: convert to gpio descriptors

On Mon, Jan 30, 2023 at 10:19 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Jan 30, 2023, at 18:18, Andy Shevchenko wrote:
> > On Mon, Jan 30, 2023 at 02:09:47PM +0100, Arnd Bergmann wrote:
>
> >> +            ret = PTR_ERR_OR_ZERO(tsin->rst_gpio);
> >>              if (ret && ret != -EBUSY) {
> >> -                    dev_err(dev, "Can't request tsin%d reset gpio\n"
> >> -                            , fei->channel_data[index]->tsin_id);
> >> +                    dev_err_probe(dev, ret,
> >> +                                  "reset gpio for tsin%d not valid\n",
> >> +                                  tsin->tsin_id);
> >>                      goto err_node_put;
> >>              }
> >>
> >>              if (!ret) {
> >
> > Can be
> >
> >       if (IS_ERR() && PTR_ERR() != -EBUSY) {
> >               ret = dev_err_probe(dev, PTR_ERR(), ...);
> >               ...
> >       }
> >
> >       if (!IS_ERR())
> >
> > (Up to you)
>
> I prefer the version that only has one PTR_ERR(), but
> either way is fine with me.
>
> > But -EBUSY check seems strange to me. What was the motivation behind?
> > (As far as I can read the code the possibility to get this if and only
> >  if we have requested GPIO too early at initcall level. Would it be
> >  ever a possibility to get it in real life?)
>
> I noticed this part as being odd as well, no idea why the
> code is like this. I just left the logic unchanged here.

It could be they were trying to account for the possibility of the
reset line being shared between several blocks, and so the first one
to initialize would grab it and reset all chips, and the followers
would be skipping the reset logic.

-- 
Dmitry