[PATCH 2.6.20] powerpc: Changed gianfar device tree definition tomake it more flexible

Kumar Gala galak at kernel.crashing.org
Thu Dec 7 09:12:44 EST 2006


On Dec 6, 2006, at 2:40 PM, Andy Fleming wrote:

>
> On Dec 4, 2006, at 02:20, Joakim Tjernlund wrote:
>
>>
>>> +
>>> +static struct gfar_flag_info __initdata flag_info[] = {
>>> +	{ "gigabit", FSL_GIANFAR_DEV_HAS_GIGABIT },
>>> +	{ "coalescing", FSL_GIANFAR_DEV_HAS_COALESCE },
>>> +	{ "rmon", FSL_GIANFAR_DEV_HAS_RMON },
>>> +	{ "checksumming", FSL_GIANFAR_DEV_HAS_CSUM },
>>> +	{ "vlan", FSL_GIANFAR_DEV_HAS_VLAN },
>>> +	{ "extended-hash", FSL_GIANFAR_DEV_HAS_EXTENDED_HASH },
>>> +	{ "padding", FSL_GIANFAR_DEV_HAS_PADDING },
>>> +	{ "filer", FSL_GIANFAR_DEV_HAS_FILER },
>>> +	{ "parseL4", FSL_GIANFAR_DEV_HAS_PARSE_L4 },
>>> +	{ "parseL3", FSL_GIANFAR_DEV_HAS_PARSE_L3 },
>>> +	{ "parseL2", FSL_GIANFAR_DEV_HAS_PARSE_L2 },
>>> +	{ "multi-queue", FSL_GIANFAR_DEV_HAS_MULTI_QUEUE },
>>> +	{ "buffer-stashing", FSL_GIANFAR_DEV_HAS_BUF_STASHING },
>>> +	{ "buffer-locking", FSL_GIANFAR_DEV_HAS_BUF_LOCKING },
>>> +	{ "bd-stashing", FSL_GIANFAR_DEV_HAS_BD_STASHING },
>>> +	{ "bd-locking", FSL_GIANFAR_DEV_HAS_BD_LOCKING },
>>> +};
>>
>> Shouldn't these be  mapped to generic names(drop the GIANFAR name)?
>> The newer UCC also have sevral of these capabilities and it seems
>> to me that one can use the same names instead of making a similar  
>> table.
>
>
> That's an excellent idea.  But the UCC code base is still pretty  
> foreign to me, so I will have to pursue that with its authors.

Unless we plan on merging the UCC and gianfar drivers in the future I  
dont see much of a point to worry about it.  Eventually this table  
will live in the driver proper so it will have to be duplicated  
between gianfar and UCC.

- k



More information about the Linuxppc-dev mailing list