lkml.org 
[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/4] atl1: Header files for Attansic L1 driver
Jan Engelhardt wrote:
> On Nov 19 2006 14:30, Jay Cliburn wrote:
>> +
>> +#define LBYTESWAP( a ) ( ( ( (a) & 0x00ff00ff ) << 8 ) | ( ( (a) & 0xff00ff00 ) >> 8 ) )
>> +#define LONGSWAP( a ) ( ( LBYTESWAP( a ) << 16 ) | ( LBYTESWAP( a ) >> 16 ) )
>> +#define SHORTSWAP( a ) ( ( (a) << 8 ) | ( (a) >> 8 ) )
>
> Please use swab16/swab32 for these.

Thanks for pointing this out. There's a lot of self-rolled stuff in the
vendor driver, and we haven't removed it all yet. That one should be
easy though.

>> +#define AT_DESC_UNUSED(R) \
>> + ((((R)->next_to_clean > (R)->next_to_use) ? 0 : (R)->count) + \
>> + (R)->next_to_clean - (R)->next_to_use - 1)
>> +
>> +#define AT_DESC_USED(R) \
>> + (((R)->next_to_clean > (R)->next_to_use) ? \
>> + ((R)->count+(R)->next_to_use-(R)->next_to_clean+1) : \
>> + ((R)->next_to_use-(R)->next_to_clean+1))
>
> These look like they are on the edge to be written as a static-inline function.
> What do others think?

I agree. There's a lot of cosmetic work left to do on this driver, but
we felt it was time to get more eyes on it.

>> +#define AT_WRITE_REG(a, reg, value) ( \
>> + writel((value), ((a)->hw_addr + reg)))
>> +
>> +#define AT_READ_REG(a, reg) ( \
>> + readl((a)->hw_addr + reg ))
>> +
>> +#define AT_WRITE_REGB(a, reg, value) (\
>> + writeb((value), ((a)->hw_addr + reg)))
>> +
>> +#define AT_READ_REGB(a, reg) (\
>> + readb((a)->hw_addr + reg))
>> +
>> +#define AT_WRITE_REGW(a, reg, value) (\
>> + writew((value), ((a)->hw_addr + reg)))
>> +
>> +#define AT_READ_REGW(a, reg) (\
>> + readw((a)->hw_addr + reg))
>> +
>> +#define AT_WRITE_REG_ARRAY(a, reg, offset, value) ( \
>> + writel((value), (((a)->hw_addr + reg) + ((offset) << 2))))
>> +
>> +#define AT_READ_REG_ARRAY(a, reg, offset) ( \
>> + readl(((a)->hw_addr + reg) + ((offset) << 2)))
>
> Possibly similarly.

Yeah, we'll inline these as well. Would you say that level of cosmetic
cleanliness is required for merging, or should we focus solely on the
functional issues for now?

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

\
 
 \ /
  Last update: 2006-11-20 07:05    [W:0.037 / U:6.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site