public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuval Mintz <yuvalm@mellanox.com>
To: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ariel.Elior@cavium.com
Subject: Re: [PATCH net-next 3/4] qed: Adapter flash update support.
Date: Tue, 27 Mar 2018 16:36:35 +0300	[thread overview]
Message-ID: <20180327133635.GB28037@dev-r-vrt-155.mtr.labs.mlnx> (raw)
In-Reply-To: <20180326101348.21075-4-sudarsana.kalluru@cavium.com>

On Mon, Mar 26, 2018 at 03:13:47AM -0700, Sudarsana Reddy Kalluru wrote:
> This patch adds the required driver support for updating the flash or
> non volatile memory of the adapter. At highlevel, flash upgrade comprises
> of reading the flash images from the input file, validating the images and
> writing it to the respective paritions.

s/it/them/

[...]

> + *     /----------------------------------------------------------------------\
> + * 0B  |                       0x4 [command index]                            |
> + * 4B  | image_type     | Options        |  Number of register settings       |
> + * 8B  |                       Value                                          |
> + * 12B |                       Mask                                           |
> + * 16B |                       Offset                                         |
> + *     \----------------------------------------------------------------------/
> + * There can be several Value-Mask-Offset sets as specified by 'Number of...'.
> + * Options - 0'b - Calculate & Update CRC for image
> + */
> +static int qed_nvm_flash_image_access(struct qed_dev *cdev, const u8 **data,
> +				      bool *check_resp)
> +{
> +	struct qed_nvm_image_att nvm_image;
> +	struct qed_hwfn *p_hwfn;
> +	bool is_crc = false;
> +	u32 image_type;
> +	int rc = 0, i;
> +	u16 len;
> +
 +
> +	nvm_image.start_addr = p_hwfn->nvm_info.image_att[i].nvm_start_addr;
> +	nvm_image.length = p_hwfn->nvm_info.image_att[i].len;
> +
> +	DP_VERBOSE(cdev, NETIF_MSG_DRV,
> +		   "Read image %02x; type = %08x; NVM [%08x,...,%08x]\n",
> +		   **data, nvm_image.start_addr, image_type,
> +		   nvm_image.start_addr + nvm_image.length - 1);

Looks like 3rd and 4th printed parameters are flipped.


> +	(*data)++;
> +	is_crc = !!(**data);

If you'd actually want to be able to use the reserved bits
[forward-compatibility] in the future, you should check bit 0 instead of
checking the byte.

> +	(*data)++;
> +	len = *((u16 *)*data);
> +	*data += 2;

[...]

> +
> +/* Binary file format -
> + *     /----------------------------------------------------------------------\
> + * 0B  |                       0x3 [command index]                            |
> + * 4B  | b'0: check_response?   | b'1-127  reserved                           |
This shows there are 128 bits in a 4 byte field.

> + * 8B  | File-type |                   reserved                               |
> + *     \----------------------------------------------------------------------/
> + *     Start a new file of the provided type
> + */
> +static int qed_nvm_flash_image_file_start(struct qed_dev *cdev,
> +					  const u8 **data, bool *check_resp)
> +{
> +	int rc;
> +
> +	*data += 4;
> +	*check_resp = !!(**data);

Like above

> +	*data += 4;
> +
> +	DP_VERBOSE(cdev, NETIF_MSG_DRV,
> +		   "About to start a new file of type %02x\n", **data);
> +	rc = qed_mcp_nvm_put_file_begin(cdev, **data);
> +	*data += 4;
> +
> +	return rc;
> +}
> +
> +/* Binary file format -
> + *     /----------------------------------------------------------------------\
> + * 0B  |                       0x2 [command index]                            |
> + * 4B  |                       Length in bytes                                |
> + * 8B  | b'0: check_response?   | b'1-127  reserved                           |

Same as above

> + * 12B |                       Offset in bytes                                |
> + * 16B |                       Data ...                                       |
> + *     \----------------------------------------------------------------------/
> + *     Write data as part of a file that was previously started. Data should be
> + *     of length equal to that provided in the message
> + */
> +static int qed_nvm_flash_image_file_data(struct qed_dev *cdev,
> +					 const u8 **data, bool *check_resp)
> +{
> +	u32 offset, len;
> +	int rc;
> +
> +	*data += 4;
> +	len = *((u32 *)(*data));
> +	*data += 4;
> +	*check_resp = !!(**data);

Same as above

> +	*data += 4;
> +	offset = *((u32 *)(*data));
> +	*data += 4;
> +
> +	DP_VERBOSE(cdev, NETIF_MSG_DRV,
> +		   "About to write File-data: %08x bytes to offset %08x\n",
> +		   len, offset);
> +
> +	rc = qed_mcp_nvm_write(cdev, QED_PUT_FILE_DATA, offset,
> +			       (char *)(*data), len);
> +	*data += len;
> +
> +	return rc;
> +}

[...]

> +
> +static int qed_nvm_flash(struct qed_dev *cdev, const char *name)
> +{
> +	rc = qed_nvm_flash_image_validate(cdev, image, &data);
> +	if (rc)
> +		goto exit;
> +
> +	while (data < data_end) {
> +		bool check_resp = false;
> +
> +		/* Parse the actual command */
> +		cmd_type = *((u32 *)data);

What's the final format of the file? Is it LE?

> +		switch (cmd_type) {
> +		case QED_NVM_FLASH_CMD_FILE_DATA:
> +			rc = qed_nvm_flash_image_file_data(cdev, &data,
> +							   &check_resp);
> +			break;
> +		case QED_NVM_FLASH_CMD_FILE_START:
> +			rc = qed_nvm_flash_image_file_start(cdev, &data,
> +							    &check_resp);
> +			break;
> +		case QED_NVM_FLASH_CMD_NVM_CHANGE:
> +			rc = qed_nvm_flash_image_access(cdev, &data,
> +							&check_resp);
> +			break;
> +		default:
> +			DP_ERR(cdev, "Unknown command %08x\n", cmd_type);
> +			rc = -EINVAL;
> +			break;

Either goto or drop the print; You're getting from the next condition.

> +		}
> +
> +		if (rc) {
> +			DP_ERR(cdev, "Command %08x failed\n", cmd_type);
> +			goto exit;
> +		}
> +
> +		/* Check response if needed */
> +		if (check_resp) {
> +			u32 mcp_response = 0;
> +
> +			if (qed_mcp_nvm_resp(cdev, (u8 *)&mcp_response)) {
> +				DP_ERR(cdev, "Failed getting MCP response\n");
> +				rc = -EINVAL;
> +				goto exit;
> +			}
> +
> +			switch (mcp_response & FW_MSG_CODE_MASK) {
> +			case FW_MSG_CODE_OK:
> +			case FW_MSG_CODE_NVM_OK:
> +			case FW_MSG_CODE_NVM_PUT_FILE_FINISH_OK:
> +			case FW_MSG_CODE_PHY_OK:
> +				break;
> +			default:
> +				DP_ERR(cdev, "MFW returns error: %08x\n",
> +				       mcp_response);
> +				rc = -EINVAL;
> +				goto exit;
> +			}
> +		}
> +	}
> +
> +exit:
> +	release_firmware(image);
> +
> +	return rc;
> +}
> +
 

  reply	other threads:[~2018-03-27 13:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 10:13 [PATCH net-next 0/4] qed*: Flash upgrade support Sudarsana Reddy Kalluru
2018-03-26 10:13 ` [PATCH net-next 1/4] qed: Populate nvm image attribute shadow Sudarsana Reddy Kalluru
2018-03-27 13:01   ` Yuval Mintz
2018-03-26 10:13 ` [PATCH net-next 2/4] qed: Add APIs for flash access Sudarsana Reddy Kalluru
2018-03-26 10:13 ` [PATCH net-next 3/4] qed: Adapter flash update support Sudarsana Reddy Kalluru
2018-03-27 13:36   ` Yuval Mintz [this message]
2018-03-28  6:56     ` Kalluru, Sudarsana
2018-03-26 10:13 ` [PATCH net-next 4/4] qede: Ethtool " Sudarsana Reddy Kalluru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180327133635.GB28037@dev-r-vrt-155.mtr.labs.mlnx \
    --to=yuvalm@mellanox.com \
    --cc=Ariel.Elior@cavium.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=sudarsana.kalluru@cavium.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox