openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/drivers/net/ethernet/qlogic/qed/qed_vf.c

1257 lines
34 KiB
C
Raw Normal View History

qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
/* QLogic qed NIC Driver
* Copyright (c) 2015 QLogic Corporation
*
* This software is available under the terms of the GNU General Public License
* (GPL) Version 2, available from the file COPYING in the main directory of
* this source tree.
*/
qed: Bulletin and Link Up to this point, VF and PF communication always originates from VF. As a result, VF cannot be notified of any async changes, and specifically cannot be informed of the current link state. This introduces the bulletin board, the mechanism through which the PF is going to communicate async notifications back to the VF. basically, it's a well-defined structure agreed by both PF and VF which the VF would continuously poll and into which the PF would DMA messages when needed. [Bulletin board is actually allocated and communicated in previous patches but never before used] Based on the bulletin infrastructure, the VF can query its link status and receive said async carrier changes. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:17 +08:00
#include <linux/crc32.h>
qed*: Support forced MAC Allows the PF to enforce the VF's mac. i.e., by using `ip link ... vf <x> mac <value>'. While a MAC is forced, PF would prevent the VF from configuring any other MAC. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:21 +08:00
#include <linux/etherdevice.h>
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
#include "qed.h"
#include "qed_sriov.h"
#include "qed_vf.h"
static void *qed_vf_pf_prep(struct qed_hwfn *p_hwfn, u16 type, u16 length)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
void *p_tlv;
/* This lock is released when we receive PF's response
* in qed_send_msg2pf().
* So, qed_vf_pf_prep() and qed_send_msg2pf()
* must come in sequence.
*/
mutex_lock(&(p_iov->mutex));
DP_VERBOSE(p_hwfn,
QED_MSG_IOV,
"preparing to send 0x%04x tlv over vf pf channel\n",
type);
/* Reset Requst offset */
p_iov->offset = (u8 *)p_iov->vf2pf_request;
/* Clear mailbox - both request and reply */
memset(p_iov->vf2pf_request, 0, sizeof(union vfpf_tlvs));
memset(p_iov->pf2vf_reply, 0, sizeof(union pfvf_tlvs));
/* Init type and length */
p_tlv = qed_add_tlv(p_hwfn, &p_iov->offset, type, length);
/* Init first tlv header */
((struct vfpf_first_tlv *)p_tlv)->reply_address =
(u64)p_iov->pf2vf_reply_phys;
return p_tlv;
}
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
static void qed_vf_pf_req_end(struct qed_hwfn *p_hwfn, int req_status)
{
union pfvf_tlvs *resp = p_hwfn->vf_iov_info->pf2vf_reply;
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"VF request status = 0x%x, PF reply status = 0x%x\n",
req_status, resp->default_resp.hdr.status);
mutex_unlock(&(p_hwfn->vf_iov_info->mutex));
}
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
static int qed_send_msg2pf(struct qed_hwfn *p_hwfn, u8 *done, u32 resp_size)
{
union vfpf_tlvs *p_req = p_hwfn->vf_iov_info->vf2pf_request;
struct ustorm_trigger_vf_zone trigger;
struct ustorm_vf_zone *zone_data;
int rc = 0, time = 100;
zone_data = (struct ustorm_vf_zone *)PXP_VF_BAR0_START_USDM_ZONE_B;
/* output tlvs list */
qed_dp_tlv_list(p_hwfn, p_req);
/* need to add the END TLV to the message size */
resp_size += sizeof(struct channel_list_end_tlv);
/* Send TLVs over HW channel */
memset(&trigger, 0, sizeof(struct ustorm_trigger_vf_zone));
trigger.vf_pf_msg_valid = 1;
DP_VERBOSE(p_hwfn,
QED_MSG_IOV,
"VF -> PF [%02x] message: [%08x, %08x] --> %p, %08x --> %p\n",
GET_FIELD(p_hwfn->hw_info.concrete_fid,
PXP_CONCRETE_FID_PFID),
upper_32_bits(p_hwfn->vf_iov_info->vf2pf_request_phys),
lower_32_bits(p_hwfn->vf_iov_info->vf2pf_request_phys),
&zone_data->non_trigger.vf_pf_msg_addr,
*((u32 *)&trigger), &zone_data->trigger);
REG_WR(p_hwfn,
(uintptr_t)&zone_data->non_trigger.vf_pf_msg_addr.lo,
lower_32_bits(p_hwfn->vf_iov_info->vf2pf_request_phys));
REG_WR(p_hwfn,
(uintptr_t)&zone_data->non_trigger.vf_pf_msg_addr.hi,
upper_32_bits(p_hwfn->vf_iov_info->vf2pf_request_phys));
/* The message data must be written first, to prevent trigger before
* data is written.
*/
wmb();
REG_WR(p_hwfn, (uintptr_t)&zone_data->trigger, *((u32 *)&trigger));
/* When PF would be done with the response, it would write back to the
* `done' address. Poll until then.
*/
while ((!*done) && time) {
msleep(25);
time--;
}
if (!*done) {
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"VF <-- PF Timeout [Type %d]\n",
p_req->first_tlv.tl.type);
rc = -EBUSY;
} else {
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"PF response: %d [Type %d]\n",
*done, p_req->first_tlv.tl.type);
}
return rc;
}
#define VF_ACQUIRE_THRESH 3
qed: PF-VF resource negotiation One of the goals of the vf's first message to the PF [acquire] is to learn about the number of resources available to it [macs, vlans, etc.]. This is done via negotiation - the VF requires a set of resources, which the PF either approves or disaproves and sends a smaller set of resources as alternative. In this later case, the VF is then expected to either abort the probe or re-send the acquire message with less required resources. While this infrastructure exists since the initial submision of qed SRIOV support, it's in fact completely inoperational - PF isn't really looking into the resources the VF has asked for and is never going to reply to the VF that it lacks resources. This patch addresses this flow, fixing it and allowing the PF and VF to actually agree on a set of resources. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:12 +08:00
static void qed_vf_pf_acquire_reduce_resc(struct qed_hwfn *p_hwfn,
struct vf_pf_resc_request *p_req,
struct pf_vf_resc *p_resp)
{
DP_VERBOSE(p_hwfn,
QED_MSG_IOV,
"PF unwilling to fullill resource request: rxq [%02x/%02x] txq [%02x/%02x] sbs [%02x/%02x] mac [%02x/%02x] vlan [%02x/%02x] mc [%02x/%02x]. Try PF recommended amount\n",
p_req->num_rxqs,
p_resp->num_rxqs,
p_req->num_rxqs,
p_resp->num_txqs,
p_req->num_sbs,
p_resp->num_sbs,
p_req->num_mac_filters,
p_resp->num_mac_filters,
p_req->num_vlan_filters,
p_resp->num_vlan_filters,
p_req->num_mc_filters, p_resp->num_mc_filters);
/* humble our request */
p_req->num_txqs = p_resp->num_txqs;
p_req->num_rxqs = p_resp->num_rxqs;
p_req->num_sbs = p_resp->num_sbs;
p_req->num_mac_filters = p_resp->num_mac_filters;
p_req->num_vlan_filters = p_resp->num_vlan_filters;
p_req->num_mc_filters = p_resp->num_mc_filters;
}
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
static int qed_vf_pf_acquire(struct qed_hwfn *p_hwfn)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_acquire_resp_tlv *resp = &p_iov->pf2vf_reply->acquire_resp;
struct pf_vf_pfdev_info *pfdev_info = &resp->pfdev_info;
qed: PF-VF resource negotiation One of the goals of the vf's first message to the PF [acquire] is to learn about the number of resources available to it [macs, vlans, etc.]. This is done via negotiation - the VF requires a set of resources, which the PF either approves or disaproves and sends a smaller set of resources as alternative. In this later case, the VF is then expected to either abort the probe or re-send the acquire message with less required resources. While this infrastructure exists since the initial submision of qed SRIOV support, it's in fact completely inoperational - PF isn't really looking into the resources the VF has asked for and is never going to reply to the VF that it lacks resources. This patch addresses this flow, fixing it and allowing the PF and VF to actually agree on a set of resources. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:12 +08:00
struct vf_pf_resc_request *p_resc;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
bool resources_acquired = false;
struct vfpf_acquire_tlv *req;
int rc = 0, attempts = 0;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_ACQUIRE, sizeof(*req));
qed: PF-VF resource negotiation One of the goals of the vf's first message to the PF [acquire] is to learn about the number of resources available to it [macs, vlans, etc.]. This is done via negotiation - the VF requires a set of resources, which the PF either approves or disaproves and sends a smaller set of resources as alternative. In this later case, the VF is then expected to either abort the probe or re-send the acquire message with less required resources. While this infrastructure exists since the initial submision of qed SRIOV support, it's in fact completely inoperational - PF isn't really looking into the resources the VF has asked for and is never going to reply to the VF that it lacks resources. This patch addresses this flow, fixing it and allowing the PF and VF to actually agree on a set of resources. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:12 +08:00
p_resc = &req->resc_request;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
/* starting filling the request */
req->vfdev_info.opaque_fid = p_hwfn->hw_info.opaque_fid;
qed: PF-VF resource negotiation One of the goals of the vf's first message to the PF [acquire] is to learn about the number of resources available to it [macs, vlans, etc.]. This is done via negotiation - the VF requires a set of resources, which the PF either approves or disaproves and sends a smaller set of resources as alternative. In this later case, the VF is then expected to either abort the probe or re-send the acquire message with less required resources. While this infrastructure exists since the initial submision of qed SRIOV support, it's in fact completely inoperational - PF isn't really looking into the resources the VF has asked for and is never going to reply to the VF that it lacks resources. This patch addresses this flow, fixing it and allowing the PF and VF to actually agree on a set of resources. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:12 +08:00
p_resc->num_rxqs = QED_MAX_VF_CHAINS_PER_PF;
p_resc->num_txqs = QED_MAX_VF_CHAINS_PER_PF;
p_resc->num_sbs = QED_MAX_VF_CHAINS_PER_PF;
p_resc->num_mac_filters = QED_ETH_VF_NUM_MAC_FILTERS;
p_resc->num_vlan_filters = QED_ETH_VF_NUM_VLAN_FILTERS;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
req->vfdev_info.os_type = VFPF_ACQUIRE_OS_LINUX;
req->vfdev_info.fw_major = FW_MAJOR_VERSION;
req->vfdev_info.fw_minor = FW_MINOR_VERSION;
req->vfdev_info.fw_revision = FW_REVISION_VERSION;
req->vfdev_info.fw_engineering = FW_ENGINEERING_VERSION;
qed: Relax VF firmware requirements Current driver require an exact match between VF and PF storm firmware; Any difference would fail the VF acquire message, causing the VF probe to be aborted. While there's still dependencies between the two, the recent FW submission has relaxed the match requirement - instead of an exact match, there's now a 'fastpath' HSI major/minor scheme, where VFs and PFs that match in their major number can co-exist even if their minor is different. In order to accomadate this change some changes in the vf-start init flow had to be made, as the VF start ramrod now has to be sent only after PF learns which fastpath HSI its VF is requiring. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:11 +08:00
req->vfdev_info.eth_fp_hsi_major = ETH_HSI_VER_MAJOR;
req->vfdev_info.eth_fp_hsi_minor = ETH_HSI_VER_MINOR;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
/* Fill capability field with any non-deprecated config we support */
req->vfdev_info.capabilities |= VFPF_ACQUIRE_CAP_100G;
/* pf 2 vf bulletin board address */
req->bulletin_addr = p_iov->bulletin.phys;
req->bulletin_size = p_iov->bulletin.size;
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
while (!resources_acquired) {
DP_VERBOSE(p_hwfn,
QED_MSG_IOV, "attempting to acquire resources\n");
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
/* Clear response buffer, as this might be a re-send */
memset(p_iov->pf2vf_reply, 0, sizeof(union pfvf_tlvs));
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
/* send acquire request */
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
return rc;
/* copy acquire response from buffer to p_hwfn */
memcpy(&p_iov->acquire_resp, resp, sizeof(p_iov->acquire_resp));
attempts++;
if (resp->hdr.status == PFVF_STATUS_SUCCESS) {
/* PF agrees to allocate our resources */
if (!(resp->pfdev_info.capabilities &
PFVF_ACQUIRE_CAP_POST_FW_OVERRIDE)) {
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
/* It's possible legacy PF mistakenly accepted;
* but we don't care - simply mark it as
* legacy and continue.
*/
req->vfdev_info.capabilities |=
VFPF_ACQUIRE_CAP_PRE_FP_HSI;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
}
DP_VERBOSE(p_hwfn, QED_MSG_IOV, "resources acquired\n");
resources_acquired = true;
} else if (resp->hdr.status == PFVF_STATUS_NO_RESOURCE &&
attempts < VF_ACQUIRE_THRESH) {
qed: PF-VF resource negotiation One of the goals of the vf's first message to the PF [acquire] is to learn about the number of resources available to it [macs, vlans, etc.]. This is done via negotiation - the VF requires a set of resources, which the PF either approves or disaproves and sends a smaller set of resources as alternative. In this later case, the VF is then expected to either abort the probe or re-send the acquire message with less required resources. While this infrastructure exists since the initial submision of qed SRIOV support, it's in fact completely inoperational - PF isn't really looking into the resources the VF has asked for and is never going to reply to the VF that it lacks resources. This patch addresses this flow, fixing it and allowing the PF and VF to actually agree on a set of resources. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:12 +08:00
qed_vf_pf_acquire_reduce_resc(p_hwfn, p_resc,
&resp->resc);
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
} else if (resp->hdr.status == PFVF_STATUS_NOT_SUPPORTED) {
if (pfdev_info->major_fp_hsi &&
(pfdev_info->major_fp_hsi != ETH_HSI_VER_MAJOR)) {
DP_NOTICE(p_hwfn,
"PF uses an incompatible fastpath HSI %02x.%02x [VF requires %02x.%02x]. Please change to a VF driver using %02x.xx.\n",
pfdev_info->major_fp_hsi,
pfdev_info->minor_fp_hsi,
ETH_HSI_VER_MAJOR,
ETH_HSI_VER_MINOR,
pfdev_info->major_fp_hsi);
rc = -EINVAL;
goto exit;
}
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
if (!pfdev_info->major_fp_hsi) {
if (req->vfdev_info.capabilities &
VFPF_ACQUIRE_CAP_PRE_FP_HSI) {
DP_NOTICE(p_hwfn,
"PF uses very old drivers. Please change to a VF driver using no later than 8.8.x.x.\n");
rc = -EINVAL;
goto exit;
} else {
DP_INFO(p_hwfn,
"PF is old - try re-acquire to see if it supports FW-version override\n");
req->vfdev_info.capabilities |=
VFPF_ACQUIRE_CAP_PRE_FP_HSI;
continue;
}
}
/* If PF/VF are using same Major, PF must have had
* it's reasons. Simply fail.
*/
DP_NOTICE(p_hwfn, "PF rejected acquisition by VF\n");
rc = -EINVAL;
goto exit;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
} else {
DP_ERR(p_hwfn,
"PF returned error %d to VF acquisition request\n",
resp->hdr.status);
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
rc = -EAGAIN;
goto exit;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
}
}
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
/* Mark the PF as legacy, if needed */
if (req->vfdev_info.capabilities & VFPF_ACQUIRE_CAP_PRE_FP_HSI)
p_iov->b_pre_fp_hsi = true;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
/* Update bulletin board size with response from PF */
p_iov->bulletin.size = resp->bulletin_size;
/* get HW info */
p_hwfn->cdev->type = resp->pfdev_info.dev_type;
p_hwfn->cdev->chip_rev = resp->pfdev_info.chip_rev;
p_hwfn->cdev->chip_num = pfdev_info->chip_num & 0xffff;
/* Learn of the possibility of CMT */
if (IS_LEAD_HWFN(p_hwfn)) {
if (resp->pfdev_info.capabilities & PFVF_ACQUIRE_CAP_100G) {
DP_NOTICE(p_hwfn, "100g VF\n");
p_hwfn->cdev->num_hwfns = 2;
}
}
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
if (!p_iov->b_pre_fp_hsi &&
ETH_HSI_VER_MINOR &&
qed: Relax VF firmware requirements Current driver require an exact match between VF and PF storm firmware; Any difference would fail the VF acquire message, causing the VF probe to be aborted. While there's still dependencies between the two, the recent FW submission has relaxed the match requirement - instead of an exact match, there's now a 'fastpath' HSI major/minor scheme, where VFs and PFs that match in their major number can co-exist even if their minor is different. In order to accomadate this change some changes in the vf-start init flow had to be made, as the VF start ramrod now has to be sent only after PF learns which fastpath HSI its VF is requiring. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:11 +08:00
(resp->pfdev_info.minor_fp_hsi < ETH_HSI_VER_MINOR)) {
DP_INFO(p_hwfn,
"PF is using older fastpath HSI; %02x.%02x is configured\n",
ETH_HSI_VER_MAJOR, resp->pfdev_info.minor_fp_hsi);
}
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
exit:
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
qed_vf_pf_req_end(p_hwfn, rc);
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
return rc;
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
}
int qed_vf_hw_prepare(struct qed_hwfn *p_hwfn)
{
struct qed_vf_iov *p_iov;
u32 reg;
/* Set number of hwfns - might be overriden once leading hwfn learns
* actual configuration from PF.
*/
if (IS_LEAD_HWFN(p_hwfn))
p_hwfn->cdev->num_hwfns = 1;
/* Set the doorbell bar. Assumption: regview is set */
p_hwfn->doorbells = (u8 __iomem *)p_hwfn->regview +
PXP_VF_BAR0_START_DQ;
reg = PXP_VF_BAR0_ME_OPAQUE_ADDRESS;
p_hwfn->hw_info.opaque_fid = (u16)REG_RD(p_hwfn, reg);
reg = PXP_VF_BAR0_ME_CONCRETE_ADDRESS;
p_hwfn->hw_info.concrete_fid = REG_RD(p_hwfn, reg);
/* Allocate vf sriov info */
p_iov = kzalloc(sizeof(*p_iov), GFP_KERNEL);
qed: Remove OOM messages These messages are unnecessary as OOM allocation failures already do a dump_stack() giving more or less the same information. $ size drivers/net/ethernet/qlogic/qed/built-in.o* (defconfig x86-64) text data bss dec hex filename 127817 27969 32800 188586 2e0aa drivers/net/ethernet/qlogic/qed/built-in.o.new 132474 27969 32800 193243 2f2db drivers/net/ethernet/qlogic/qed/built-in.o.old Miscellanea: o Change allocs to the generally preferred forms where possible. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-05 05:24:03 +08:00
if (!p_iov)
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
return -ENOMEM;
/* Allocate vf2pf msg */
p_iov->vf2pf_request = dma_alloc_coherent(&p_hwfn->cdev->pdev->dev,
sizeof(union vfpf_tlvs),
&p_iov->vf2pf_request_phys,
GFP_KERNEL);
qed: Remove OOM messages These messages are unnecessary as OOM allocation failures already do a dump_stack() giving more or less the same information. $ size drivers/net/ethernet/qlogic/qed/built-in.o* (defconfig x86-64) text data bss dec hex filename 127817 27969 32800 188586 2e0aa drivers/net/ethernet/qlogic/qed/built-in.o.new 132474 27969 32800 193243 2f2db drivers/net/ethernet/qlogic/qed/built-in.o.old Miscellanea: o Change allocs to the generally preferred forms where possible. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-05 05:24:03 +08:00
if (!p_iov->vf2pf_request)
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
goto free_p_iov;
p_iov->pf2vf_reply = dma_alloc_coherent(&p_hwfn->cdev->pdev->dev,
sizeof(union pfvf_tlvs),
&p_iov->pf2vf_reply_phys,
GFP_KERNEL);
qed: Remove OOM messages These messages are unnecessary as OOM allocation failures already do a dump_stack() giving more or less the same information. $ size drivers/net/ethernet/qlogic/qed/built-in.o* (defconfig x86-64) text data bss dec hex filename 127817 27969 32800 188586 2e0aa drivers/net/ethernet/qlogic/qed/built-in.o.new 132474 27969 32800 193243 2f2db drivers/net/ethernet/qlogic/qed/built-in.o.old Miscellanea: o Change allocs to the generally preferred forms where possible. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-05 05:24:03 +08:00
if (!p_iov->pf2vf_reply)
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
goto free_vf2pf_request;
DP_VERBOSE(p_hwfn,
QED_MSG_IOV,
"VF's Request mailbox [%p virt 0x%llx phys], Response mailbox [%p virt 0x%llx phys]\n",
p_iov->vf2pf_request,
(u64) p_iov->vf2pf_request_phys,
p_iov->pf2vf_reply, (u64)p_iov->pf2vf_reply_phys);
/* Allocate Bulletin board */
p_iov->bulletin.size = sizeof(struct qed_bulletin_content);
p_iov->bulletin.p_virt = dma_alloc_coherent(&p_hwfn->cdev->pdev->dev,
p_iov->bulletin.size,
&p_iov->bulletin.phys,
GFP_KERNEL);
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"VF's bulletin Board [%p virt 0x%llx phys 0x%08x bytes]\n",
p_iov->bulletin.p_virt,
(u64)p_iov->bulletin.phys, p_iov->bulletin.size);
mutex_init(&p_iov->mutex);
p_hwfn->vf_iov_info = p_iov;
p_hwfn->hw_info.personality = QED_PCI_ETH;
return qed_vf_pf_acquire(p_hwfn);
free_vf2pf_request:
dma_free_coherent(&p_hwfn->cdev->pdev->dev,
sizeof(union vfpf_tlvs),
p_iov->vf2pf_request, p_iov->vf2pf_request_phys);
free_p_iov:
kfree(p_iov);
return -ENOMEM;
}
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
#define TSTORM_QZONE_START PXP_VF_BAR0_START_SDM_ZONE_A
#define MSTORM_QZONE_START(dev) (TSTORM_QZONE_START + \
(TSTORM_QZONE_SIZE * NUM_OF_L2_QUEUES(dev)))
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
int qed_vf_pf_rxq_start(struct qed_hwfn *p_hwfn,
u8 rx_qid,
u16 sb,
u8 sb_index,
u16 bd_max_bytes,
dma_addr_t bd_chain_phys_addr,
dma_addr_t cqe_pbl_addr,
u16 cqe_pbl_size, void __iomem **pp_prod)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_start_queue_resp_tlv *resp;
struct vfpf_start_rxq_tlv *req;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_START_RXQ, sizeof(*req));
req->rx_qid = rx_qid;
req->cqe_pbl_addr = cqe_pbl_addr;
req->cqe_pbl_size = cqe_pbl_size;
req->rxq_addr = bd_chain_phys_addr;
req->hw_sb = sb;
req->sb_index = sb_index;
req->bd_max_bytes = bd_max_bytes;
req->stat_id = -1;
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
/* If PF is legacy, we'll need to calculate producers ourselves
* as well as clean them.
*/
if (pp_prod && p_iov->b_pre_fp_hsi) {
u8 hw_qid = p_iov->acquire_resp.resc.hw_qid[rx_qid];
u32 init_prod_val = 0;
*pp_prod = (u8 __iomem *)p_hwfn->regview +
MSTORM_QZONE_START(p_hwfn->cdev) +
hw_qid * MSTORM_QZONE_SIZE;
/* Init the rcq, rx bd and rx sge (if valid) producers to 0 */
__internal_ram_wr(p_hwfn, *pp_prod, sizeof(u32),
(u32 *)(&init_prod_val));
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->queue_start;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
/* Learn the address of the producer from the response */
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
if (pp_prod && !p_iov->b_pre_fp_hsi) {
qed: Don't over-do producer cleanup for Rx Before requesting the firmware to start Rx queues, driver goes and sets the queue producer in the device to 0. But while the producer is 32-bit, the driver currently clears 64 bits, effectively zeroing an additional CID's producer as well. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-27 19:45:21 +08:00
u32 init_prod_val = 0;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
*pp_prod = (u8 __iomem *)p_hwfn->regview + resp->offset;
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"Rxq[0x%02x]: producer at %p [offset 0x%08x]\n",
rx_qid, *pp_prod, resp->offset);
/* Init the rcq, rx bd and rx sge (if valid) producers to 0 */
qed: Don't over-do producer cleanup for Rx Before requesting the firmware to start Rx queues, driver goes and sets the queue producer in the device to 0. But while the producer is 32-bit, the driver currently clears 64 bits, effectively zeroing an additional CID's producer as well. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-27 19:45:21 +08:00
__internal_ram_wr(p_hwfn, *pp_prod, sizeof(u32),
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
(u32 *)&init_prod_val);
}
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
int qed_vf_pf_rxq_stop(struct qed_hwfn *p_hwfn, u16 rx_qid, bool cqe_completion)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct vfpf_stop_rxqs_tlv *req;
struct pfvf_def_resp_tlv *resp;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_STOP_RXQS, sizeof(*req));
req->rx_qid = rx_qid;
req->num_rxqs = 1;
req->cqe_completion = cqe_completion;
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->default_resp;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
int qed_vf_pf_txq_start(struct qed_hwfn *p_hwfn,
u16 tx_queue_id,
u16 sb,
u8 sb_index,
dma_addr_t pbl_addr,
u16 pbl_size, void __iomem **pp_doorbell)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
qed: Move doorbell calculation from VF to PF Today, the VF is aware of its queues context-ids, and calculates the doorbell address when opening its queues on its own. The configuration of doorbells in HW can sometime in the future be changed by the PF [hw has several configurable features that might affect doorbell addresses, e.g., dpm support], this would break compatibility with older VFs as their calculated doorbell addresses would be incorrect for such a configuration. In order to avoid such a backward compatibility failure, let the PF make the calculation of the doorbell offset based on the context-id, and pass that to the VF. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:14 +08:00
struct pfvf_start_queue_resp_tlv *resp;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
struct vfpf_start_txq_tlv *req;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_START_TXQ, sizeof(*req));
req->tx_qid = tx_queue_id;
/* Tx */
req->pbl_addr = pbl_addr;
req->pbl_size = pbl_size;
req->hw_sb = sb;
req->sb_index = sb_index;
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
qed: Move doorbell calculation from VF to PF Today, the VF is aware of its queues context-ids, and calculates the doorbell address when opening its queues on its own. The configuration of doorbells in HW can sometime in the future be changed by the PF [hw has several configurable features that might affect doorbell addresses, e.g., dpm support], this would break compatibility with older VFs as their calculated doorbell addresses would be incorrect for such a configuration. In order to avoid such a backward compatibility failure, let the PF make the calculation of the doorbell offset based on the context-id, and pass that to the VF. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:14 +08:00
resp = &p_iov->pf2vf_reply->queue_start;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Move doorbell calculation from VF to PF Today, the VF is aware of its queues context-ids, and calculates the doorbell address when opening its queues on its own. The configuration of doorbells in HW can sometime in the future be changed by the PF [hw has several configurable features that might affect doorbell addresses, e.g., dpm support], this would break compatibility with older VFs as their calculated doorbell addresses would be incorrect for such a configuration. In order to avoid such a backward compatibility failure, let the PF make the calculation of the doorbell offset based on the context-id, and pass that to the VF. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:14 +08:00
goto exit;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Move doorbell calculation from VF to PF Today, the VF is aware of its queues context-ids, and calculates the doorbell address when opening its queues on its own. The configuration of doorbells in HW can sometime in the future be changed by the PF [hw has several configurable features that might affect doorbell addresses, e.g., dpm support], this would break compatibility with older VFs as their calculated doorbell addresses would be incorrect for such a configuration. In order to avoid such a backward compatibility failure, let the PF make the calculation of the doorbell offset based on the context-id, and pass that to the VF. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:14 +08:00
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
if (pp_doorbell) {
qed*: Add support for VFs over legacy PFs Modern VFs can't run on old non-compatible as the fastpath HSI is slightly changed - but as the HSI is actually very close [basically, a single bit whose meaning flipped] this can be supported with small modifications. The major differences would be in: - Recognizing that VF is running on top of a legacy PF. - Returning some slowpath configurations that are no longer needed on top of modern PFs, but would be required when working over the legacy ones. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:11 +08:00
/* Modern PFs provide the actual offsets, while legacy
* provided only the queue id.
*/
if (!p_iov->b_pre_fp_hsi) {
*pp_doorbell = (u8 __iomem *)p_hwfn->doorbells +
resp->offset;
} else {
u8 cid = p_iov->acquire_resp.resc.cid[tx_queue_id];
u32 db_addr;
db_addr = qed_db_addr(cid, DQ_DEMS_LEGACY);
*pp_doorbell = (u8 __iomem *)p_hwfn->doorbells +
db_addr;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Move doorbell calculation from VF to PF Today, the VF is aware of its queues context-ids, and calculates the doorbell address when opening its queues on its own. The configuration of doorbells in HW can sometime in the future be changed by the PF [hw has several configurable features that might affect doorbell addresses, e.g., dpm support], this would break compatibility with older VFs as their calculated doorbell addresses would be incorrect for such a configuration. In order to avoid such a backward compatibility failure, let the PF make the calculation of the doorbell offset based on the context-id, and pass that to the VF. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:14 +08:00
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"Txq[0x%02x]: doorbell at %p [offset 0x%08x]\n",
tx_queue_id, *pp_doorbell, resp->offset);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
}
qed: Move doorbell calculation from VF to PF Today, the VF is aware of its queues context-ids, and calculates the doorbell address when opening its queues on its own. The configuration of doorbells in HW can sometime in the future be changed by the PF [hw has several configurable features that might affect doorbell addresses, e.g., dpm support], this would break compatibility with older VFs as their calculated doorbell addresses would be incorrect for such a configuration. In order to avoid such a backward compatibility failure, let the PF make the calculation of the doorbell offset based on the context-id, and pass that to the VF. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-05 18:11:14 +08:00
exit:
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
int qed_vf_pf_txq_stop(struct qed_hwfn *p_hwfn, u16 tx_qid)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct vfpf_stop_txqs_tlv *req;
struct pfvf_def_resp_tlv *resp;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_STOP_TXQS, sizeof(*req));
req->tx_qid = tx_qid;
req->num_txqs = 1;
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->default_resp;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
int qed_vf_pf_vport_start(struct qed_hwfn *p_hwfn,
u8 vport_id,
u16 mtu,
u8 inner_vlan_removal,
enum qed_tpa_mode tpa_mode,
qed*: Support PVID configuration This adds support for PF control over the VF vlan configuration. I.e., `ip link ... vf <x> vlan <vid>' should now be supported. 1. <vid> != 0 => VF receives [unknowingly] only traffic tagged by <vid> and tags all outgoing traffic sent by VF with <vid>. 2. <vid> == 0 ==> Remove the pvid configuration, reverting to previous. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:20 +08:00
u8 max_buffers_per_cqe, u8 only_untagged)
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct vfpf_vport_start_tlv *req;
struct pfvf_def_resp_tlv *resp;
int rc, i;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_VPORT_START, sizeof(*req));
req->mtu = mtu;
req->vport_id = vport_id;
req->inner_vlan_removal = inner_vlan_removal;
req->tpa_mode = tpa_mode;
req->max_buffers_per_cqe = max_buffers_per_cqe;
qed*: Support PVID configuration This adds support for PF control over the VF vlan configuration. I.e., `ip link ... vf <x> vlan <vid>' should now be supported. 1. <vid> != 0 => VF receives [unknowingly] only traffic tagged by <vid> and tags all outgoing traffic sent by VF with <vid>. 2. <vid> == 0 ==> Remove the pvid configuration, reverting to previous. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:20 +08:00
req->only_untagged = only_untagged;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
/* status blocks */
for (i = 0; i < p_hwfn->vf_iov_info->acquire_resp.resc.num_sbs; i++)
if (p_hwfn->sbs_info[i])
req->sb_addr[i] = p_hwfn->sbs_info[i]->sb_phys;
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->default_resp;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
int qed_vf_pf_vport_stop(struct qed_hwfn *p_hwfn)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_def_resp_tlv *resp = &p_iov->pf2vf_reply->default_resp;
int rc;
/* clear mailbox and prep first tlv */
qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_VPORT_TEARDOWN,
sizeof(struct vfpf_first_tlv));
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
static bool
qed_vf_handle_vp_update_is_needed(struct qed_hwfn *p_hwfn,
struct qed_sp_vport_update_params *p_data,
u16 tlv)
{
switch (tlv) {
case CHANNEL_TLV_VPORT_UPDATE_ACTIVATE:
return !!(p_data->update_vport_active_rx_flg ||
p_data->update_vport_active_tx_flg);
qed: Align TLVs As the VF infrastructure is supposed to offer backward/forward compatibility, the various types associated with VF<->PF communication should be aligned across all various platforms that support IOV on our family of adapters. This adds a couple of currently missing values, specifically aligning the enum for the various TLVs possible in the communication between them. It then adds the PF implementation for some of those missing VF requests. This support isn't really necessary for the Linux VF as those VFs aren't requiring it [at least today], but are required by VFs running on other OSes. LRO is an example of one such configuration. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:18 +08:00
case CHANNEL_TLV_VPORT_UPDATE_TX_SWITCH:
return !!p_data->update_tx_switching_flg;
case CHANNEL_TLV_VPORT_UPDATE_VLAN_STRIP:
return !!p_data->update_inner_vlan_removal_flg;
qed*: Support PVID configuration This adds support for PF control over the VF vlan configuration. I.e., `ip link ... vf <x> vlan <vid>' should now be supported. 1. <vid> != 0 => VF receives [unknowingly] only traffic tagged by <vid> and tags all outgoing traffic sent by VF with <vid>. 2. <vid> == 0 ==> Remove the pvid configuration, reverting to previous. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:20 +08:00
case CHANNEL_TLV_VPORT_UPDATE_ACCEPT_ANY_VLAN:
return !!p_data->update_accept_any_vlan_flg;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
case CHANNEL_TLV_VPORT_UPDATE_MCAST:
return !!p_data->update_approx_mcast_flg;
case CHANNEL_TLV_VPORT_UPDATE_ACCEPT_PARAM:
return !!(p_data->accept_flags.update_rx_mode_config ||
p_data->accept_flags.update_tx_mode_config);
case CHANNEL_TLV_VPORT_UPDATE_RSS:
return !!p_data->rss_params;
qed: Align TLVs As the VF infrastructure is supposed to offer backward/forward compatibility, the various types associated with VF<->PF communication should be aligned across all various platforms that support IOV on our family of adapters. This adds a couple of currently missing values, specifically aligning the enum for the various TLVs possible in the communication between them. It then adds the PF implementation for some of those missing VF requests. This support isn't really necessary for the Linux VF as those VFs aren't requiring it [at least today], but are required by VFs running on other OSes. LRO is an example of one such configuration. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:18 +08:00
case CHANNEL_TLV_VPORT_UPDATE_SGE_TPA:
return !!p_data->sge_tpa_params;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
default:
DP_INFO(p_hwfn, "Unexpected vport-update TLV[%d]\n",
tlv);
return false;
}
}
static void
qed_vf_handle_vp_update_tlvs_resp(struct qed_hwfn *p_hwfn,
struct qed_sp_vport_update_params *p_data)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_def_resp_tlv *p_resp;
u16 tlv;
for (tlv = CHANNEL_TLV_VPORT_UPDATE_ACTIVATE;
tlv < CHANNEL_TLV_VPORT_UPDATE_MAX; tlv++) {
if (!qed_vf_handle_vp_update_is_needed(p_hwfn, p_data, tlv))
continue;
p_resp = (struct pfvf_def_resp_tlv *)
qed_iov_search_list_tlvs(p_hwfn, p_iov->pf2vf_reply,
tlv);
if (p_resp && p_resp->hdr.status)
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"TLV[%d] Configuration %s\n",
tlv,
(p_resp && p_resp->hdr.status) ? "succeeded"
: "failed");
}
}
int qed_vf_pf_vport_update(struct qed_hwfn *p_hwfn,
struct qed_sp_vport_update_params *p_params)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct vfpf_vport_update_tlv *req;
struct pfvf_def_resp_tlv *resp;
u8 update_rx, update_tx;
u32 resp_size = 0;
u16 size, tlv;
int rc;
resp = &p_iov->pf2vf_reply->default_resp;
resp_size = sizeof(*resp);
update_rx = p_params->update_vport_active_rx_flg;
update_tx = p_params->update_vport_active_tx_flg;
/* clear mailbox and prep header tlv */
qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_VPORT_UPDATE, sizeof(*req));
/* Prepare extended tlvs */
if (update_rx || update_tx) {
struct vfpf_vport_update_activate_tlv *p_act_tlv;
size = sizeof(struct vfpf_vport_update_activate_tlv);
p_act_tlv = qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_VPORT_UPDATE_ACTIVATE,
size);
resp_size += sizeof(struct pfvf_def_resp_tlv);
if (update_rx) {
p_act_tlv->update_rx = update_rx;
p_act_tlv->active_rx = p_params->vport_active_rx_flg;
}
if (update_tx) {
p_act_tlv->update_tx = update_tx;
p_act_tlv->active_tx = p_params->vport_active_tx_flg;
}
}
qed*: Tx-switching configuration Device should be configured by default to VEB once VFs are active. This changes the configuration of both PFs' and VFs' vports into enabling tx-switching once sriov is enabled. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:25 +08:00
if (p_params->update_tx_switching_flg) {
struct vfpf_vport_update_tx_switch_tlv *p_tx_switch_tlv;
size = sizeof(struct vfpf_vport_update_tx_switch_tlv);
tlv = CHANNEL_TLV_VPORT_UPDATE_TX_SWITCH;
p_tx_switch_tlv = qed_add_tlv(p_hwfn, &p_iov->offset,
tlv, size);
resp_size += sizeof(struct pfvf_def_resp_tlv);
p_tx_switch_tlv->tx_switching = p_params->tx_switching_flg;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
if (p_params->update_approx_mcast_flg) {
struct vfpf_vport_update_mcast_bin_tlv *p_mcast_tlv;
size = sizeof(struct vfpf_vport_update_mcast_bin_tlv);
p_mcast_tlv = qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_VPORT_UPDATE_MCAST, size);
resp_size += sizeof(struct pfvf_def_resp_tlv);
memcpy(p_mcast_tlv->bins, p_params->bins,
sizeof(unsigned long) * ETH_MULTICAST_MAC_BINS_IN_REGS);
}
update_rx = p_params->accept_flags.update_rx_mode_config;
update_tx = p_params->accept_flags.update_tx_mode_config;
if (update_rx || update_tx) {
struct vfpf_vport_update_accept_param_tlv *p_accept_tlv;
tlv = CHANNEL_TLV_VPORT_UPDATE_ACCEPT_PARAM;
size = sizeof(struct vfpf_vport_update_accept_param_tlv);
p_accept_tlv = qed_add_tlv(p_hwfn, &p_iov->offset, tlv, size);
resp_size += sizeof(struct pfvf_def_resp_tlv);
if (update_rx) {
p_accept_tlv->update_rx_mode = update_rx;
p_accept_tlv->rx_accept_filter =
p_params->accept_flags.rx_accept_filter;
}
if (update_tx) {
p_accept_tlv->update_tx_mode = update_tx;
p_accept_tlv->tx_accept_filter =
p_params->accept_flags.tx_accept_filter;
}
}
if (p_params->rss_params) {
struct qed_rss_params *rss_params = p_params->rss_params;
struct vfpf_vport_update_rss_tlv *p_rss_tlv;
size = sizeof(struct vfpf_vport_update_rss_tlv);
p_rss_tlv = qed_add_tlv(p_hwfn,
&p_iov->offset,
CHANNEL_TLV_VPORT_UPDATE_RSS, size);
resp_size += sizeof(struct pfvf_def_resp_tlv);
if (rss_params->update_rss_config)
p_rss_tlv->update_rss_flags |=
VFPF_UPDATE_RSS_CONFIG_FLAG;
if (rss_params->update_rss_capabilities)
p_rss_tlv->update_rss_flags |=
VFPF_UPDATE_RSS_CAPS_FLAG;
if (rss_params->update_rss_ind_table)
p_rss_tlv->update_rss_flags |=
VFPF_UPDATE_RSS_IND_TABLE_FLAG;
if (rss_params->update_rss_key)
p_rss_tlv->update_rss_flags |= VFPF_UPDATE_RSS_KEY_FLAG;
p_rss_tlv->rss_enable = rss_params->rss_enable;
p_rss_tlv->rss_caps = rss_params->rss_caps;
p_rss_tlv->rss_table_size_log = rss_params->rss_table_size_log;
memcpy(p_rss_tlv->rss_ind_table, rss_params->rss_ind_table,
sizeof(rss_params->rss_ind_table));
memcpy(p_rss_tlv->rss_key, rss_params->rss_key,
sizeof(rss_params->rss_key));
}
qed*: Support PVID configuration This adds support for PF control over the VF vlan configuration. I.e., `ip link ... vf <x> vlan <vid>' should now be supported. 1. <vid> != 0 => VF receives [unknowingly] only traffic tagged by <vid> and tags all outgoing traffic sent by VF with <vid>. 2. <vid> == 0 ==> Remove the pvid configuration, reverting to previous. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:20 +08:00
if (p_params->update_accept_any_vlan_flg) {
struct vfpf_vport_update_accept_any_vlan_tlv *p_any_vlan_tlv;
size = sizeof(struct vfpf_vport_update_accept_any_vlan_tlv);
tlv = CHANNEL_TLV_VPORT_UPDATE_ACCEPT_ANY_VLAN;
p_any_vlan_tlv = qed_add_tlv(p_hwfn, &p_iov->offset, tlv, size);
resp_size += sizeof(struct pfvf_def_resp_tlv);
p_any_vlan_tlv->accept_any_vlan = p_params->accept_any_vlan;
p_any_vlan_tlv->update_accept_any_vlan_flg =
p_params->update_accept_any_vlan_flg;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, resp_size);
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed_vf_handle_vp_update_tlvs_resp(p_hwfn, p_params);
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
return rc;
}
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
int qed_vf_pf_reset(struct qed_hwfn *p_hwfn)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_def_resp_tlv *resp;
struct vfpf_first_tlv *req;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_CLOSE, sizeof(*req));
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->default_resp;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EAGAIN;
goto exit;
}
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
p_hwfn->b_int_enabled = 0;
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
return rc;
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
}
int qed_vf_pf_release(struct qed_hwfn *p_hwfn)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_def_resp_tlv *resp;
struct vfpf_first_tlv *req;
u32 size;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_RELEASE, sizeof(*req));
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->default_resp;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (!rc && resp->hdr.status != PFVF_STATUS_SUCCESS)
rc = -EAGAIN;
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
p_hwfn->b_int_enabled = 0;
if (p_iov->vf2pf_request)
dma_free_coherent(&p_hwfn->cdev->pdev->dev,
sizeof(union vfpf_tlvs),
p_iov->vf2pf_request,
p_iov->vf2pf_request_phys);
if (p_iov->pf2vf_reply)
dma_free_coherent(&p_hwfn->cdev->pdev->dev,
sizeof(union pfvf_tlvs),
p_iov->pf2vf_reply, p_iov->pf2vf_reply_phys);
if (p_iov->bulletin.p_virt) {
size = sizeof(struct qed_bulletin_content);
dma_free_coherent(&p_hwfn->cdev->pdev->dev,
size,
p_iov->bulletin.p_virt, p_iov->bulletin.phys);
}
kfree(p_hwfn->vf_iov_info);
p_hwfn->vf_iov_info = NULL;
return rc;
}
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
void qed_vf_pf_filter_mcast(struct qed_hwfn *p_hwfn,
struct qed_filter_mcast *p_filter_cmd)
{
struct qed_sp_vport_update_params sp_params;
int i;
memset(&sp_params, 0, sizeof(sp_params));
sp_params.update_approx_mcast_flg = 1;
if (p_filter_cmd->opcode == QED_FILTER_ADD) {
for (i = 0; i < p_filter_cmd->num_mc_addrs; i++) {
u32 bit;
bit = qed_mcast_bin_from_mac(p_filter_cmd->mac[i]);
__set_bit(bit, sp_params.bins);
}
}
qed_vf_pf_vport_update(p_hwfn, &sp_params);
}
int qed_vf_pf_filter_ucast(struct qed_hwfn *p_hwfn,
struct qed_filter_ucast *p_ucast)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct vfpf_ucast_filter_tlv *req;
struct pfvf_def_resp_tlv *resp;
int rc;
/* clear mailbox and prep first tlv */
req = qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_UCAST_FILTER, sizeof(*req));
req->opcode = (u8) p_ucast->opcode;
req->type = (u8) p_ucast->type;
memcpy(req->mac, p_ucast->mac, ETH_ALEN);
req->vlan = p_ucast->vlan;
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
resp = &p_iov->pf2vf_reply->default_resp;
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EAGAIN;
goto exit;
}
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
return rc;
qed: IOV l2 functionality This adds sufficient changes to allow VFs l2-configuration flows to work. While the fastpath of the VF and the PF are meant to be exactly the same, the configuration of the VF is done by the PF. This diverges all VF-related configuration flows that originate from a VF, making them pass through the VF->PF channel and adding sufficient logic on the PF side to support them. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:16 +08:00
}
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
int qed_vf_pf_int_cleanup(struct qed_hwfn *p_hwfn)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct pfvf_def_resp_tlv *resp = &p_iov->pf2vf_reply->default_resp;
int rc;
/* clear mailbox and prep first tlv */
qed_vf_pf_prep(p_hwfn, CHANNEL_TLV_INT_CLEANUP,
sizeof(struct vfpf_first_tlv));
/* add list termination tlv */
qed_add_tlv(p_hwfn, &p_iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
rc = qed_send_msg2pf(p_hwfn, &resp->hdr.status, sizeof(*resp));
if (rc)
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
goto exit;
if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
rc = -EINVAL;
goto exit;
}
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
exit:
qed_vf_pf_req_end(p_hwfn, rc);
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
qed: Change locking scheme for VF channel Each VF employees a lock that's supposed to serialize its usage of the HW channel for communication with its PF, but the critical section is ill-defined: - VFs currently release the lock whenever the PF response arrives, prior to actually processing the reply buffer [which was also supposed to have been protected by same lock]. - The lock would be released on first response, ignoring the possibilty the sw flow isn't over [as might be the case of the acquisition flow]. As a result, the flow would run unprotected and would cause a double mutex release [as the additional message completion would release it while its actually already free]. Change the flow to have a dedicated function to be called at end of each flow and release the lock. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-08-22 18:25:12 +08:00
return rc;
qed: IOV configure and FLR While previous patches have already added the necessary logic to probe VFs as well as enabling them in the HW, this patch adds the ability to support VF FLR & SRIOV disable. It then wraps both flows together into the first IOV callback to be provided to the protocol driver - `configure'. This would later to be used to enable and disable SRIOV in the adapter. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:15 +08:00
}
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
u16 qed_vf_get_igu_sb_id(struct qed_hwfn *p_hwfn, u16 sb_id)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
if (!p_iov) {
DP_NOTICE(p_hwfn, "vf_sriov_info isn't initialized\n");
return 0;
}
return p_iov->acquire_resp.resc.hw_sbs[sb_id].hw_sb_id;
}
qed: Bulletin and Link Up to this point, VF and PF communication always originates from VF. As a result, VF cannot be notified of any async changes, and specifically cannot be informed of the current link state. This introduces the bulletin board, the mechanism through which the PF is going to communicate async notifications back to the VF. basically, it's a well-defined structure agreed by both PF and VF which the VF would continuously poll and into which the PF would DMA messages when needed. [Bulletin board is actually allocated and communicated in previous patches but never before used] Based on the bulletin infrastructure, the VF can query its link status and receive said async carrier changes. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:17 +08:00
int qed_vf_read_bulletin(struct qed_hwfn *p_hwfn, u8 *p_change)
{
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
struct qed_bulletin_content shadow;
u32 crc, crc_size;
crc_size = sizeof(p_iov->bulletin.p_virt->crc);
*p_change = 0;
/* Need to guarantee PF is not in the middle of writing it */
memcpy(&shadow, p_iov->bulletin.p_virt, p_iov->bulletin.size);
/* If version did not update, no need to do anything */
if (shadow.version == p_iov->bulletin_shadow.version)
return 0;
/* Verify the bulletin we see is valid */
crc = crc32(0, (u8 *)&shadow + crc_size,
p_iov->bulletin.size - crc_size);
if (crc != shadow.crc)
return -EAGAIN;
/* Set the shadow bulletin and process it */
memcpy(&p_iov->bulletin_shadow, &shadow, p_iov->bulletin.size);
DP_VERBOSE(p_hwfn, QED_MSG_IOV,
"Read a bulletin update %08x\n", shadow.version);
*p_change = 1;
return 0;
}
void __qed_vf_get_link_params(struct qed_hwfn *p_hwfn,
struct qed_mcp_link_params *p_params,
struct qed_bulletin_content *p_bulletin)
{
memset(p_params, 0, sizeof(*p_params));
p_params->speed.autoneg = p_bulletin->req_autoneg;
p_params->speed.advertised_speeds = p_bulletin->req_adv_speed;
p_params->speed.forced_speed = p_bulletin->req_forced_speed;
p_params->pause.autoneg = p_bulletin->req_autoneg_pause;
p_params->pause.forced_rx = p_bulletin->req_forced_rx;
p_params->pause.forced_tx = p_bulletin->req_forced_tx;
p_params->loopback_mode = p_bulletin->req_loopback;
}
void qed_vf_get_link_params(struct qed_hwfn *p_hwfn,
struct qed_mcp_link_params *params)
{
__qed_vf_get_link_params(p_hwfn, params,
&(p_hwfn->vf_iov_info->bulletin_shadow));
}
void __qed_vf_get_link_state(struct qed_hwfn *p_hwfn,
struct qed_mcp_link_state *p_link,
struct qed_bulletin_content *p_bulletin)
{
memset(p_link, 0, sizeof(*p_link));
p_link->link_up = p_bulletin->link_up;
p_link->speed = p_bulletin->speed;
p_link->full_duplex = p_bulletin->full_duplex;
p_link->an = p_bulletin->autoneg;
p_link->an_complete = p_bulletin->autoneg_complete;
p_link->parallel_detection = p_bulletin->parallel_detection;
p_link->pfc_enabled = p_bulletin->pfc_enabled;
p_link->partner_adv_speed = p_bulletin->partner_adv_speed;
p_link->partner_tx_flow_ctrl_en = p_bulletin->partner_tx_flow_ctrl_en;
p_link->partner_rx_flow_ctrl_en = p_bulletin->partner_rx_flow_ctrl_en;
p_link->partner_adv_pause = p_bulletin->partner_adv_pause;
p_link->sfp_tx_fault = p_bulletin->sfp_tx_fault;
}
void qed_vf_get_link_state(struct qed_hwfn *p_hwfn,
struct qed_mcp_link_state *link)
{
__qed_vf_get_link_state(p_hwfn, link,
&(p_hwfn->vf_iov_info->bulletin_shadow));
}
void __qed_vf_get_link_caps(struct qed_hwfn *p_hwfn,
struct qed_mcp_link_capabilities *p_link_caps,
struct qed_bulletin_content *p_bulletin)
{
memset(p_link_caps, 0, sizeof(*p_link_caps));
p_link_caps->speed_capabilities = p_bulletin->capability_speed;
}
void qed_vf_get_link_caps(struct qed_hwfn *p_hwfn,
struct qed_mcp_link_capabilities *p_link_caps)
{
__qed_vf_get_link_caps(p_hwfn, p_link_caps,
&(p_hwfn->vf_iov_info->bulletin_shadow));
}
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
void qed_vf_get_num_rxqs(struct qed_hwfn *p_hwfn, u8 *num_rxqs)
{
*num_rxqs = p_hwfn->vf_iov_info->acquire_resp.resc.num_rxqs;
}
void qed_vf_get_port_mac(struct qed_hwfn *p_hwfn, u8 *port_mac)
{
memcpy(port_mac,
p_hwfn->vf_iov_info->acquire_resp.pfdev_info.port_mac, ETH_ALEN);
}
void qed_vf_get_num_vlan_filters(struct qed_hwfn *p_hwfn, u8 *num_vlan_filters)
{
struct qed_vf_iov *p_vf;
p_vf = p_hwfn->vf_iov_info;
*num_vlan_filters = p_vf->acquire_resp.resc.num_vlan_filters;
}
qed*: Support forced MAC Allows the PF to enforce the VF's mac. i.e., by using `ip link ... vf <x> mac <value>'. While a MAC is forced, PF would prevent the VF from configuring any other MAC. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:21 +08:00
bool qed_vf_check_mac(struct qed_hwfn *p_hwfn, u8 *mac)
{
struct qed_bulletin_content *bulletin;
bulletin = &p_hwfn->vf_iov_info->bulletin_shadow;
if (!(bulletin->valid_bitmap & (1 << MAC_ADDR_FORCED)))
return true;
/* Forbid VF from changing a MAC enforced by PF */
if (ether_addr_equal(bulletin->mac, mac))
return false;
return false;
}
qed: mark symbols static where possible We get a few warnings when building kernel with W=1: drivers/net/ethernet/qlogic/qed/qed_l2.c:112:5: warning: no previous prototype for 'qed_sp_vport_start' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:110:6: warning: no previous prototype for 'qed_iov_is_valid_vfid' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:188:5: warning: no previous prototype for 'qed_iov_post_vf_bulletin' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:578:6: warning: no previous prototype for 'qed_iov_set_vfs_to_disable' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:1135:28: warning: no previous prototype for 'qed_iov_get_public_vf_info' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:1148:6: warning: no previous prototype for 'qed_iov_clean_vf' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:2444:5: warning: no previous prototype for 'qed_iov_chk_ucast' [-Wmissing-prototypes] drivers/net/ethernet/qlogic/qed/qed_sriov.c:2762:5: warning: no previous prototype for 'qed_iov_vf_flr_cleanup' [-Wmissing-prototypes] .... In fact, these functions are only used in the file in which they are declared and don't need a declaration, but can be made static. so this patch marks these functions with 'static'. Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-09 09:21:15 +08:00
static bool qed_vf_bulletin_get_forced_mac(struct qed_hwfn *hwfn,
u8 *dst_mac, u8 *p_is_forced)
qed*: Support forced MAC Allows the PF to enforce the VF's mac. i.e., by using `ip link ... vf <x> mac <value>'. While a MAC is forced, PF would prevent the VF from configuring any other MAC. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:21 +08:00
{
struct qed_bulletin_content *bulletin;
bulletin = &hwfn->vf_iov_info->bulletin_shadow;
if (bulletin->valid_bitmap & (1 << MAC_ADDR_FORCED)) {
if (p_is_forced)
*p_is_forced = 1;
} else if (bulletin->valid_bitmap & (1 << VFPF_BULLETIN_MAC_ADDR)) {
if (p_is_forced)
*p_is_forced = 0;
} else {
return false;
}
ether_addr_copy(dst_mac, bulletin->mac);
return true;
}
qed: Introduce VFs This adds the qed VFs for the first time - The vfs are limited functions, with a very different PCI bar structure [when compared with PFs] to better impose the related security demands associated with them. This patch includes the logic neccesary to allow VFs to successfully probe [without actually adding the ability to enable iov]. This includes diverging all the flows that would occur as part of the pci probe of the driver, preventing VF from accessing registers/memories it can't and instead utilize the VF->PF channel to query the PF for needed information. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:14 +08:00
void qed_vf_get_fw_version(struct qed_hwfn *p_hwfn,
u16 *fw_major, u16 *fw_minor,
u16 *fw_rev, u16 *fw_eng)
{
struct pf_vf_pfdev_info *info;
info = &p_hwfn->vf_iov_info->acquire_resp.pfdev_info;
*fw_major = info->fw_major;
*fw_minor = info->fw_minor;
*fw_rev = info->fw_rev;
*fw_eng = info->fw_eng;
}
qed: Bulletin and Link Up to this point, VF and PF communication always originates from VF. As a result, VF cannot be notified of any async changes, and specifically cannot be informed of the current link state. This introduces the bulletin board, the mechanism through which the PF is going to communicate async notifications back to the VF. basically, it's a well-defined structure agreed by both PF and VF which the VF would continuously poll and into which the PF would DMA messages when needed. [Bulletin board is actually allocated and communicated in previous patches but never before used] Based on the bulletin infrastructure, the VF can query its link status and receive said async carrier changes. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:17 +08:00
static void qed_handle_bulletin_change(struct qed_hwfn *hwfn)
{
qed*: Support forced MAC Allows the PF to enforce the VF's mac. i.e., by using `ip link ... vf <x> mac <value>'. While a MAC is forced, PF would prevent the VF from configuring any other MAC. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:21 +08:00
struct qed_eth_cb_ops *ops = hwfn->cdev->protocol_ops.eth;
u8 mac[ETH_ALEN], is_mac_exist, is_mac_forced;
void *cookie = hwfn->cdev->ops_cookie;
is_mac_exist = qed_vf_bulletin_get_forced_mac(hwfn, mac,
&is_mac_forced);
if (is_mac_exist && is_mac_forced && cookie)
ops->force_mac(cookie, mac);
qed: Bulletin and Link Up to this point, VF and PF communication always originates from VF. As a result, VF cannot be notified of any async changes, and specifically cannot be informed of the current link state. This introduces the bulletin board, the mechanism through which the PF is going to communicate async notifications back to the VF. basically, it's a well-defined structure agreed by both PF and VF which the VF would continuously poll and into which the PF would DMA messages when needed. [Bulletin board is actually allocated and communicated in previous patches but never before used] Based on the bulletin infrastructure, the VF can query its link status and receive said async carrier changes. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-05-11 21:36:17 +08:00
/* Always update link configuration according to bulletin */
qed_link_update(hwfn);
}
void qed_iov_vf_task(struct work_struct *work)
{
struct qed_hwfn *hwfn = container_of(work, struct qed_hwfn,
iov_task.work);
u8 change = 0;
if (test_and_clear_bit(QED_IOV_WQ_STOP_WQ_FLAG, &hwfn->iov_task_flags))
return;
/* Handle bulletin board changes */
qed_vf_read_bulletin(hwfn, &change);
if (change)
qed_handle_bulletin_change(hwfn);
/* As VF is polling bulletin board, need to constantly re-schedule */
queue_delayed_work(hwfn->iov_wq, &hwfn->iov_task, HZ);
}