On Thursday 21 September 2017 06:29 PM, Shreyansh Jain wrote:
Hello Ferruh,
Apologies for delay in response for these, I am already working to get
the next version based on your comments. Meanwhile, some comments inline...
On Monday 18 September 2017 08:25 PM, Ferruh Yigit wrote:
On 9/9/2017 12:21 PM, Shreyansh Jain wrote:
Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com>
Signed-off-by: Shreyansh Jain <shreyansh.j...@nxp.com>
<...>
[...]
+ }
+
+ /* Populate ethdev structure */
eth_dev->dev_ops = &dpaa_devops;
+ eth_dev->rx_pkt_burst = dpaa_eth_queue_rx;
+ eth_dev->tx_pkt_burst = dpaa_eth_tx_drop_all;
+
+ /* Allocate memory for storing MAC addresses */
+ eth_dev->data->mac_addrs = rte_zmalloc("mac_addr",
+ ETHER_ADDR_LEN * DPAA_MAX_MAC_FILTER, 0);
+ if (eth_dev->data->mac_addrs == NULL) {
+ DPAA_PMD_ERR("Failed to allocate %d bytes needed to "
+ "store MAC addresses",
+ ETHER_ADDR_LEN * DPAA_MAX_MAC_FILTER);
free dpaa_intf->rx_queues, tx_queues ?
yes, certainly an issue. I will fix it.
I have fixed this in v5.
+ return -ENOMEM;
+ }
+
+ /* copy the primary mac address */
+ memcpy(eth_dev->data->mac_addrs[0].addr_bytes,
+ fman_intf->mac_addr.addr_bytes,
+ ETHER_ADDR_LEN);
Instead can use ether_addr_copy() instead.
:) Yes, I can.
Unfortunately, I forgot to fix this in v5.
If you want, I can send a small patch against this. Sending a v6 because
of this would be overkill. But, this is definitely a valid comment.
Sorry.
<...>
