Received-SPF: pass (google.com: domain of linux-kernel+bounces-10070-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20231220235459.2965548-1-markhas@chromium.org>
 <20231220165423.v2.21.Ife9ebad2bbfbab3a05e90040f344d750aa0aac7e@changeid> <ZYRawMwhtimA-rkD@smile.fi.intel.com>
In-Reply-To: <ZYRawMwhtimA-rkD@smile.fi.intel.com>
From: Mark Hasemeyer <markhas@chromium.org>
Date: Fri, 22 Dec 2023 14:51:32 -0700
Message-ID: <CANg-bXA+kboBGVwqQrW+7zPGgwCwd-cTbnjy4213Lf4pKWpdLA@mail.gmail.com>
Subject: Re: [PATCH v2 21/22] platform: Modify platform_get_irq_optional() to
 use resource
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, 
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Tzung-Bi Shih <tzungbi@kernel.org>, 
	Raul Rangel <rrangel@chromium.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, 
	Rob Herring <robh@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>, David Gow <davidgow@google.com>, 
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mark Brown <broonie@kernel.org>, 
	"Rafael J. Wysocki" <rafael@kernel.org>, Takashi Iwai <tiwai@suse.de>, 
	=?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= <u.kleine-koenig@pengutronix.de>
Content-Type: text/plain; charset="UTF-8"

> >   * For example::
> >   *
> > - *           int irq = platform_get_irq_optional(pdev, 0);
> > + *           int irq = platform_get_irq_resource_optional(pdev, 0, &res);
> >   *           if (irq < 0)
> >   *                   return irq;
> >   *
> >   * Return: non-zero IRQ number on success, negative error number on failure.
>
> Why do we need the irq to be returned via error code?

We don't really. It just matches the convention of
'platform_get_irq()' and 'of_irq_to_resource()'.

> >       int ret;
>
> Missing blank line, have you run checkpatch.pl?

Yes, I normally run checkpatch.pl. I may have missed the warning or it
didn't catch it. I'll add it.

>
> > +     if (IS_ERR_OR_NULL(r))
> > +             return -EINVAL;
>
> If we ever have an error pointer in r, I prefer to see
>
>         if (!r)
>                 return -EINVAL;
>         if (IS_ERR(r))
>                 return PTR_ERR(r);
>
> But Q is the same as earlier: when would we have the error pointer in @r?

I don't see when we would. I'll drop it.

> Can we save this and be consistent with above fwnode API return code check?
>
> > +                     ret = ret ?: r->start;
> >                       goto out;
> > +             }
> >       }

Yep!