On 9/9/2022 6:43 AM, Chaoyong He wrote:
On 9/8/2022 9:44 AM, Chaoyong He wrote:
The NFP card can load different firmware applications. Currently
only the CoreNIC application is supported. This commit makes needed
infrastructure changes in order to support other firmware
applications too.
Clearer separation is made between the PF device and any application
specific concepts. The PF struct is now generic regardless of the
application loaded. A new struct is also made for the CoreNIC
application. Future additions to support other applications should
also add an applications specific struct.
What do you think to replace 'application' usage in the commit log
with 'application firmware'?
<...>
diff --git a/drivers/net/nfp/nfp_ethdev.c
b/drivers/net/nfp/nfp_ethdev.c index e9d01f4..bd9cf67 100644
--- a/drivers/net/nfp/nfp_ethdev.c
+++ b/drivers/net/nfp/nfp_ethdev.c
@@ -39,15 +39,15 @@
#include "nfp_cpp_bridge.h"
static int
-nfp_net_pf_read_mac(struct nfp_pf_dev *pf_dev, int port)
+nfp_net_pf_read_mac(struct nfp_app_fw_nic *app_hw_nic, int port)
Is this intentional that struct name is 'nfp_app_fw_nic' but variable
name is 'app_hw_nic'? Why is app_fw vs app_hw difference?
Sorry, I'm not quite sure I catch your doubt.
Do you mean I should just use `app_hw` as variable name if the function only
process one type of the application firmware?
Oh, sorry, I understand now.
I misspelled 'app_fw' to 'app_hw' in some place, I'll revise and check it.
ack
