Turns out there's many good reasons for this!

Lyude Paul (5):
  Revert "nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage"
  Revert "nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation"
  Revert "nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)"
  Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd"
  Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions"

 drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h      |  8 ++++----
 .../gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/alloc.c    |  4 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/bar.c  |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/ctrl.c |  2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c  | 10 +++++-----
 5 files changed, 13 insertions(+), 13 deletions(-)


base-commit: 61de054a772a1feda6364931ab1baf9038abf1c8
-- 
2.54.0

On Thu, 28 May 2026 15:27:14 -0400, Lyude Paul wrote:
> [PATCH 0/5] Revert cleanups for IS_ERR_OR_NULL() usage

Applied, thanks!

  Branch: drm-misc-next-fixes
  Tree:   https://gitlab.freedesktop.org/drm/misc/kernel.git

[1/5] Revert "nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage"
      commit: ebddb00faa82
[2/5] Revert "nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation"
      commit: 1a8117455d0d
[3/5] Revert "nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)"
      commit: dd516da348f1
[4/5] Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd"
      commit: 80fa10569b90
[5/5] Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions"
      commit: 18178f2ac176

The patches will appear in the next linux-next integration (typically within 24
hours on weekdays).

The patches are queued up for the upcoming merge window for the next major
kernel release.

On Thu, 2026-05-28 at 15:27 -0400, Lyude Paul wrote:
> Turns out there's many good reasons for this!
> 
> Lyude Paul (5):
>   Revert "nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage"
>   Revert "nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation"
>   Revert "nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)"
>   Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd"
>   Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions"

Reviewed-by: Timur Tabi <ttabi@nvidia.com>

On Thu May 28, 2026 at 9:27 PM CEST, Lyude Paul wrote:
> Lyude Paul (5):
>   Revert "nouveau/gsp/rm: cleanup remaining IS_ERR_OR_NULL usage"
>   Revert "nouveau/gsp/rm: cleanup IS_ERR_OR_NULL in core implementation"
>   Revert "nouveau/gsp/rm: cleanup WARN_ON(IS_ERR_OR_NULL)"
>   Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rpc_rd"
>   Revert "nouveau/gsp: cleanup IS_ERR_OR_NULL in rm_alloc functions"

Reverting the whole thing for now is the right call, as it needs some more
review.

@Timur: I do think cleaning this up is the right call in general though, and I
also don't think that the whole driver necessarily needs to be consistent on
whether IS_ERR_OR_NULL() or IS_ERR() is used -- it depends on the context
(although I usually prefer not to mix up NULL and ERR semantics in the first
place).

It should however be consistent in terms of what functions can actually return.

	ret = foo();
	if (IS_ERR_OR_NULL(ret))
		return ret;

If foo() can never return NULL, the above is misleading, as it puts an
obligation on the caller to somehow handle the NULL case and come up with an
actual error code for it.

So, I think it is the right call to align that to what functions can actually
return, but while doing this, the contract should be properly documented, such
that subsequent changes can be properly validated.

I can pick this up later, but in case you want to pick it up Lyude, note that
this now has to go into drm-misc-next-fixes.

Thanks,
Danilo

On Thu, 2026-05-28 at 21:44 +0200, Danilo Krummrich wrote:
> 
> @Timur: I do think cleaning this up is the right call in general though, and I
> also don't think that the whole driver necessarily needs to be consistent on
> whether IS_ERR_OR_NULL() or IS_ERR() is used -- it depends on the context
> (although I usually prefer not to mix up NULL and ERR semantics in the first
> place).
> 
> It should however be consistent in terms of what functions can actually return.
> 
> 	ret = foo();
> 	if (IS_ERR_OR_NULL(ret))
> 		return ret;
> 
> If foo() can never return NULL, the above is misleading, as it puts an
> obligation on the caller to somehow handle the NULL case and come up with an
> actual error code for it.

Sure, I get that.  My point is that it's often not clear whether foo() actually can never return
NULL.  

It's been a while since I've dug through the RPC call chains in Nouveau, so my memory is a little
hazy here.  I do remember noticing that Nouveau frequently has situations where foo() call bar1()
and bar2(), where bar1() can return NULL but bar2() can't.  So the question is not whether foo() can
return NULL, it's whether bar1() should not return NULL, or whether bar2() should.

> So, I think it is the right call to align that to what functions can actually
> return, but while doing this, the contract should be properly documented, such
> that subsequent changes can be properly validated.

"Properly documented" and "Nouveau" are not two things that go together.  

On Thu May 28, 2026 at 10:23 PM CEST, Timur Tabi wrote:
> On Thu, 2026-05-28 at 21:44 +0200, Danilo Krummrich wrote:
>> 
>> @Timur: I do think cleaning this up is the right call in general though, and I
>> also don't think that the whole driver necessarily needs to be consistent on
>> whether IS_ERR_OR_NULL() or IS_ERR() is used -- it depends on the context
>> (although I usually prefer not to mix up NULL and ERR semantics in the first
>> place).
>> 
>> It should however be consistent in terms of what functions can actually return.
>> 
>> 	ret = foo();
>> 	if (IS_ERR_OR_NULL(ret))
>> 		return ret;
>> 
>> If foo() can never return NULL, the above is misleading, as it puts an
>> obligation on the caller to somehow handle the NULL case and come up with an
>> actual error code for it.
>
> Sure, I get that.  My point is that it's often not clear whether foo() actually can never return
> NULL.  
>
> It's been a while since I've dug through the RPC call chains in Nouveau, so my memory is a little
> hazy here.  I do remember noticing that Nouveau frequently has situations where foo() call bar1()
> and bar2(), where bar1() can return NULL but bar2() can't.  So the question is not whether foo() can
> return NULL, it's whether bar1() should not return NULL, or whether bar2() should.

If there are multiple, it has to be the superset of course.

>> So, I think it is the right call to align that to what functions can actually
>> return, but while doing this, the contract should be properly documented, such
>> that subsequent changes can be properly validated.
>
> "Properly documented" and "Nouveau" are not two things that go together.

Unfortunately -- but the changes submitted by Hongling can add the documentation
for the places that are touched.

@Hongling, can you consider this in a v2 please?

Thanks,
Danilo

On Thu, 2026-05-28 at 21:44 +0200, Danilo Krummrich wrote:
> 
> I can pick this up later, but in case you want to pick it up Lyude,
> note that
> this now has to go into drm-misc-next-fixes.

Whatever works for you and is easier, I also didn't realize we'd hit
rc6 yet