netdev - Re: [PATCH net-next 15/15] bnxt_en: Add support for devlink info command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191123115506.2019cd08@cakuba.netronome.com>
Date:   Sat, 23 Nov 2019 11:55:06 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Michael Chan <michael.chan@...adcom.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        Vasundhara Volam <vasundhara-v.volam@...adcom.com>,
        Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH net-next 15/15] bnxt_en: Add support for devlink info
 command

On Sat, 23 Nov 2019 03:26:10 -0500, Michael Chan wrote:
> From: Vasundhara Volam <vasundhara-v.volam@...adcom.com>
> 
> Display the following information via devlink info command:
>   - Driver name
>   - Board id
>   - Broad revision
>   - Board Serial number
>   - Board Package version
>   - FW version
>   - FW management version
>   - FW RoCE version
> 
>   Standard output example:
>   $ devlink dev info pci/0000:3b:00.0
>   pci/0000:3b:00.0:
>     driver bnxt_en
>     serial_number B0-26-28-FF-FE-25-84-20
>     versions:
>         fixed:
>           board.id C454
>           board.rev 1
>         running:
>           board.package N/A

Just don't report it if you don't have it?

>           fw.version 216.0.154.32004
>           fw.mgmt 864.0.0.0
>           fw.app 216.0.51.0
> 
> Cc: Jiri Pirko <jiri@...lanox.com>
> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@...adcom.com>
> Signed-off-by: Michael Chan <michael.chan@...adcom.com>

> +static int bnxt_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
> +			    struct netlink_ext_ack *extack)
> +{
> +	struct bnxt *bp = bnxt_get_bp_from_dl(dl);
> +	union devlink_param_value nvm_cfg_ver;
> +	struct hwrm_ver_get_output *ver_resp;
> +	char mgmt_ver[FW_VER_STR_LEN];
> +	char roce_ver[FW_VER_STR_LEN];
> +	char fw_ver[FW_VER_STR_LEN];
> +	char buf[32];
> +	int rc;
> +
> +	rc = devlink_info_driver_name_put(req, DRV_MODULE_NAME);
> +	if (rc)
> +		return rc;
> +
> +	sprintf(buf, "%X", bp->chip_num);
> +	rc = devlink_info_version_fixed_put(req, "board.id", buf);

Are you sure chip_num is the board id and not the asic id?
Is this the board version or the silicon version?

Also please use the defines: DEVLINK_INFO_VERSION_GENERIC_BOARD_ID.

> +	if (rc)
> +		return rc;
> +
> +	ver_resp = &bp->ver_resp;
> +	sprintf(buf, "%X", ver_resp->chip_rev);
> +	rc = devlink_info_version_fixed_put(req, "board.rev", buf);
> +	if (rc)
> +		return rc;
> +
> +	if (BNXT_PF(bp)) {
> +		sprintf(buf, "%02X-%02X-%02X-%02X-%02X-%02X-%02X-%02X",
> +			bp->dsn[7], bp->dsn[6], bp->dsn[5], bp->dsn[4],
> +			bp->dsn[3], bp->dsn[2], bp->dsn[1], bp->dsn[0]);
> +		rc = devlink_info_serial_number_put(req, buf);
> +		if (rc)
> +			return rc;
> +	}
> +
> +	if (strlen(ver_resp->active_pkg_name)) {
> +		rc =
> +		    devlink_info_version_running_put(req, "board.package",
> +						     ver_resp->active_pkg_name);

What's a board package? What HW people call a "module"? All devlink info
versions should be documented in devlink-info-versions.rst.

What are the possible values here? Reporting free form strings read
from FW is going to be a tough sell. Probably worth dropping this one
if you want the rest merged for 5.5.

> +		if (rc)
> +			return rc;
> +	}
> +
> +	if (BNXT_PF(bp) && !bnxt_hwrm_get_nvm_cfg_ver(bp, &nvm_cfg_ver)) {
> +		u32 ver = nvm_cfg_ver.vu32;
> +
> +		sprintf(buf, "%X.%X.%X", (ver >> 16) & 0xF, (ver >> 8) & 0xF,
> +			ver & 0xF);
> +		rc = devlink_info_version_running_put(req, "board.nvm_cfg_ver",

ditto

> +						      buf);
> +		if (rc)
> +			return rc;
> +	}
> +
> +	if (ver_resp->flags & VER_GET_RESP_FLAGS_EXT_VER_AVAIL) {
> +		snprintf(fw_ver, FW_VER_STR_LEN, "%d.%d.%d.%d",
> +			 ver_resp->hwrm_fw_major, ver_resp->hwrm_fw_minor,
> +			 ver_resp->hwrm_fw_build, ver_resp->hwrm_fw_patch);
> +
> +		snprintf(mgmt_ver, FW_VER_STR_LEN, "%d.%d.%d.%d",
> +			 ver_resp->mgmt_fw_major, ver_resp->mgmt_fw_minor,
> +			 ver_resp->mgmt_fw_build, ver_resp->mgmt_fw_patch);
> +
> +		snprintf(roce_ver, FW_VER_STR_LEN, "%d.%d.%d.%d",
> +			 ver_resp->roce_fw_major, ver_resp->roce_fw_minor,
> +			 ver_resp->roce_fw_build, ver_resp->roce_fw_patch);
> +	} else {
> +		snprintf(fw_ver, FW_VER_STR_LEN, "%d.%d.%d.%d",
> +			 ver_resp->hwrm_fw_maj_8b, ver_resp->hwrm_fw_min_8b,
> +			 ver_resp->hwrm_fw_bld_8b, ver_resp->hwrm_fw_rsvd_8b);
> +
> +		snprintf(mgmt_ver, FW_VER_STR_LEN, "%d.%d.%d.%d",
> +			 ver_resp->mgmt_fw_maj_8b, ver_resp->mgmt_fw_min_8b,
> +			 ver_resp->mgmt_fw_bld_8b, ver_resp->mgmt_fw_rsvd_8b);
> +
> +		snprintf(roce_ver, FW_VER_STR_LEN, "%d.%d.%d.%d",
> +			 ver_resp->roce_fw_maj_8b, ver_resp->roce_fw_min_8b,
> +			 ver_resp->roce_fw_bld_8b, ver_resp->roce_fw_rsvd_8b);
> +	}
> +	rc = devlink_info_version_running_put(req, "fw.version", fw_ver);
> +	if (rc)
> +		return rc;
> +
> +	if (!(bp->flags & BNXT_FLAG_CHIP_P5)) {
> +		rc = devlink_info_version_running_put(req, "fw.mgmt", mgmt_ver);
> +		if (rc)
> +			return rc;
> +
> +		rc = devlink_info_version_running_put(req, "fw.app", roce_ver);

Should this be fw.roce? Is the NIC ROCE centric, IOW the data path is
all ROCE? 

What's hwrm? perhaps that's the datapath microcode version?

> +		if (rc)
> +			return rc;
> +	}
> +	return 0;
> +}
> +
>  static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
>  			     int msg_len, union devlink_param_value *val)
>  {