Hi again Al,
On 7/20/2011 1:38 PM, Albert Chu wrote:
> Hey Hal,
>
> Thanks for the nit-catches. As for
>
>> + {32, 2, "PortVLXmitFlowCtlUpdateErrors0", mad_dump_uint},
>>> + {34, 2, "PortVLXmitFlowCtlUpdateErrors1", mad_dump_uint},
>>> + {36, 2, "PortVLXmitFlowCtlUpdateErrors2", mad_dump_uint},
>>> + {38, 2, "PortVLXmitFlowCtlUpdateErrors3", mad_dump_uint},
>>> + {40, 2, "PortVLXmitFlowCtlUpdateErrors4", mad_dump_uint},
>>> + {42, 2, "PortVLXmitFlowCtlUpdateErrors5", mad_dump_uint},
>>> + {44, 2, "PortVLXmitFlowCtlUpdateErrors6", mad_dump_uint},
>>> + {46, 2, "PortVLXmitFlowCtlUpdateErrors7", mad_dump_uint},
>>> + {48, 2, "PortVLXmitFlowCtlUpdateErrors8", mad_dump_uint},
>>> + {50, 2, "PortVLXmitFlowCtlUpdateErrors9", mad_dump_uint},
>>> + {52, 2, "PortVLXmitFlowCtlUpdateErrors10", mad_dump_uint},
>>> + {54, 2, "PortVLXmitFlowCtlUpdateErrors11", mad_dump_uint},
>>> + {56, 2, "PortVLXmitFlowCtlUpdateErrors12", mad_dump_uint},
>>> + {58, 2, "PortVLXmitFlowCtlUpdateErrors13", mad_dump_uint},
>>> + {60, 2, "PortVLXmitFlowCtlUpdateErrors14", mad_dump_uint},
>>> + {62, 2, "PortVLXmitFlowCtlUpdateErrors15", mad_dump_uint},
>>
>> Don't these need to be BITSOFFS(nn, 2) ?
>
> Perhaps there's a subtlety I'm missing. If these require BITSOFFS, then
> wouldn't the 16 bit fields require them too? There are many places
> amongst the performance counters that BITSOFFS isn't used w/ 16 bit
> fields.
Yes; it looks like any field less than 32 bits should use BITSOFFS so I
think that there are some existing things to fix in fields.c (the 16 bit
fields that are not using the macro).
-- Hal
> Al
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
