[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87cyy6mgrw.fsf@intel.com>
Date: Mon, 25 Sep 2023 18:09:07 +0300
From: Jani Nikula <jani.nikula@...ux.intel.com>
To: Randy Dunlap <rdunlap@...radead.org>,
Matthew Brost <matthew.brost@...el.com>,
"Dr. David Alan Gilbert" <dave@...blig.org>
Cc: krzysztof.kozlowski@...aro.org, airlied@...il.com,
mgreer@...malcreek.com, intel-gfx@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [Intel-gfx] ERR_PTR(0) in a couple of places
On Sun, 24 Sep 2023, Randy Dunlap <rdunlap@...radead.org> wrote:
> On 9/24/23 21:18, Matthew Brost wrote:
>> On Sun, Sep 24, 2023 at 12:41:07AM +0000, Dr. David Alan Gilbert wrote:
>>> Hi,
>>> I randomly noticed there are a couple of places in the kernel that
>>> do
>>> ERR_PTR(0);
>>>
>>> and thought that was odd - shouldn't those just be NULL's ?
>>>
>>> 1) i915
>>> drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c : 47
>>>
>>> if (i <= 1)
>>> return ERR_PTR(0);
>>
>> Yes, s/ERR_PTR(0)/ERR_PTR(NULL)/
>>
>> Matt
>
> I agree with Dave's original suggestion since casting NULL isn't needed.
Yeah, s/ERR_PTR(0)/NULL/ would be my choice as well.
As a side note, I generally think it's better not to mix NULL and error
pointers in error return values for a function, because they're harder
to handle properly.
BR,
Jani.
>
>>
>>>
>>> from f9d72092cb490
>>>
>>> 2) trf7970a
>>> drivers/nfc/trf7970a.c : 896
>>>
>>> trf->ignore_timeout =
>>> !cancel_delayed_work(&trf->timeout_work);
>>> trf->rx_skb = ERR_PTR(0);
>>> trf7970a_send_upstream(trf);
>>>
>>> from 1961843ceeca0
>>>
>>> Dave
>>> --
>>> -----Open up your eyes, open up your mind, open up your code -------
>>> / Dr. David Alan Gilbert | Running GNU/Linux | Happy \
>>> \ dave @ treblig.org | | In Hex /
>>> \ _________________________|_____ http://www.treblig.org |_______/
--
Jani Nikula, Intel
Powered by blists - more mailing lists