All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: "linux-acpi" <linux-acpi@intel.com>,
	"Mikael Pettersson" <mikpe@it.uu.se>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] avoid compiler warnings
Date: Wed, 15 Nov 2006 16:47:59 +0000	[thread overview]
Message-ID: <455B52CF.76E4.0078.0@novell.com> (raw)
In-Reply-To: <17755.13665.576585.82545@alkaid.it.uu.se>

>>Pointers should not be casted to u32 as this results in compiler warnings
>>on 64-bit platforms.
>
>NAK. Use "%p" for formatting pointers. No casts needed.

Indeed, how did I not see this... While at this, I saw that there were a few
more instances that needed fixing (they weren't actively generating warnings
because of the build settings).

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- linux-2.6.19-rc5/drivers/acpi/executer/exmutex.c	2006-09-20 05:42:06.000000000 +0200
+++ 2.6.19-rc5-acpi-warnings/drivers/acpi/executer/exmutex.c	2006-11-15 17:22:39.000000000 +0100
@@ -266,10 +266,10 @@ acpi_ex_release_mutex(union acpi_operand
 	     walk_state->thread->thread_id)
 	    && (obj_desc->mutex.os_mutex != ACPI_GLOBAL_LOCK)) {
 		ACPI_ERROR((AE_INFO,
-			    "Thread %X cannot release Mutex [%4.4s] acquired by thread %X",
-			    (u32) walk_state->thread->thread_id,
+			    "Thread %p cannot release Mutex [%4.4s] acquired by thread %p",
+			    walk_state->thread->thread_id,
 			    acpi_ut_get_node_name(obj_desc->mutex.node),
-			    (u32) obj_desc->mutex.owner_thread->thread_id));
+			    obj_desc->mutex.owner_thread->thread_id));
 		return_ACPI_STATUS(AE_AML_NOT_OWNER);
 	}
 
--- linux-2.6.19-rc5/drivers/acpi/utilities/utmutex.c	2006-09-20 05:42:06.000000000 +0200
+++ 2.6.19-rc5-acpi-warnings/drivers/acpi/utilities/utmutex.c	2006-11-15 17:24:31.000000000 +0100
@@ -222,7 +222,7 @@ acpi_status acpi_ut_acquire_mutex(acpi_m
 			if (acpi_gbl_mutex_info[i].thread_id == this_thread_id) {
 				if (i == mutex_id) {
 					ACPI_ERROR((AE_INFO,
-						    "Mutex [%s] already acquired by this thread [%X]",
+						    "Mutex [%s] already acquired by this thread [%p]",
 						    acpi_ut_get_mutex_name
 						    (mutex_id),
 						    this_thread_id));
@@ -231,7 +231,7 @@ acpi_status acpi_ut_acquire_mutex(acpi_m
 				}
 
 				ACPI_ERROR((AE_INFO,
-					    "Invalid acquire order: Thread %X owns [%s], wants [%s]",
+					    "Invalid acquire order: Thread %p owns [%s], wants [%s]",
 					    this_thread_id,
 					    acpi_ut_get_mutex_name(i),
 					    acpi_ut_get_mutex_name(mutex_id)));
@@ -243,23 +243,23 @@ acpi_status acpi_ut_acquire_mutex(acpi_m
 #endif
 
 	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-			  "Thread %X attempting to acquire Mutex [%s]\n",
-			  (u32) this_thread_id, acpi_ut_get_mutex_name(mutex_id)));
+			  "Thread %p attempting to acquire Mutex [%s]\n",
+			  this_thread_id, acpi_ut_get_mutex_name(mutex_id)));
 
 	status = acpi_os_acquire_mutex(acpi_gbl_mutex_info[mutex_id].mutex,
 				       ACPI_WAIT_FOREVER);
 	if (ACPI_SUCCESS(status)) {
 		ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-				  "Thread %X acquired Mutex [%s]\n",
-				  (u32) this_thread_id,
+				  "Thread %p acquired Mutex [%s]\n",
+				  this_thread_id,
 				  acpi_ut_get_mutex_name(mutex_id)));
 
 		acpi_gbl_mutex_info[mutex_id].use_count++;
 		acpi_gbl_mutex_info[mutex_id].thread_id = this_thread_id;
 	} else {
 		ACPI_EXCEPTION((AE_INFO, status,
-				"Thread %X could not acquire Mutex [%X]",
-				(u32) this_thread_id, mutex_id));
+				"Thread %p could not acquire Mutex [%X]",
+				this_thread_id, mutex_id));
 	}
 
 	return (status);
@@ -285,7 +285,7 @@ acpi_status acpi_ut_release_mutex(acpi_m
 
 	this_thread_id = acpi_os_get_thread_id();
 	ACPI_DEBUG_PRINT((ACPI_DB_MUTEX,
-			  "Thread %X releasing Mutex [%s]\n", (u32) this_thread_id,
+			  "Thread %p releasing Mutex [%s]\n", this_thread_id,
 			  acpi_ut_get_mutex_name(mutex_id)));
 
 	if (mutex_id > ACPI_MAX_MUTEX) {



  reply	other threads:[~2006-11-15 16:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-15 14:48 [PATCH] avoid compiler warnings Jan Beulich
2006-11-15 15:42 ` Mikael Pettersson
2006-11-15 16:47   ` Jan Beulich [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-11-16 12:38 Mikael Pettersson

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=455B52CF.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=linux-acpi@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.