From: Martin Habets <habetsm.xilinx@gmail.com>
To: alejandro.lucero-palau@amd.com
Cc: netdev@vger.kernel.org, linux-net-drivers@amd.com,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@google.com, martin.habets@amd.com, edward.cree@amd.com,
linux-doc@vger.kernel.org, corbet@lwn.net, jiri@nvidia.com
Subject: Re: [PATCH net] sfc: fix devlink info error handling
Date: Thu, 18 May 2023 08:35:43 +0100 [thread overview]
Message-ID: <ZGXVT5p3SJdYQ48z@gmail.com> (raw)
In-Reply-To: <20230518054822.20242-1-alejandro.lucero-palau@amd.com>
On Thu, May 18, 2023 at 06:48:22AM +0100, alejandro.lucero-palau@amd.com wrote:
> From: Alejandro Lucero <alejandro.lucero-palau@amd.com>
>
> Avoid early devlink info return if errors arise with MCDI commands
> executed for getting the required info from the device. The rationale
> is some commands can fail but later ones could still give useful data.
> Moreover, some nvram partitions could not be present which needs to be
> handled as a non error.
>
> The specific errors are reported through system messages and if any
> error appears, it will be reported generically through extack.
>
> Fixes 14743ddd2495 (sfc: add devlink info support for ef100)
> Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com>
Acked-by: Martin Habets <habetsm.xilinx@gmail.com>
> ---
> drivers/net/ethernet/sfc/efx_devlink.c | 95 ++++++++++++--------------
> 1 file changed, 45 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/net/ethernet/sfc/efx_devlink.c b/drivers/net/ethernet/sfc/efx_devlink.c
> index 381b805659d3..ef9971cbb695 100644
> --- a/drivers/net/ethernet/sfc/efx_devlink.c
> +++ b/drivers/net/ethernet/sfc/efx_devlink.c
> @@ -171,9 +171,14 @@ static int efx_devlink_info_nvram_partition(struct efx_nic *efx,
>
> rc = efx_mcdi_nvram_metadata(efx, partition_type, NULL, version, NULL,
> 0);
> +
> + /* If the partition does not exist, that is not an error. */
> + if (rc == -ENOENT)
> + return 0;
> +
> if (rc) {
> - netif_err(efx, drv, efx->net_dev, "mcdi nvram %s: failed\n",
> - version_name);
> + netif_err(efx, drv, efx->net_dev, "mcdi nvram %s: failed (rc=%d)\n",
> + version_name, rc);
> return rc;
> }
>
> @@ -187,36 +192,33 @@ static int efx_devlink_info_nvram_partition(struct efx_nic *efx,
> static int efx_devlink_info_stored_versions(struct efx_nic *efx,
> struct devlink_info_req *req)
> {
> - int rc;
> -
> - rc = efx_devlink_info_nvram_partition(efx, req,
> - NVRAM_PARTITION_TYPE_BUNDLE,
> - DEVLINK_INFO_VERSION_GENERIC_FW_BUNDLE_ID);
> - if (rc)
> - return rc;
> -
> - rc = efx_devlink_info_nvram_partition(efx, req,
> - NVRAM_PARTITION_TYPE_MC_FIRMWARE,
> - DEVLINK_INFO_VERSION_GENERIC_FW_MGMT);
> - if (rc)
> - return rc;
> -
> - rc = efx_devlink_info_nvram_partition(efx, req,
> - NVRAM_PARTITION_TYPE_SUC_FIRMWARE,
> - EFX_DEVLINK_INFO_VERSION_FW_MGMT_SUC);
> - if (rc)
> - return rc;
> -
> - rc = efx_devlink_info_nvram_partition(efx, req,
> - NVRAM_PARTITION_TYPE_EXPANSION_ROM,
> - EFX_DEVLINK_INFO_VERSION_FW_EXPROM);
> - if (rc)
> - return rc;
> + int err;
>
> - rc = efx_devlink_info_nvram_partition(efx, req,
> - NVRAM_PARTITION_TYPE_EXPANSION_UEFI,
> - EFX_DEVLINK_INFO_VERSION_FW_UEFI);
> - return rc;
> + /* We do not care here about the specific error but just if an error
> + * happened. The specific error will be reported inside the call
> + * through system messages, and if any error happened in any call
> + * below, we report it through extack.
> + */
> + err = efx_devlink_info_nvram_partition(efx, req,
> + NVRAM_PARTITION_TYPE_BUNDLE,
> + DEVLINK_INFO_VERSION_GENERIC_FW_BUNDLE_ID);
> +
> + err |= efx_devlink_info_nvram_partition(efx, req,
> + NVRAM_PARTITION_TYPE_MC_FIRMWARE,
> + DEVLINK_INFO_VERSION_GENERIC_FW_MGMT);
> +
> + err |= efx_devlink_info_nvram_partition(efx, req,
> + NVRAM_PARTITION_TYPE_SUC_FIRMWARE,
> + EFX_DEVLINK_INFO_VERSION_FW_MGMT_SUC);
> +
> + err |= efx_devlink_info_nvram_partition(efx, req,
> + NVRAM_PARTITION_TYPE_EXPANSION_ROM,
> + EFX_DEVLINK_INFO_VERSION_FW_EXPROM);
> +
> + err |= efx_devlink_info_nvram_partition(efx, req,
> + NVRAM_PARTITION_TYPE_EXPANSION_UEFI,
> + EFX_DEVLINK_INFO_VERSION_FW_UEFI);
> + return err;
> }
>
> #define EFX_VER_FLAG(_f) \
> @@ -587,27 +589,20 @@ static int efx_devlink_info_get(struct devlink *devlink,
> {
> struct efx_devlink *devlink_private = devlink_priv(devlink);
> struct efx_nic *efx = devlink_private->efx;
> - int rc;
> + int err;
>
> - /* Several different MCDI commands are used. We report first error
> - * through extack returning at that point. Specific error
> - * information via system messages.
> + /* Several different MCDI commands are used. We report if errors
> + * happened through extack. Specific error information via system
> + * messages inside the calls.
> */
> - rc = efx_devlink_info_board_cfg(efx, req);
> - if (rc) {
> - NL_SET_ERR_MSG_MOD(extack, "Getting board info failed");
> - return rc;
> - }
> - rc = efx_devlink_info_stored_versions(efx, req);
> - if (rc) {
> - NL_SET_ERR_MSG_MOD(extack, "Getting stored versions failed");
> - return rc;
> - }
> - rc = efx_devlink_info_running_versions(efx, req);
> - if (rc) {
> - NL_SET_ERR_MSG_MOD(extack, "Getting running versions failed");
> - return rc;
> - }
> + err = efx_devlink_info_board_cfg(efx, req);
> +
> + err |= efx_devlink_info_stored_versions(efx, req);
> +
> + err |= efx_devlink_info_running_versions(efx, req);
> +
> + if (err)
> + NL_SET_ERR_MSG_MOD(extack, "Errors when getting device info. Check system messages");
>
> return 0;
> }
> --
> 2.17.1
>
next prev parent reply other threads:[~2023-05-18 7:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 5:48 [PATCH net] sfc: fix devlink info error handling alejandro.lucero-palau
2023-05-18 7:35 ` Martin Habets [this message]
2023-05-19 8:00 ` patchwork-bot+netdevbpf
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=ZGXVT5p3SJdYQ48z@gmail.com \
--to=habetsm.xilinx@gmail.com \
--cc=alejandro.lucero-palau@amd.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edward.cree@amd.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-net-drivers@amd.com \
--cc=martin.habets@amd.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.