[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5a5c0bcfecb96ea740337785623ed78a1591622.camel@maquefel.me>
Date: Thu, 29 Jun 2023 19:10:33 +0300
From: Nikita Shubin <nikita.shubin@...uefel.me>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Alexander Sverdlin <alexander.sverdlin@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Linus Walleij <linus.walleij@...aro.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Michael Peters <mpeters@...eddedts.com>,
Kris Bahnsen <kris@...eddedts.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 09/43] clocksource: ep93xx: Add driver for Cirrus
Logic EP93xx
Hello Andy!
On Wed, 2023-06-21 at 11:28 +0300, Andy Shevchenko wrote:
> On Wed, Jun 21, 2023 at 11:22 AM Nikita Shubin
> <nikita.shubin@...uefel.me> wrote:
>
> ...
>
> > > > + irq = irq_of_parse_and_map(np, 0);
> > > > + if (irq <= 0) {
> > > > + pr_err("ERROR: invalid interrupt number\n");
> > > > + ret = -EINVAL;
> > >
> > > Shadowed error in case of negative returned code. Why?
> >
> > Majority of clocksource drivers shadow it. Same like above.
>
> It doesn't mean they are correct or using brand new APIs.
Or may be this because irq_of_parse_and_map can return zero as error,
and returning zero from timer_init means success ?
Please correct me if i am wrong here.
>
> Can you use fwnode_irq_get() instead?
Will it help ?
>From docs:
* Return: Linux IRQ number on success. Other values are determined
* according to acpi_irq_get() or of_irq_get() operation.
* of_irq_get()
* Return: Linux IRQ number on success, or 0 on the IRQ mapping failure
> The shadowing is most likely due to nasty =0 comparison.
Indeed.
>
> Also that ERROR is a bit weird, pr_err() is already on error level.
>
Completely agree.
Powered by blists - more mailing lists