From: Danilo Krummrich <dakr@kernel.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: phasta@kernel.org, Lyude Paul <lyude@redhat.com>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Sumit Semwal <sumit.semwal@linaro.org>,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/nouveau: Don't signal when killing the fence context
Date: Thu, 22 May 2025 15:50:04 +0200 [thread overview]
Message-ID: <aC8rjBuqzst-SHMD@pollux> (raw)
In-Reply-To: <aac87a7e-5a45-4b54-a43b-cb92c5df669c@amd.com>
On Thu, May 22, 2025 at 03:05:02PM +0200, Christian König wrote:
> E.g. when you don't know the implementation side use the defined API and don't mess with the internals. If you do know the implementation side then it's valid that you check the internals.
I assume you meant this as "bothering with the internals of you *own* fence is
fine, but not with foreign ones".
And if the driver messes with the internals of its own fence code that's fine,
but in this case we talk about the generic dma_fence implementation, i.e. an
internal flag of the dma_fence implementation.
In general, a driver should *never* bother with implementation details of a
generic component, regardless whether the author knows the internal details.
Things are *always* prone to change and then this may result into subtle bugs.
next prev parent reply other threads:[~2025-05-22 13:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-22 11:25 [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled() Philipp Stanner
2025-05-22 11:25 ` [PATCH 2/2] drm/nouveau: Don't signal when killing the fence context Philipp Stanner
2025-05-22 12:06 ` Christian König
2025-05-22 12:20 ` Philipp Stanner
2025-05-22 12:34 ` Christian König
2025-05-22 12:42 ` Philipp Stanner
2025-05-22 13:05 ` Christian König
2025-05-22 13:50 ` Danilo Krummrich [this message]
2025-05-22 15:01 ` Christian König
2025-05-22 12:57 ` Tvrtko Ursulin
2025-05-22 13:15 ` Christian König
2025-05-22 12:59 ` Danilo Krummrich
2025-05-22 13:09 ` Christian König
2025-05-22 13:16 ` Philipp Stanner
2025-05-22 13:24 ` Christian König
2025-05-22 13:43 ` Philipp Stanner
2025-05-22 14:35 ` Christian König
2025-05-22 13:41 ` Danilo Krummrich
2025-05-23 14:47 ` [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled() Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aC8rjBuqzst-SHMD@pollux \
--to=dakr@kernel.org \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=phasta@kernel.org \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox