All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org, jiri@resnulli.us, valex@mellanox.com,
	linyunsheng@huawei.com, lihong.yang@intel.com
Subject: Re: [PATCH 10/15] ice: add basic handler for devlink .info_get
Date: Fri, 31 Jan 2020 10:07:27 -0800	[thread overview]
Message-ID: <20200131100727.1e098f49@cakuba.hsd1.ca.comcast.net> (raw)
In-Reply-To: <20200130225913.1671982-11-jacob.e.keller@intel.com>

On Thu, 30 Jan 2020 14:59:05 -0800, Jacob Keller wrote:
> The devlink .info_get callback allows the driver to report detailed
> version information. The following devlink versions are reported with
> this initial implementation:
> 
>  "driver.version" -> device driver version, to match ethtool -i version
>  "fw" -> firmware version as reported by ethtool -i firmware-version
>  "fw.mgmt" -> The version of the firmware that controls PHY, link, etc
>  "fw.api" -> API version of interface exposed over the AdminQ
>  "fw.build" -> Unique build identifier for the management firmware
>  "nvm.version" -> Version of the NVM parameters section
>  "nvm.oem" -> OEM-specific version information
>  "nvm.eetrack" -> Unique identifier for the combined NVM image

These all need documentation.

> With this, devlink can now report at least the same information as
> reported by the older ethtool interface. Each section of the
> "firmware-version" is also reported independently so that it is easier
> to understand the meaning.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_devlink.c | 103 +++++++++++++++++++
>  1 file changed, 103 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c b/drivers/net/ethernet/intel/ice/ice_devlink.c
> index 0b0f936122de..493c2c2986f2 100644
> --- a/drivers/net/ethernet/intel/ice/ice_devlink.c
> +++ b/drivers/net/ethernet/intel/ice/ice_devlink.c
> @@ -2,9 +2,112 @@
>  /* Copyright (c) 2019, Intel Corporation. */
>  
>  #include "ice.h"
> +#include "ice_lib.h"
>  #include "ice_devlink.h"
>  
> +/**
> + * ice_devlink_info_get - .info_get devlink handler
> + * @devlink: devlink instance structure
> + * @req: the devlink info request
> + * @extack: extended netdev ack structure
> + *
> + * Callback for the devlink .info_get operation. Reports information about the
> + * device.
> + *
> + * @returns zero on success or an error code on failure.
> + */
> +static int ice_devlink_info_get(struct devlink *devlink,
> +				struct devlink_info_req *req,
> +				struct netlink_ext_ack *extack)
> +{
> +	u8 oem_ver, oem_patch, nvm_ver_hi, nvm_ver_lo;
> +	struct ice_pf *pf = devlink_priv(devlink);
> +	struct ice_hw *hw = &pf->hw;
> +	u16 oem_build;
> +	char buf[32]; /* TODO: size this properly */
> +	int err;
> +
> +	ice_get_nvm_version(hw, &oem_ver, &oem_build, &oem_patch, &nvm_ver_hi,
> +			    &nvm_ver_lo);
> +
> +	err = devlink_info_driver_name_put(req, KBUILD_MODNAME);
> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set driver name");
> +		return err;
> +	}
> +
> +	/* driver.version */
> +	err = devlink_info_version_fixed_put(req, "driver.version",
> +					     ice_drv_ver);

Hard no. You should really try to follow the discussions on netdev.

> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set driver version");
> +		return err;
> +	}
> +
> +	/* fw (match exact output of ethtool -i firmware-version) */

That's generally a bad idea, the whole point of info was that people
were stuffing multiple things into ethtool -i fw. Is this only one item
referring to one single entity?

> +	err = devlink_info_version_running_put(req,
> +					       DEVLINK_INFO_VERSION_GENERIC_FW,
> +					       ice_nvm_version_str(hw));
> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set combined fw version");
> +		return err;
> +	}
> +
> +	/* fw.mgmt (DEVLINK_INFO_VERSION_GENERIC_FW_MGMT) */
> +	snprintf(buf, sizeof(buf), "%u.%u.%u", hw->fw_maj_ver, hw->fw_min_ver,
> +		 hw->fw_patch);
> +	err = devlink_info_version_running_put(req, "fw.mgmt", buf);

why not use the define?

> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set fw version data");
> +		return err;
> +	}
> +
> +	/* fw.api */
> +	snprintf(buf, sizeof(buf), "%u.%u", hw->api_maj_ver,
> +		 hw->api_min_ver);
> +	err = devlink_info_version_running_put(req, "fw.api", buf);

Is this the API version of the management FW? I'd go for "fw.mgmt.api".
Datapath, RoCE and other bits may have APIs which evolve independently
for complex chips.

> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set fw API data");
> +		return err;
> +	}
> +
> +	/* fw.build */
> +	snprintf(buf, sizeof(buf), "%08x", hw->fw_build);
> +	err = devlink_info_version_running_put(req, "fw.build", buf);

Huh? Why is this not part of the version?

Maybe you want to use fw.bundle? Naming is hard, at Netronome added
that as a unique identifier for the FW in its entirety / the entire
build as it is passed from Eng to QA and released externally.

> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set fw build data");
> +		return err;
> +	}
> +
> +	/* nvm.version */
> +	snprintf(buf, sizeof(buf), "%x.%02x", nvm_ver_hi, nvm_ver_lo);
> +	err = devlink_info_version_running_put(req, "nvm.version", buf);

Please us the psid 

> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set NVM version data");
> +		return err;
> +	}
> +
> +	/* nvm.oem */
> +	snprintf(buf, sizeof(buf), "%u.%u.%u", oem_ver, oem_build, oem_patch);
> +	err = devlink_info_version_running_put(req, "nvm.oem", buf);

This looks like free form catch all. Let's not.

> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set oem version data");
> +		return err;
> +	}
> +
> +	/* nvm.eetrack */
> +	snprintf(buf, sizeof(buf), "0x%0X", hw->nvm.eetrack);

Mm. maybe this is bundle? Or psid. Hm. Please explain what this is and
what it's supposed to be used for. I should probably add more docs to
the existing items :S

> +	err = devlink_info_version_running_put(req, "nvm.eetrack", buf);
> +	if (err) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unable to set NVM eetrack data");
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +
>  const struct devlink_ops ice_devlink_ops = {
> +	.info_get = ice_devlink_info_get,
>  };
>  
>  /**


  reply	other threads:[~2020-01-31 18:07 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 22:58 [RFC PATCH 00/13] devlink direct region reading Jacob Keller
2020-01-30 22:58 ` [PATCH 01/15] devlink: prepare to support region operations Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-02-03 11:35   ` Jiri Pirko
2020-02-03 16:48     ` Jacob Keller
2020-02-03 17:07     ` Jacob Keller
2020-02-03 17:10       ` Jacob Keller
2020-02-03 17:14     ` Jacob Keller
2020-02-03 17:17     ` Jacob Keller
2020-01-30 22:58 ` [PATCH 02/15] devlink: add functions to take snapshot while locked Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-01-31 18:09     ` Jacob Keller
2020-02-03 11:39   ` Jiri Pirko
2020-02-03 16:45     ` Jacob Keller
2020-01-30 22:58 ` [PATCH 03/15] devlink: add operation to take an immediate snapshot Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-02-03  8:19   ` Yunsheng Lin
2020-02-03 11:50     ` Jiri Pirko
2020-02-03 11:50   ` Jiri Pirko
2020-02-03 16:33     ` Jacob Keller
2020-02-03 19:32     ` Jacob Keller
2020-02-03 21:30       ` Jiri Pirko
2020-02-04 19:20         ` Jacob Keller
2020-01-30 22:58 ` [PATCH 04/15] netdevsim: support taking immediate snapshot via devlink Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-01-31 18:12     ` Jacob Keller
2020-01-30 22:59 ` [PATCH 05/15] ice: use __le16 types for explicitly Little Endian values Jacob Keller
2020-01-30 22:59 ` [PATCH 06/15] ice: create function to read a section of the NVM and Shadow RAM Jacob Keller
2020-01-30 22:59 ` [PATCH 07/15] ice: implement full NVM read from ETHTOOL_GEEPROM Jacob Keller
2020-01-30 22:59 ` [PATCH 08/15] devlink: add devres managed devlinkm_alloc and devlinkm_free Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-01-31 18:16     ` Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-02-01  0:51     ` Jacob Keller
2020-02-01 17:43       ` Jakub Kicinski
2020-02-03 16:35         ` Jacob Keller
2020-02-03 11:29   ` Jiri Pirko
2020-02-03 16:56     ` Jacob Keller
2020-01-30 22:59 ` [PATCH 09/15] ice: enable initial devlink support Jacob Keller
2020-01-30 22:59 ` [PATCH 10/15] ice: add basic handler for devlink .info_get Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski [this message]
2020-01-31 18:25     ` Jacob Keller
2020-01-30 22:59 ` [PATCH 11/15] ice: add board identifier info to " Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-01-31 18:26     ` Jacob Keller
2020-01-30 22:59 ` [PATCH 12/15] ice: add a devlink region to dump shadow RAM contents Jacob Keller
2020-01-30 22:59 ` [PATCH 13/15] devlink: support directly reading from region memory Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-01-31 18:27     ` Jacob Keller
2020-01-31 19:15     ` Jacob Keller
2020-02-03 13:44   ` Jiri Pirko
2020-02-03 16:40     ` Jacob Keller
2020-01-30 22:59 ` [PATCH 14/15] ice: support direct read of the shadow ram region Jacob Keller
2020-01-30 22:59 ` [PATCH 15/15] ice: add ice.rst devlink documentation file Jacob Keller
2020-01-31 18:07   ` Jakub Kicinski
2020-01-31 18:28     ` Jacob Keller
2020-01-30 22:59 ` [RFC PATCH 1/3] Update kernel headers Jacob Keller
2020-01-30 22:59 ` [RFC PATCH 2/3] devlink: add support for DEVLINK_CMD_REGION_TAKE_SNAPSHOT Jacob Keller
2020-01-30 22:59 ` [RFC PATCH 3/3] devlink: stop requiring snapshot for regions Jacob Keller
2020-01-30 23:03 ` [RFC PATCH 00/13] devlink direct region reading Jacob Keller
2020-01-31 18:06 ` Jakub Kicinski
2020-01-31 18:09   ` Jacob Keller

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=20200131100727.1e098f49@cakuba.hsd1.ca.comcast.net \
    --to=kuba@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --cc=lihong.yang@intel.com \
    --cc=linyunsheng@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=valex@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.