linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH] [media] ivtv-i2c: Fix two wanrings
Date: Thu, 30 Dec 2010 13:29:41 -0200	[thread overview]
Message-ID: <4D1CA565.4080204@redhat.com> (raw)
In-Reply-To: <201012301621.21746.hverkuil@xs4all.nl>

Em 30-12-2010 13:21, Hans Verkuil escreveu:
> On Thursday, December 30, 2010 16:00:41 Mauro Carvalho Chehab wrote:
>> Fix two gcc warnings:
>>
>> drivers/media/video/ivtv/ivtv-i2c.c:170: warning: cast from pointer to integer of different size
>> drivers/media/video/ivtv/ivtv-i2c.c:171: warning: cast from pointer to integer of different size
>> $ gcc --version
>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
>>
>> They seem bogus, but, as the original code also has problems with
>> LE/BE, just change its implementation to be clear.
> 
> Definitely not bogus:

Yes, it is not bogus.
> 
> unsigned char keybuf[4];
> 
> ..
> 
> *ir_key = (u32) keybuf;
> 
> Here keybuf == &keybuf[0]. So you put the address of keybuf in *ir_key. Which is
> indeed of a different size in the case of a 64-bit architecture.
> 
> What you probably meant to do is:
> 
> *ir_key = *(u32 *)keybuf;

Yes, but this would lead into BE/LE issues.
> 
> Note that the code in your patch assumes that keybuf is in big-endian order. I assume
> that's what it should be?

Based on the way lirc_i2c was printing the data, this seems to be the most coherent way.
We'll only know for sure after testing the remote with the hardware.

> 
> Regards,
> 
> 	Hans
> 
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>>
>> diff --git a/drivers/media/video/ivtv/ivtv-i2c.c b/drivers/media/video/ivtv/ivtv-i2c.c
>> index 2bed430..e103b8f 100644
>> --- a/drivers/media/video/ivtv/ivtv-i2c.c
>> +++ b/drivers/media/video/ivtv/ivtv-i2c.c
>> @@ -167,8 +167,8 @@ static int get_key_adaptec(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>>  	keybuf[2] &= 0x7f;
>>  	keybuf[3] |= 0x80;
>>  
>> -	*ir_key = (u32) keybuf;
>> -	*ir_raw = (u32) keybuf;
>> +	*ir_key = keybuf[3] | keybuf[2] << 8 | keybuf[1] << 16 |keybuf[0] << 24;
>> +	*ir_raw = *ir_key;
>>  
>>  	return 1;
>>  }
>>
> 


      reply	other threads:[~2010-12-30 15:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-30 15:00 [PATCH] [media] ivtv-i2c: Fix two wanrings Mauro Carvalho Chehab
2010-12-30 15:21 ` Hans Verkuil
2010-12-30 15:29   ` Mauro Carvalho Chehab [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=4D1CA565.4080204@redhat.com \
    --to=mchehab@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).