public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
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 --]

      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