From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Lee Jones <lee@kernel.org>
Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mfd: intel-lpss: Add missing check for platform_get_resource
Date: Mon, 27 Nov 2023 14:50:37 +0200 [thread overview]
Message-ID: <ZWSQnZfGKQ_0DaYJ@smile.fi.intel.com> (raw)
In-Reply-To: <20231127085356.GD1470173@google.com>
On Mon, Nov 27, 2023 at 08:53:56AM +0000, Lee Jones wrote:
> On Fri, 24 Nov 2023, Andy Shevchenko wrote:
> > On Fri, Jun 09, 2023 at 09:48:18AM +0800, Jiasheng Jiang wrote:
...
> > > Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
> >
> > This does not fix anything and just introduces a duplication code.
> > I would like this to be reverted. Should I send one?
>
> Checking this value at the source of obtention and providing and earlier
> return with arguably a better return value, all at the cost of an
> inexpensive pointer comparison to NULL doesn't sound like a terrible
> idea.
In general, I agree with you, but the cases similar to this. Why?
Because memory resource retrieval and remapping has a lot of helpers,
some of which are enriched with own error handling and messaging.
Yes, we use devm_ioremap_uc(), which doesn't give that (yet?).
However, it will be more work if we, theoretically, switch to
something like devm_ioremap_resource() in the future.
Hence, I would like to have a common code to be in common place
and behave in the same way independently on the glue druver (PCI,
ACPI, etc).
> If you were committed to the idea of removing it, which I suggest you
> reconsider, I would insist that you replace it with at least a comment.
Isn't what I have done in the series I sent last week?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-11-27 13:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 1:48 [PATCH v2] mfd: intel-lpss: Add missing check for platform_get_resource Jiasheng Jiang
2023-06-09 6:38 ` Lee Jones
2023-11-24 17:47 ` Andy Shevchenko
2023-11-27 8:53 ` Lee Jones
2023-11-27 12:50 ` Andy Shevchenko [this message]
2023-11-30 11:35 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZWSQnZfGKQ_0DaYJ@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=jiasheng@iscas.ac.cn \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox