[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70b61b75-c68b-ad89-5f6a-f1d681b9f5d0@samsung.com>
Date: Wed, 24 Jun 2020 21:39:57 +0200
From: Andrzej Hajda <a.hajda@...sung.com>
To: Robin Murphy <robin.murphy@....com>,
Mark Brown <broonie@...nel.org>
Cc: Jernej Skrabec <jernej.skrabec@...l.net>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jonas Karlman <jonas@...boo.se>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:DRM DRIVERS" <dri-devel@...ts.freedesktop.org>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Neil Armstrong <narmstrong@...libre.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [RESEND PATCH v5 3/5] drivers core: allow probe_err accept
integer and pointer types
On 24.06.2020 17:16, Robin Murphy wrote:
> On 2020-06-24 16:04, Mark Brown wrote:
>> On Wed, Jun 24, 2020 at 03:25:33PM +0100, Robin Murphy wrote:
>>
>>> And yeah, anyone who pipes up suggesting that places where an
>>> ERR_PTR value
>>> could be passed to probe_err() could simply refactor IS_ERR() checks
>>> with
>>> more uses of the god-awful PTR_ERR_OR_ZERO() obfuscator gets a long
>>> stare of
>>> disapproval...
>>
>> We could also have a probe_err_ptr() or something that took an ERR_PTR()
>> instead if there really were an issue with explicitly doing this.
>
> Yeah, for all my lyrical objection, a static inline <blah>_ptr_err()
> helper to wrap <blah>_err() with sensible type checking might actually
> be an OK compromise if people really feel strongly for having that
> utility.
I have proposed such thing in my previous iteration[1], except it was
macro because of variadic arguments.
With current version we save 8 chars and hacky macro, with the old
version we save only 4 chars and more clear construct - less tempting
solution for me.
Personally I prefer the current version - it does not seems to me more
dangerous than all these PTR_ERR, IS_ERR,ERR_PTR helpers, but can
prevent expression split across multiple lines due to 80char limit.
Probably the simplest solution is to drop this patch, I will do it then.
[1]:
https://lwn.net/ml/linux-kernel/20181220102247.4911-4-a.hajda@samsung.com/
Regards
Andrzej
>
> (and then we can debate whether it should also convert NULL to -ENOMEM
> and !IS_ERR to 0... :D)
>
> Robin.
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://protect2.fireeye.com/url?k=074420c0-5ada8e5a-0745ab8f-0cc47a336fae-bba8bb4caf96e14d&q=1&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel
>
>
Powered by blists - more mailing lists