Re: [PATCH 2/6] dma-resv: Define guards for context-less dma_resv locks

["Christian König" <christian.koenig@amd.com>]

On 5/18/26 16:15, Boris Brezillon wrote:
> On Mon, 18 May 2026 14:18:41 +0200
> Christian König <christian.koenig@amd.com> wrote:
> 
>> On 5/18/26 11:14, Boris Brezillon wrote:
>>> Hi Christian,
>>>
>>> On Mon, 18 May 2026 09:10:23 +0200
>>> Christian König <christian.koenig@amd.com> wrote:
>>>   
>>>> On 5/13/26 18:58, Boris Brezillon wrote:  
>>>>> When used without a context, dma_resv are no different from regular
>>>>> locks. Define guards so we can use the guard-syntactic sugars for
>>>>> explicit/implicit scoped locks.
>>>>>
>>>>> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>    
>>>>
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>>
>>>> How do you want to upstream it? My preference would be drm-misc-next, but I think I can live with a panthor specific branch as well.  
>>>
>>> Everything Panthor related goes through drm-misc-next, so drm-misc-next
>>> also has my preference ;-). But I'd like to wait for more feedback on
>>> the other drm patches, and there are a few things I need to address in
>>> the panthor patches anyway, so it's likely to take a couple more weeks
>>> for this series to hit the drm-misc tree, unless you have a good reason
>>> to fast-track this specific patch.  
>>
>> Well the DMA-buf code itself uses dma_resv_lock/unlock
> 
> There's no use in dma-resv.c that can be converted to guards. I gave
> dma-buf.c a try, but just like for panthor, I don't really like the fact
> it's halfway through (other locks still use manual locking), so I'd be
> tempted to convert everything at once for consistency. If you're fine
> with that, I can give this a try.

Well depends on what everything means. I would only convert dma-buf.c in one patch and nothing else.

>> and obviously has test cases for all the different variants.
> 
> Looks like the test cases all validate that dma_resv_lock(x, NULL)
> returns 0. If I were to convert those to guard(dma_resv)(), these checks
> would be gone. Is that okay with you?

Ah, good point. No we need to check the return value here.

So keep the test cases as they are, they basically make sure that we can actually use the guards when there is no ticket.

Thanks,
Christian.