Message ID | 20190728015549.27051-3-skalluru@marvell.com |
---|---|
State | Changes Requested |
Delegated to: | David Miller |
Headers | show |
Series | qed*: Support for NVM config attributes. | expand |
From: Sudarsana Reddy Kalluru <skalluru@marvell.com> Date: Sat, 27 Jul 2019 18:55:49 -0700 > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev, const char *name) > rc = qed_nvm_flash_image_access(cdev, &data, > &check_resp); > break; > + case QED_NVM_FLASH_CMD_NVM_CFG_ID: > + rc = qed_nvm_flash_cfg_write(cdev, &data); > + break; > default: > DP_ERR(cdev, "Unknown command %08x\n", cmd_type); I don't see how any existing portable interface can cause this new code to actually be used. You have to explain this to me.
> -----Original Message----- > From: David Miller <davem@davemloft.net> > Sent: Monday, July 29, 2019 11:34 PM > To: Sudarsana Reddy Kalluru <skalluru@marvell.com> > Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>; > Ariel Elior <aelior@marvell.com> > Subject: Re: [PATCH net-next v3 2/2] qed: Add driver API for flashing the > config attributes. > > From: Sudarsana Reddy Kalluru <skalluru@marvell.com> > Date: Sat, 27 Jul 2019 18:55:49 -0700 > > > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev, > const char *name) > > rc = qed_nvm_flash_image_access(cdev, &data, > > &check_resp); > > break; > > + case QED_NVM_FLASH_CMD_NVM_CFG_ID: > > + rc = qed_nvm_flash_cfg_write(cdev, &data); > > + break; > > default: > > DP_ERR(cdev, "Unknown command %08x\n", > cmd_type); > > I don't see how any existing portable interface can cause this new code to > actually be used. > > You have to explain this to me. The API qed_nvm_flash() is used to flash the user provided data (e.g., Management FW) to the required partitions of the adapter. - Format of the input file would be - file signature info, followed by one or more data sets. - Each data set is represented with the header followed by its contents. Header captures info such as command name (e.g., FILE_START), data size etc., which specifies how to handle the data. The API qed_nvm_flash() validates the user provided input file, parses the data sets and handles each accordingly. Here one of the data sets (preferably the last one) could be nvm-attributes page (with cmd-id = QED_NVM_FLASH_CMD_NVM_CHANGE).
> From: Sudarsana Reddy Kalluru > Sent: Tuesday, July 30, 2019 6:36 AM > To: David Miller <davem@davemloft.net> > > > -----Original Message----- > > From: David Miller <davem@davemloft.net> > > Sent: Monday, July 29, 2019 11:34 PM > > To: Sudarsana Reddy Kalluru <skalluru@marvell.com> > > Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>; > > Ariel Elior <aelior@marvell.com> > > Subject: Re: [PATCH net-next v3 2/2] qed: Add driver API for flashing > > the config attributes. > > > > From: Sudarsana Reddy Kalluru <skalluru@marvell.com> > > Date: Sat, 27 Jul 2019 18:55:49 -0700 > > > > > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev, > > const char *name) > > > rc = qed_nvm_flash_image_access(cdev, &data, > > > &check_resp); > > > break; > > > + case QED_NVM_FLASH_CMD_NVM_CFG_ID: > > > + rc = qed_nvm_flash_cfg_write(cdev, &data); > > > + break; > > > > default: > > > DP_ERR(cdev, "Unknown command %08x\n", > > cmd_type); > > > > I don't see how any existing portable interface can cause this new > > code to actually be used. > > > > You have to explain this to me. > The API qed_nvm_flash() is used to flash the user provided data (e.g., > Management FW) to the required partitions of the adapter. > - Format of the input file would be - file signature info, followed by one or > more data sets. > - Each data set is represented with the header followed by its contents. > Header captures info such as command name (e.g., FILE_START), data size > etc., which specifies how to handle the data. > The API qed_nvm_flash() validates the user provided input file, parses the > data sets and handles each accordingly. Here one of the data sets (preferably > the last one) could be nvm-attributes page (with cmd-id = > QED_NVM_FLASH_CMD_NVM_CHANGE). This is basically an expansion of our existing ethtool -f implementation. The management FW has exposed an additional method of configuring some of the nvram options, and this makes use of that. The new code will come into use when newer FW files which contain configuration directives employing this API will be provided to ethtool -f. thanks, Ariel
> -----Original Message----- > From: Ariel Elior <aelior@marvell.com> > Sent: Monday, August 5, 2019 8:00 PM > To: Sudarsana Reddy Kalluru <skalluru@marvell.com>; David Miller > <davem@davemloft.net> > Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com> > Subject: RE: [PATCH net-next v3 2/2] qed: Add driver API for flashing the > config attributes. > > > From: Sudarsana Reddy Kalluru > > Sent: Tuesday, July 30, 2019 6:36 AM > > To: David Miller <davem@davemloft.net> > > > > > -----Original Message----- > > > From: David Miller <davem@davemloft.net> > > > Sent: Monday, July 29, 2019 11:34 PM > > > To: Sudarsana Reddy Kalluru <skalluru@marvell.com> > > > Cc: netdev@vger.kernel.org; Michal Kalderon > <mkalderon@marvell.com>; > > > Ariel Elior <aelior@marvell.com> > > > Subject: Re: [PATCH net-next v3 2/2] qed: Add driver API for > > > flashing the config attributes. > > > > > > From: Sudarsana Reddy Kalluru <skalluru@marvell.com> > > > Date: Sat, 27 Jul 2019 18:55:49 -0700 > > > > > > > @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev > > > > *cdev, > > > const char *name) > > > > rc = qed_nvm_flash_image_access(cdev, &data, > > > > &check_resp); > > > > break; > > > > + case QED_NVM_FLASH_CMD_NVM_CFG_ID: > > > > + rc = qed_nvm_flash_cfg_write(cdev, &data); > > > > + break; > > > > > > default: > > > > DP_ERR(cdev, "Unknown command %08x\n", > > > cmd_type); > > > > > > I don't see how any existing portable interface can cause this new > > > code to actually be used. > > > > > > You have to explain this to me. > > The API qed_nvm_flash() is used to flash the user provided data (e.g., > > Management FW) to the required partitions of the adapter. > > - Format of the input file would be - file signature info, followed > > by one or more data sets. > > - Each data set is represented with the header followed by its contents. > > Header captures info such as command name (e.g., FILE_START), data > > size etc., which specifies how to handle the data. > > The API qed_nvm_flash() validates the user provided input file, parses > > the data sets and handles each accordingly. Here one of the data sets > > (preferably the last one) could be nvm-attributes page (with cmd-id = > > QED_NVM_FLASH_CMD_NVM_CHANGE). > > This is basically an expansion of our existing ethtool -f implementation. > The management FW has exposed an additional method of configuring some > of the nvram options, and this makes use of that. The new code will come > into use when newer FW files which contain configuration directives > employing this API will be provided to ethtool -f. > > thanks, > Ariel Dave, The series appears as "changes requested" in patchwork. Please let us know if any modifications need to be incorporated on this series? Thanks, Sudarsana
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c index 829dd60..54f00d2 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_main.c +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c @@ -67,6 +67,8 @@ #define QED_ROCE_QPS (8192) #define QED_ROCE_DPIS (8) #define QED_RDMA_SRQS QED_ROCE_QPS +#define QED_NVM_CFG_SET_FLAGS 0xE +#define QED_NVM_CFG_SET_PF_FLAGS 0x1E static char version[] = "QLogic FastLinQ 4xxxx Core Module qed " DRV_MODULE_VERSION "\n"; @@ -2227,6 +2229,66 @@ static int qed_nvm_flash_image_validate(struct qed_dev *cdev, return 0; } +/* Binary file format - + * /----------------------------------------------------------------------\ + * 0B | 0x5 [command index] | + * 4B | Entity ID | Reserved | Number of config attributes | + * 8B | Config ID | Length | Value | + * | | + * \----------------------------------------------------------------------/ + * There can be several Cfg_id-Length-Value sets as specified by 'Number of...'. + * Entity ID - A non zero entity value for which the config need to be updated. + */ +static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data) +{ + struct qed_hwfn *hwfn = QED_LEADING_HWFN(cdev); + u8 entity_id, len, buf[32]; + struct qed_ptt *ptt; + u16 cfg_id, count; + int rc = 0, i; + u32 flags; + + ptt = qed_ptt_acquire(hwfn); + if (!ptt) + return -EAGAIN; + + /* NVM CFG ID attribute header */ + *data += 4; + entity_id = **data; + *data += 2; + count = *((u16 *)*data); + *data += 2; + + DP_VERBOSE(cdev, NETIF_MSG_DRV, + "Read config ids: entity id %02x num _attrs = %0d\n", + entity_id, count); + /* NVM CFG ID attributes */ + for (i = 0; i < count; i++) { + cfg_id = *((u16 *)*data); + *data += 2; + len = **data; + (*data)++; + memcpy(buf, *data, len); + *data += len; + + flags = entity_id ? QED_NVM_CFG_SET_PF_FLAGS : + QED_NVM_CFG_SET_FLAGS; + + DP_VERBOSE(cdev, NETIF_MSG_DRV, + "cfg_id = %d len = %d\n", cfg_id, len); + rc = qed_mcp_nvm_set_cfg(hwfn, ptt, cfg_id, entity_id, flags, + buf, len); + if (rc) { + DP_ERR(cdev, "Error %d configuring %d\n", rc, cfg_id); + break; + } + } + + qed_ptt_release(hwfn, ptt); + + return rc; +} + static int qed_nvm_flash(struct qed_dev *cdev, const char *name) { const struct firmware *image; @@ -2268,6 +2330,9 @@ static int qed_nvm_flash(struct qed_dev *cdev, const char *name) rc = qed_nvm_flash_image_access(cdev, &data, &check_resp); break; + case QED_NVM_FLASH_CMD_NVM_CFG_ID: + rc = qed_nvm_flash_cfg_write(cdev, &data); + break; default: DP_ERR(cdev, "Unknown command %08x\n", cmd_type); rc = -EINVAL; diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h index eef02e6..23805ea 100644 --- a/include/linux/qed/qed_if.h +++ b/include/linux/qed/qed_if.h @@ -804,6 +804,7 @@ enum qed_nvm_flash_cmd { QED_NVM_FLASH_CMD_FILE_DATA = 0x2, QED_NVM_FLASH_CMD_FILE_START = 0x3, QED_NVM_FLASH_CMD_NVM_CHANGE = 0x4, + QED_NVM_FLASH_CMD_NVM_CFG_ID = 0x5, QED_NVM_FLASH_CMD_NVM_MAX, };