Re: [dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback

[Remy Horton <remy.horton@intel.com>]

Morning,


On 23/06/2016 14:26, zr@semihalf.com wrote:
> From: Zyta Szpak <zr@semihalf.com>
>
> Version 4 of fixing the assumption of that device registers
> are always 32 bits long. rte_eth_dev_get_reg_length and
> rte_eth_dev_get_reg_info callbacks did not provide register size
> to the app in any way. It is needed to allocate proper number
> of bytes before retrieving registers content with
> rte_eth_dev_get_reg. This commit remove rte_eth_dev_get_reg_length
> callback and adds width parameter to reg_info struct which makes
> it possible to call rte_eth_dev_get_reg_info to get attributes
> first. The drivers using this callback fill width and length
> when call to function made with data=NULL.

I think this would read better as a commit message:

Removes hard-coded assumption that device registers are always 32 bits 
wide. The rte_eth_dev_get_reg_length and rte_eth_dev_get_reg_info 
callbacks did not provide register size to the app in any way, which is 
needed to allocate correct number of bytes before retrieving registers 
using rte_eth_dev_get_reg.

This commit changes rte_eth_dev_get_reg_info so that it can be used to 
retrieve both the number of registers and their width, and removes the 
now-redundant rte_eth_dev_get_reg_length.


> -/**
> - * Retrieve device registers and register attributes
> + * Retrieve device registers and register attributes (nb of regs and reg size)
>   *
>   * @param port_id
>   *   The port identifier of the Ethernet device.

Need detail regarding how *info->data affects function behaviour. 
Something along the lines of:

/**
  * Retrieve device registers and register attributes (number of
  * registers and register size)
  *
  * @param port_id
  *   The port identifier of the Ethernet device.
  * @param info
  *   Pointer to rte_dev_reg_info structure to fill in. If info->data is
  *   NULL the function fills in the width and length fields. If non-NULL
  *   the registers are put into the buffer pointed at by the data field.

Program code itself looks good to me.

..Remy