[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