[dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback
OK On 27.06.2016 17:19, Thomas Monjalon wrote: > 2016-06-23 15:26, zr at semihalf.com: >> From: Zyta Szpak >> >> 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. >> >> Signed-off-by: Zyta Szpak > Please do not mention patch revision in the commit log. > However you can add a changelog below the three dashes (with --annotate). > And please use --in-reply-to to keep revisions in the same thread. > Thanks
[dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback
OK On 27.06.2016 12:46, Remy Horton wrote: > Morning, > > > On 23/06/2016 14:26, zr at semihalf.com wrote: >> From: Zyta Szpak >> >> 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
[dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback
2016-06-23 15:26, zr at semihalf.com: > From: Zyta Szpak > > 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. > > Signed-off-by: Zyta Szpak Please do not mention patch revision in the commit log. However you can add a changelog below the three dashes (with --annotate). And please use --in-reply-to to keep revisions in the same thread. Thanks
[dpdk-dev] [PATCH v4 1/2] ethdev: remove get_reg_length callback
Morning, On 23/06/2016 14:26, zr at semihalf.com wrote: > From: Zyta Szpak > > 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
