linux-kernel - RE: [PATCH 08/10] staging/xgifb: Remove unnecessary bitshifts in XGI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ADE657CA350FB648AAC2C43247A983F00207D12B89AA@AUSP01VMBX24.collaborationhost.net>
Date:	Mon, 4 Feb 2013 12:25:44 -0600
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Dan Carpenter <dan.carpenter@...cle.com>,
	Peter Huewe <peterhuewe@....de>
CC:	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnaud Patard <arnaud.patard@...-net.org>,
	Aaro Koskinen <aaro.koskinen@....fi>
Subject: RE: [PATCH 08/10] staging/xgifb: Remove unnecessary bitshifts in
 XGI_SetCRT1ModeRegs

On Monday, February 04, 2013 5:59 AM, Dan Carpenter wrote:
> On Sun, Feb 03, 2013 at 10:54:37PM +0100, Peter Huewe wrote:
>> Since data can only be 0x0000, 0x0035 or 0x0048 we can simply skip the
>> bit shifting and masking as data & 0xFF is always equal to data and
>> data & 0xFF00 is always 0.
>> So we simply use data and 0 directly and save the assignment.
>> 
>> Signed-off-by: Peter Huewe <peterhuewe@....de>
>> ---
>>  drivers/staging/xgifb/vb_setmode.c |    6 ++----
>>  1 files changed, 2 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/staging/xgifb/vb_setmode.c b/drivers/staging/xgifb/vb_setmode.c
>> index 6f366f4..1ff1178 100644
>> --- a/drivers/staging/xgifb/vb_setmode.c
>> +++ b/drivers/staging/xgifb/vb_setmode.c
>> @@ -1083,10 +1083,8 @@ static void XGI_SetCRT1ModeRegs(struct xgi_hw_device_info *HwDeviceExtension,
>>  			data = 0x0048;
>>  	}
>>  
>> -	data2 = data & 0x00FF;
>> -	xgifb_reg_and_or(pVBInfo->P3d4, 0x19, 0xFF, data2);
>> -	data2 = (data & 0xFF00) >> 8;
>> -	xgifb_reg_and_or(pVBInfo->P3d4, 0x19, 0xFC, data2);
>> +	xgifb_reg_and_or(pVBInfo->P3d4, 0x19, 0xFF, data);
>> +	xgifb_reg_and_or(pVBInfo->P3d4, 0x19, 0xFC, 0);
>
> This patch is fine.
>
> This is a fairly common pattern where people do:
>
>	write_a_char(data & 0xff);
>	write_a_char((data >> 8) & 0xff);
>
> It feels there should be a macro to do the shift and mask but I'm
> not sure what it would look like.

How about...

#define LOBYTE(x)	((x) & 0xff)
#define HIBYTE(x)	(((x) >> 8) & 0xff)

And for completeness...

#define LOWORD	((x) & 0xffff)
#define HIWORD	(((x) >> 16) & 0xffff)

There are a couple uses of these defines in the kernel already.
sound/synth/emux/emux_synth.c also has LO_BYTE and HI_BYTE
that do the same thing.

Of course these are probably not endian safe.

Regards,
Hartley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/