From: vitaly prosyak <vprosyak@amd.com>
To: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Karthik B S <karthik.b.s@intel.com>,
igt-dev@lists.freedesktop.org,
Vitaly Prosyak <vitaly.prosyak@amd.com>
Subject: Re: [PATCH i-g-t] tests/amd/amd_fuzzing: Fix compilation error on fedora
Date: Thu, 2 Apr 2026 12:33:52 -0400 [thread overview]
Message-ID: <f0ea4825-af35-47fc-9578-d521988bc0f3@amd.com> (raw)
In-Reply-To: <20260402153634.2wzz6pdw4fmr66yk@kamilkon-DESK.igk.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]
Hi Kamil,
Thanks for pointing this out, including the checkpatch.pl angle.
I also found quite a few checkpatch/style warnings in this area, and I will send a cleanup patch for those formatting/style issues soon.
Thanks, Vitaly
On 2026-04-02 11:36, Kamil Konieczny wrote:
> Hi Karthik,
> On 2026-04-02 at 20:54:39 +0530, Karthik B S wrote:
>> Fix compilation error:
>>
>> ../tests/amdgpu/amd_fuzzing.c: In function ‘amd_kgd_multi_ioctl_field_fuzzing’:
>> ../tests/amdgpu/amd_fuzzing.c:1103:13: error: ‘have_amdgpu_dev’ undeclared (first use in this function); did you mean ‘amdgpu_dev’?
>> 1103 | if (have_amdgpu_dev) {
>> | ^~~~~~~~~~~~~~~
>> | amdgpu_dev
>>
>> Cc: Vitaly Prosyak <vitaly.prosyak@amd.com>
>> Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>
>> Fixes: d512e54bbace ("tests/amdgpu/amd_fuzzing: Remove unused variable")
>> Signed-off-by: Karthik B S <karthik.b.s@intel.com>
> LGTM
> Reviewed-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
>
> btw using
> bool b = (ptr != NULL);
> is strange and should be catched by checkpatch.pl. In this case just
> use 'ptr', no point in using helper var.'
You are right about |bool b = (ptr != NULL)| here — in this case the helper variable is unnecessary.
>
> This also shows that code inside ifdef/endif should be very minimal
> and all code should compile.
>
> Vitalyi, what about only placing one var per one ifdef? For example:
>
> #ifdef AMDGPU_USERQ_ENABLED
> bool amdgpu_userq_enabled = true;
> #else
> bool amdgpu_userq_enabled = false;
> #endif
>
> and have you code always compile?
For the broader #ifdef point, I agree in principle and will try to keep those blocks minimal, but in amd_fuzzing.c some USERQ paths still need to stay under #ifdef AMDGPU_USERQ_ENABLED because they use USERQ-specific types/ioctls.
>
> Regards,
> Kamil
>
>> ---
>> tests/amdgpu/amd_fuzzing.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/amdgpu/amd_fuzzing.c b/tests/amdgpu/amd_fuzzing.c
>> index 00717e593..9d7468ea4 100644
>> --- a/tests/amdgpu/amd_fuzzing.c
>> +++ b/tests/amdgpu/amd_fuzzing.c
>> @@ -1100,7 +1100,7 @@ amd_kgd_multi_ioctl_field_fuzzing(int fd, amdgpu_device_handle amdgpu_dev)
>> * Note: USERQ_WAIT has no timeout field; it is not a blocking wait.
>> * It only registers the dependency. We therefore only test ret==0.
>> */
>> - if (have_amdgpu_dev) {
>> + if (amdgpu_dev) {
>> uint32_t timeline_handle = 0;
>> uint32_t timeline_handles[1];
>> uint64_t timeline_points[1];
>> @@ -1142,7 +1142,7 @@ amd_kgd_multi_ioctl_field_fuzzing(int fd, amdgpu_device_handle amdgpu_dev)
>> * Note: USERQ_WAIT has no timeout field and is not a blocking call; it
>> * only registers a dependency. We therefore only verify ret==0 here.
>> */
>> - if (have_amdgpu_dev) {
>> + if (amdgpu_dev) {
>> uint32_t timeline_handles[2] = { 0, 0 };
>> uint64_t signal_points[2] = { 8, 8 };
>> uint64_t wait_points[2] = { 8, 8 }; /* both already signaled */
>> --
>> 2.43.0
>>
[-- Attachment #2: Type: text/html, Size: 4334 bytes --]
prev parent reply other threads:[~2026-04-02 16:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 15:24 [PATCH i-g-t] tests/amd/amd_fuzzing: Fix compilation error on fedora Karthik B S
2026-04-02 15:36 ` Kamil Konieczny
2026-04-02 16:33 ` vitaly prosyak [this message]
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=f0ea4825-af35-47fc-9578-d521988bc0f3@amd.com \
--to=vprosyak@amd.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=karthik.b.s@intel.com \
--cc=vitaly.prosyak@amd.com \
/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