Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu)

[Alex Deucher]

On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel <pmenzel at molgen.mpg.de> wrote:
>
> Dear Christian,
>
>
> Am 05.04.22 um 08:54 schrieb Christian König:
> > Am 05.04.22 um 08:45 schrieb Paul Menzel:
>
> >> Am 04.04.22 um 23:42 schrieb Philip Yang:
> >>> bo_adev is NULL for system memory mapping to GPU.
> >>>
> >>> Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)
> >>
> >> Sorry, where can I find that commit?
> >
> > Well that's expected, the development branch is not public.
>
> Well obviously, it was unexpected for me. How should I have known? Where
> is that documented? If the patches are publicly posted to the mailing
> list, why is that development branch not public?
>
> The current situation is really frustrating for non-AMD employees. How
> can the current situation be improved?

Our development branch
(https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next)
is available publicly.  There can be a day or so of lag depending on
when it gets mirrored (e.g., over the weekend).

Alex

>
>
> Kind regards,
>
> Paul
>
>
> >> I do not see it in drm-next from agd5f git archive
> >> git at gitlab.freedesktop.org:agd5f/linux.git.
> >>
> >>     $ git log --oneline -1
> >>     e45422695c19 (HEAD, agd5f/drm-next) drm/amdkfd: Create file
> >> descriptor after client is added to smi_clients list
> >>
> >>
> >> Kind regards,
> >>
> >> Paul
> >>
> >>
> >>> Signed-off-by: Philip Yang <Philip.Yang at amd.com>
> >>> ---
> >>>   drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> index 907b02045824..d3fb2d0b5a25 100644
> >>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> @@ -1281,7 +1281,7 @@ svm_range_map_to_gpu(struct kfd_process_device
> >>> *pdd, struct svm_range *prange,
> >>>                          last_start, prange->start + i,
> >>>                          pte_flags,
> >>>                          last_start - prange->start,
> >>> -                       bo_adev->vm_manager.vram_base_offset,
> >>> +                       bo_adev ?
> >>> bo_adev->vm_manager.vram_base_offset : 0,
> >>>                          NULL, dma_addr, &vm->last_update);
> >>>             for (j = last_start - prange->start; j <= i; j++)