Not bad.
On Fri, Feb 24, 2012 at 07:52:00PM +0800, Zhengwang Ruan wrote:
> There are some compiler warnings, this is to silence them.
When there are compiler warnings, cut and paste the compiler
warnings into the message here.
>
> Signed-off-by: Zhengwang Ruan <ruan.zhengwang@xxxxxxxxx>
> ---
> drivers/staging/android/binder.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
> index f0b7e66..c4e616c 100644
> --- a/drivers/staging/android/binder.c
> +++ b/drivers/staging/android/binder.c
> @@ -104,7 +104,7 @@ static uint32_t binder_debug_mask = BINDER_DEBUG_USER_ERROR |
> module_param_named(debug_mask, binder_debug_mask, uint, S_IWUSR | S_IRUGO);
>
> static int binder_debug_no_lock;
> -module_param_named(proc_no_lock, binder_debug_no_lock, bool, S_IWUSR | S_IRUGO);
> +module_param_named(proc_no_lock, binder_debug_no_lock, int, S_IWUSR | S_IRUGO);
Instead of doing this, it would be better to change the line before
and declare binder_debug_no_lock as a bool.
>
> static DECLARE_WAIT_QUEUE_HEAD(binder_user_error_wait);
> static int binder_stop_on_user_error;
> @@ -716,8 +716,8 @@ static struct binder_buffer *binder_alloc_buf(struct binder_proc *proc,
> size_t offsets_size, int is_async)
> {
> struct rb_node *n = proc->free_buffers.rb_node;
> - struct binder_buffer *buffer;
> - size_t buffer_size;
> + struct binder_buffer *buffer = NULL;
> + size_t buffer_size = 0;
The other option would be to use the uninitialized_var() macro. On
fast paths we would probably insist on that, but for this probably
no one cares.
When you fix uninitialized variable warnings, please comment in the
changelog whether the variable can ever be used uninitialized in
real life. (Is GCC correct?).
This should probably be split into two patches. One for the type
change and one for the uninitialized variables. We could probably
merge it as is, but definitely no one will complain if you split it
apart.
Use the ./scripts/get_maintainer.pl to find where to resend this
patch. Every kernel patch has to be CC'd to a mailing list. I
wouldn't CC lkml for this. They don't care about trivial patches
to staging. Just devel@xxxxxxxxxxxxxxxxxxxx is fine.
regards,
dan carpenter
Attachment:
signature.asc
Description: Digital signature
