Received-SPF: pass (google.com: domain of linux-kernel+bounces-25472-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Sun, 14 Jan 2024 16:04:19 +0200
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Mark Hasemeyer <markhas@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Raul Rangel <rrangel@chromium.org>,
	Tzung-Bi Shih <tzungbi@kernel.org>, 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>,
	Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH v4 23/24] platform: Modify platform_get_irq_optional() to
 use resource
Message-ID: <ZaPp4yVQ44J7HJB2@smile.fi.intel.com>
References: <20240102210820.2604667-1-markhas@chromium.org>
 <20240102140734.v4.23.Ife9ebad2bbfbab3a05e90040f344d750aa0aac7e@changeid>
 <ZZlp_YszbYTUFC1u@smile.fi.intel.com>
 <CANg-bXA1thAjWDeaJs8aO-SmTkgcjx8Cw0nWUHt+CGyCrB5tLA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANg-bXA1thAjWDeaJs8aO-SmTkgcjx8Cw0nWUHt+CGyCrB5tLA@mail.gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Mon, Jan 08, 2024 at 12:09:10PM -0700, Mark Hasemeyer wrote:
> On Sat, Jan 6, 2024 at 7:56 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Tue, Jan 02, 2024 at 02:07:47PM -0700, Mark Hasemeyer wrote:

..

> > > +     ret = fwnode_irq_get_resource(fwnode, num, r);
> >
> > I still prefer this not to return positive value. Since you _require_ @r to be
> > not NULL, i.e. valid, the returning positive value makes no sense.
> >
> > > +     ret = ret < 0 ? ret : 0;
> > > +     if (!ret || ret == -EPROBE_DEFER)
> > > +             goto out;
> 
> I agree. But echoing my response from v3 patch 24:
> - The fwnode patch is already reviewed and approved.
> - The fwnode patch uses of_irq_to_resource() which already existed and
> returns the irq number on success. The error handling translation will
> just get pushed to the fwnode subsystem unless of_irq_to_resource() is
> also modified which means updating 8 or so drivers that reference it.
> 
> I can either:
> -Leave it
> -Modify the fwnode subsystem to perform the error translation of
> of_irq_to_resource()
> -Modify the fwnode and OF subsystems and update all driver references
> 
> The fwnode and OF patches are already reviewed. I imagine coding
> changes would imply dropping any Reviewed-by tags and requesting
> another review?
> I'd really prefer to not blow up the patch series anymore, but if you
> feel strongly, we can come up with a solution.

fwnode is quite generic API and I won't fail it from day 1.
Yet we have already some deviations in fwnode/device vs. OF/ACPI cases
(first comes to mind is device_for_each_child_node() which assumes
 "availability").

So, I would prefer fwnode API to not inherit issues/features of OF specific
code. Maybe this can be considered as "yes, please update it".

-- 
With Best Regards,
Andy Shevchenko