netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shradha Shah <sshah@solarflare.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>, <linux-net-drivers@solarflare.com>
Subject: [PATCH net-next 05/14] sfc: Record [rt]x_dpcpu_fw_id in EF10 nic_data
Date: Wed, 6 May 2015 00:56:55 +0100	[thread overview]
Message-ID: <554958C7.9060502@solarflare.com> (raw)
In-Reply-To: <554957DF.2010307@solarflare.com>

From: Daniel Pieczko <dpieczko@solarflare.com>

The (future) code to add/remove vswitches and vports will be
dependent on the firmware variant.
To simplify the checking of the firmware variant, record
values for rx_dpcpu_fw_id and tx_dpcpu_fw_id in EF10 nic_data.

There was only one place where this was previously used:
efx_mcdi_print_fwver() in ethtool.c.
The MC_CMD_GET_CAPABILITIES can be replaced and the values from
nic_data used instead.

Note that the printing of "?" if the MC command fails or if the
outlength is incorrect no longer apply, because errors are returned
in efx_ef10_init_datapath_caps() in both of these cases.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
---
 drivers/net/ethernet/sfc/ef10.c |  7 +++++++
 drivers/net/ethernet/sfc/mcdi.c | 22 ++++++----------------
 drivers/net/ethernet/sfc/nic.h  |  4 ++++
 3 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index ad23018..4f9775f 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -118,6 +118,13 @@ static int efx_ef10_init_datapath_caps(struct efx_nic *efx)
 	nic_data->datapath_caps =
 		MCDI_DWORD(outbuf, GET_CAPABILITIES_OUT_FLAGS1);
 
+	/* record the DPCPU firmware IDs to determine VEB vswitching support.
+	 */
+	nic_data->rx_dpcpu_fw_id =
+		MCDI_WORD(outbuf, GET_CAPABILITIES_OUT_RX_DPCPU_FW_ID);
+	nic_data->tx_dpcpu_fw_id =
+		MCDI_WORD(outbuf, GET_CAPABILITIES_OUT_TX_DPCPU_FW_ID);
+
 	if (!(nic_data->datapath_caps &
 	      (1 << MC_CMD_GET_CAPABILITIES_OUT_TX_TSO_LBN))) {
 		netif_err(efx, drv, efx->net_dev,
diff --git a/drivers/net/ethernet/sfc/mcdi.c b/drivers/net/ethernet/sfc/mcdi.c
index 6502ada..6e0c789 100644
--- a/drivers/net/ethernet/sfc/mcdi.c
+++ b/drivers/net/ethernet/sfc/mcdi.c
@@ -1083,9 +1083,7 @@ void efx_mcdi_process_event(struct efx_channel *channel,
 
 void efx_mcdi_print_fwver(struct efx_nic *efx, char *buf, size_t len)
 {
-	MCDI_DECLARE_BUF(outbuf,
-			 max(MC_CMD_GET_VERSION_OUT_LEN,
-			     MC_CMD_GET_CAPABILITIES_OUT_LEN));
+	MCDI_DECLARE_BUF(outbuf, MC_CMD_GET_VERSION_OUT_LEN);
 	size_t outlength;
 	const __le16 *ver_words;
 	size_t offset;
@@ -1110,19 +1108,11 @@ void efx_mcdi_print_fwver(struct efx_nic *efx, char *buf, size_t len)
 	 * single version.  Report which variants are running.
 	 */
 	if (efx_nic_rev(efx) >= EFX_REV_HUNT_A0) {
-		BUILD_BUG_ON(MC_CMD_GET_CAPABILITIES_IN_LEN != 0);
-		rc = efx_mcdi_rpc(efx, MC_CMD_GET_CAPABILITIES, NULL, 0,
-				  outbuf, sizeof(outbuf), &outlength);
-		if (rc || outlength < MC_CMD_GET_CAPABILITIES_OUT_LEN)
-			offset += snprintf(
-				buf + offset, len - offset, " rx? tx?");
-		else
-			offset += snprintf(
-				buf + offset, len - offset, " rx%x tx%x",
-				MCDI_WORD(outbuf,
-					  GET_CAPABILITIES_OUT_RX_DPCPU_FW_ID),
-				MCDI_WORD(outbuf,
-					  GET_CAPABILITIES_OUT_TX_DPCPU_FW_ID));
+		struct efx_ef10_nic_data *nic_data = efx->nic_data;
+
+		offset += snprintf(buf + offset, len - offset, " rx%x tx%x",
+				   nic_data->rx_dpcpu_fw_id,
+				   nic_data->tx_dpcpu_fw_id);
 
 		/* It's theoretically possible for the string to exceed 31
 		 * characters, though in practice the first three version
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 65dcbc7..17ee3ae 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -491,6 +491,8 @@ enum {
  *	after MC reboot
  * @datapath_caps: Capabilities of datapath firmware (FLAGS1 field of
  *	%MC_CMD_GET_CAPABILITIES response)
+ * @rx_dpcpu_fw_id: Firmware ID of the RxDPCPU
+ * @tx_dpcpu_fw_id: Firmware ID of the TxDPCPU
  */
 struct efx_ef10_nic_data {
 	struct efx_buffer mcdi_buf;
@@ -509,6 +511,8 @@ struct efx_ef10_nic_data {
 	bool workaround_35388;
 	bool must_check_datapath_caps;
 	u32 datapath_caps;
+	unsigned int rx_dpcpu_fw_id;
+	unsigned int tx_dpcpu_fw_id;
 };
 
 int efx_init_sriov(void);

  parent reply	other threads:[~2015-05-05 23:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05 23:53 [PATCH net-next 00/14] sfc: Enabling EF10 Vf's, set up vswitching and bind the SFC driver to the VF's Shradha Shah
2015-05-05 23:55 ` [PATCH net-next 01/14] sfc: Own header for nic-specific sriov functions, single instance of netdev_ops and sriov removed from Falcon code Shradha Shah
2015-05-05 23:55 ` [PATCH net-next 02/14] sfc: Move and rename efx_vf struct to siena_vf Shradha Shah
2015-05-05 23:55 ` [PATCH net-next 03/14] sfc: Enable VF's via a write to the sysfs file sriov_numvfs Shradha Shah
2015-05-05 23:56 ` [PATCH net-next 04/14] sfc: Use MCDI to set FILTER_OP_IN_TX_DOMAIN Shradha Shah
2015-05-05 23:56 ` Shradha Shah [this message]
2015-05-05 23:57 ` [PATCH net-next 06/14] sfc: record the PF's vport ID in nic_data Shradha Shah
2015-05-05 23:57 ` [PATCH net-next 07/14] sfc: create VEB vswitch and vport above default firmware setup Shradha Shah
2015-05-05 23:57 ` [PATCH net-next 08/14] sfc: get the PF number and record in nic_data Shradha Shah
2015-05-05 23:58 ` [PATCH net-next 09/14] sfc: Prepare to bind the sfc driver to the VF Shradha Shah
2015-05-05 23:58 ` [PATCH net-next 10/14] sfc: create vports for VFs and assign random MAC addresses Shradha Shah
2015-05-05 23:58 ` [PATCH net-next 11/14] sfc: manually allocate and free vadaptors Shradha Shah
2015-05-05 23:59 ` [PATCH net-next 12/14] sfc: Cope with permissions enforcement added to firmware for SR-IOV Shradha Shah
2015-05-05 23:59 ` [PATCH net-next 13/14] sfc: Add use of shared RSS contexts Shradha Shah
2015-05-06  0:00 ` [PATCH net-next 14/14] sfc: Bind the sfc driver to any available VF's Shradha Shah
2015-05-09 20:18 ` [PATCH net-next 00/14] sfc: Enabling EF10 Vf's, set up vswitching and bind the SFC driver to the VF's David Miller

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=554958C7.9060502@solarflare.com \
    --to=sshah@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linux-net-drivers@solarflare.com \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).