On Fri, 29 Nov 2019 14:38:50 +0000
Steven Price <steven.price@xxxxxxx> wrote:
> On 29/11/2019 14:31, Boris Brezillon wrote:
> > On Fri, 29 Nov 2019 14:19:50 +0000
> > Steven Price <steven.price@xxxxxxx> 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@xxxxxxxxxxxxxxx>
> >>> Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>
> >>
> >> 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@xxxxxxxxxxxxxxx> # 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
