linux-kernel - Re: [PATCH v2] mfd: intel-lpss: Add missing check for platform_get

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: <ZWSQnZfGKQ_0DaYJ@smile.fi.intel.com>
Date:   Mon, 27 Nov 2023 14:50:37 +0200
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     Lee Jones <lee@...nel.org>
Cc:     Jiasheng Jiang <jiasheng@...as.ac.cn>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mfd: intel-lpss: Add missing check for
 platform_get_resource

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