Re: [PATCH 1/8] drm/panfrost: Make panfrost_job_run() return an ERR_PTR() instead of NULL

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 29 Nov 2019 14:38:50 +0000
Steven Price <steven.price@arm.com> wrote:

> On 29/11/2019 14:31, Boris Brezillon wrote:
> > On Fri, 29 Nov 2019 14:19:50 +0000
> > Steven Price <steven.price@arm.com> wrote:
> >   
> >> On 29/11/2019 13:59, Boris Brezillon wrote:  
> >>> If we don't do that, dma_fence_set_error() complains (called from
> >>> drm_sched_main()).
> >>>
> >>> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> >>> Cc: <stable@vger.kernel.org>
> >>> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>    
> >>
> >> This might be worth doing, but actually it's not Panfrost that is broken
> >> it's the callers, see [1] and [2]. So I don't think we want the
> >> Fixes/stable tag.  
> > 
> > Okay.
> >   
> >>
> >> [1] https://patchwork.kernel.org/patch/11218399/
> >> [2] https://patchwork.kernel.org/patch/11267073/
> >>  
> >>> ---
> >>>  drivers/gpu/drm/panfrost/panfrost_job.c | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c
> >>> index 21f34d44aac2..cdd9448fbbdd 100644
> >>> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> >>> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> >>> @@ -328,13 +328,13 @@ static struct dma_fence *panfrost_job_run(struct drm_sched_job *sched_job)
> >>>  	struct dma_fence *fence = NULL;
> >>>  
> >>>  	if (unlikely(job->base.s_fence->finished.error))
> >>> -		return NULL;
> >>> +		return ERR_PTR(job->base.s_fence->finished.error);  
> > 
> > Hm, so we can keep the return NULL here if [1] is applied (the error
> > is preserved), but I'm not sure it's clearer that way.
> >   
> >>>  
> >>>  	pfdev->jobs[slot] = job;
> >>>  
> >>>  	fence = panfrost_fence_create(pfdev, slot);
> >>>  	if (IS_ERR(fence))
> >>> -		return NULL;
> >>> +		return ERR_PTR(-ENOMEM);    
> > 
> > This one should be fixed though, otherwise the error is never updated,
> > so I'm wondering if it doesn't deserve a Fixes tag in the end...  
> 
> Good point, although this can't be back-ported before [3] (well unless
> that commit is considered stable material too), so this is only really
> relevant for v5.4. But worth fixing there.

IIRc, such constraints can be specified with:

Cc: <stable@vger.kernel.org> # v5.4+

Anyway, I'll drop this patch from the series and repost a new version
once [1] has landed.

Thanks for the heads up.

Boris