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

[Kumar Gala]

On Dec 4, 2006, at 2:08 PM, Andy Fleming wrote:

>
> On Dec 1, 2006, at 12:52, Kumar Gala wrote:
>
>> [snip]
>>
>>> +  Optional properties (features):
>>> +    - gigabit : Indicates support for 1000 Mbit operation
>>> +    - coalescing : Indicates support for interrupt coalescing
>>> +    - rmon : Indicates support for RMON-style counters
>>> +    - checksumming : Indicates support for hardware TCP/UDP  
>>> checksumming
>>> +    - vlan-insertion : Indicates support for hardware vlan  
>>> header insertion
>>> +    - extended-hash : Indicates support for using the Individual
>>> +        Address Hash registers to extend the Group Address Hash  
>>> registers
>>> +    - padding : Indicates support for padding between the FCB and
>>> +        the frame
>>> +    - filer : Indicates support for the Filer
>>> +    - parseL2 : Indicates support for parsing L2 headers
>>> +    - parseL3 : Indicates support for parsing L3 headers
>>> +    - parseL4 : Indicates support for parsing L4 headers
>>
>> I'm still think that filer, parseL2, parseL3, parseL4 should be  
>> folded into one attribute. Unless there are plans for version that  
>> only do some subset.
>
> I was told that it would be good to separate them.  I can pursue  
> this further, but until there's code that uses these bits, they're  
> not too important.  Can we let this through, with the proviso that  
> I'll change it?  I'm more concerned about getting the code in,  
> right now.

Told by whom?  I'm not in favor of letting this in because its a  
interface we dont want to be changing.  I can list at all the reasons  
we dont want to, but I think you get the point.

>>> +    - multi-queue : Indicates support for sending and receiving
>>
>> We may want to split this into multi-queue = 4 or something to  
>> spec how many.  Also you may want to split this into tx-multi- 
>> queue and rx-multi-queue.  I can for see have non-equal numbers  
>> for them.
>
>
> Hmm.  Yeah, that makes sense.  My comment from above applies again,  
> though.  Can we let it through, with the proviso that I will change  
> it in a forthcoming patch?  There's no code actually *using* these  
> bits right now, but I need to look into the parse/filer bits, and I  
> need to think about the multiqueue stuff.

See my comment about about interfaces.

>>> +      into multiple queues
>>> +    - buffer-stashing : Controller can allocate buffers into L2
>>> +    - buffer-locking : Controller can lock buffers into L2
>>> +    - bd-stashing : Controller can allocate descriptors into L2
>>> +    - bd-locking : Controller can lock descriptors into L2
>>> +
>>
>>
>> Also
>
> On the other hand
>
>
> Andy