2020-05-27 15:21:28 +00:00
|
|
|
// SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0-only)
|
2021-11-17 14:30:51 +00:00
|
|
|
/* Copyright(c) 2015 - 2021 Intel Corporation */
|
2021-12-16 09:13:21 +00:00
|
|
|
#include <linux/bitfield.h>
|
2021-11-17 14:30:51 +00:00
|
|
|
#include <linux/spinlock.h>
|
|
|
|
|
#include <linux/types.h>
|
2015-08-07 18:34:25 +00:00
|
|
|
#include "adf_accel_devices.h"
|
|
|
|
|
#include "adf_common_drv.h"
|
2021-11-17 14:30:51 +00:00
|
|
|
#include "adf_pfvf_msg.h"
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
#include "adf_pfvf_pf_msg.h"
|
2021-11-17 14:30:51 +00:00
|
|
|
#include "adf_pfvf_pf_proto.h"
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
#include "adf_pfvf_utils.h"
|
|
|
|
|
|
|
|
|
|
typedef u8 (*pf2vf_blkmsg_data_getter_fn)(u8 const *blkmsg, u8 byte);
|
|
|
|
|
|
|
|
|
|
static const adf_pf2vf_blkmsg_provider pf2vf_blkmsg_providers[] = {
|
|
|
|
|
NULL, /* no message type defined for value 0 */
|
|
|
|
|
NULL, /* no message type defined for value 1 */
|
2021-12-16 09:13:27 +00:00
|
|
|
adf_pf_capabilities_msg_provider, /* ADF_VF2PF_BLKMSG_REQ_CAP_SUMMARY */
|
2021-12-16 09:13:29 +00:00
|
|
|
adf_pf_ring_to_svc_msg_provider, /* ADF_VF2PF_BLKMSG_REQ_RING_SVC_MAP */
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
};
|
2021-09-28 11:44:36 +00:00
|
|
|
|
2021-09-28 11:44:38 +00:00
|
|
|
/**
|
|
|
|
|
* adf_send_pf2vf_msg() - send PF to VF message
|
|
|
|
|
* @accel_dev: Pointer to acceleration device
|
|
|
|
|
* @vf_nr: VF number to which the message will be sent
|
|
|
|
|
* @msg: Message to send
|
|
|
|
|
*
|
|
|
|
|
* This function allows the PF to send a message to a specific VF.
|
|
|
|
|
*
|
|
|
|
|
* Return: 0 on success, error code otherwise.
|
|
|
|
|
*/
|
2021-12-16 09:13:20 +00:00
|
|
|
int adf_send_pf2vf_msg(struct adf_accel_dev *accel_dev, u8 vf_nr, struct pfvf_message msg)
|
2021-09-28 11:44:38 +00:00
|
|
|
{
|
2021-12-16 09:13:18 +00:00
|
|
|
struct adf_pfvf_ops *pfvf_ops = GET_PFVF_OPS(accel_dev);
|
|
|
|
|
u32 pfvf_offset = pfvf_ops->get_pf2vf_offset(vf_nr);
|
|
|
|
|
|
|
|
|
|
return pfvf_ops->send_msg(accel_dev, msg, pfvf_offset,
|
|
|
|
|
&accel_dev->pf.vf_info[vf_nr].pf2vf_lock);
|
2021-09-28 11:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
2021-11-17 14:30:50 +00:00
|
|
|
/**
|
|
|
|
|
* adf_recv_vf2pf_msg() - receive a VF to PF message
|
|
|
|
|
* @accel_dev: Pointer to acceleration device
|
|
|
|
|
* @vf_nr: Number of the VF from where the message will be received
|
|
|
|
|
*
|
|
|
|
|
* This function allows the PF to receive a message from a specific VF.
|
|
|
|
|
*
|
|
|
|
|
* Return: a valid message on success, zero otherwise.
|
|
|
|
|
*/
|
2021-12-16 09:13:20 +00:00
|
|
|
static struct pfvf_message adf_recv_vf2pf_msg(struct adf_accel_dev *accel_dev, u8 vf_nr)
|
2021-11-17 14:30:50 +00:00
|
|
|
{
|
crypto: qat - support fast ACKs in the PFVF protocol
The original design and current implementation of the PFVF protocol
expects the sender to both acquire and relinquish the ownership of the
shared CSR by setting and clearing the "in use" pattern on the remote
half of the register when sending a message. This happens regardless of
the acknowledgment of the reception, to guarantee changes, including
collisions, are surely detected.
However, in the case of a request that requires a response, collisions
can also be detected by the lack of a reply. This can be exploited to
speed up and simplify the above behaviour, letting the receiver both
acknowledge the message and release the CSR in a single transaction:
1) the sender can return as soon as the message has been acknowledged
2) the receiver doesn't have to wait long before acquiring ownership
of the CSR for the response message, greatly improving the overall
throughput.
Howerver, this improvement cannot be leveraged for fire-and-forget
notifications, as it would be impossible for the sender to clearly
distinguish between a collision and an ack immediately followed by a new
message.
This patch implements this optimization in a new version of the protocol
(v3), which applies the fast-ack logic only whenever possible and
guarantees backward compatibility with older versions. For requests, a
new retry loop guarantees a correct behaviour.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:28 +00:00
|
|
|
struct adf_accel_vf_info *vf_info = &accel_dev->pf.vf_info[vf_nr];
|
2021-12-16 09:13:18 +00:00
|
|
|
struct adf_pfvf_ops *pfvf_ops = GET_PFVF_OPS(accel_dev);
|
|
|
|
|
u32 pfvf_offset = pfvf_ops->get_vf2pf_offset(vf_nr);
|
|
|
|
|
|
crypto: qat - support fast ACKs in the PFVF protocol
The original design and current implementation of the PFVF protocol
expects the sender to both acquire and relinquish the ownership of the
shared CSR by setting and clearing the "in use" pattern on the remote
half of the register when sending a message. This happens regardless of
the acknowledgment of the reception, to guarantee changes, including
collisions, are surely detected.
However, in the case of a request that requires a response, collisions
can also be detected by the lack of a reply. This can be exploited to
speed up and simplify the above behaviour, letting the receiver both
acknowledge the message and release the CSR in a single transaction:
1) the sender can return as soon as the message has been acknowledged
2) the receiver doesn't have to wait long before acquiring ownership
of the CSR for the response message, greatly improving the overall
throughput.
Howerver, this improvement cannot be leveraged for fire-and-forget
notifications, as it would be impossible for the sender to clearly
distinguish between a collision and an ack immediately followed by a new
message.
This patch implements this optimization in a new version of the protocol
(v3), which applies the fast-ack logic only whenever possible and
guarantees backward compatibility with older versions. For requests, a
new retry loop guarantees a correct behaviour.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:28 +00:00
|
|
|
return pfvf_ops->recv_msg(accel_dev, pfvf_offset, vf_info->vf_compat_ver);
|
2021-11-17 14:30:50 +00:00
|
|
|
}
|
|
|
|
|
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
static adf_pf2vf_blkmsg_provider get_blkmsg_response_provider(u8 type)
|
|
|
|
|
{
|
|
|
|
|
if (type >= ARRAY_SIZE(pf2vf_blkmsg_providers))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return pf2vf_blkmsg_providers[type];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Byte pf2vf_blkmsg_data_getter_fn callback */
|
|
|
|
|
static u8 adf_pf2vf_blkmsg_get_byte(u8 const *blkmsg, u8 index)
|
|
|
|
|
{
|
|
|
|
|
return blkmsg[index];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* CRC pf2vf_blkmsg_data_getter_fn callback */
|
|
|
|
|
static u8 adf_pf2vf_blkmsg_get_crc(u8 const *blkmsg, u8 count)
|
|
|
|
|
{
|
|
|
|
|
/* count is 0-based, turn it into a length */
|
|
|
|
|
return adf_pfvf_calc_blkmsg_crc(blkmsg, count + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int adf_pf2vf_blkmsg_get_data(struct adf_accel_vf_info *vf_info,
|
|
|
|
|
u8 type, u8 byte, u8 max_size, u8 *data,
|
|
|
|
|
pf2vf_blkmsg_data_getter_fn data_getter)
|
|
|
|
|
{
|
|
|
|
|
u8 blkmsg[ADF_PFVF_BLKMSG_MSG_MAX_SIZE] = { 0 };
|
|
|
|
|
struct adf_accel_dev *accel_dev = vf_info->accel_dev;
|
|
|
|
|
adf_pf2vf_blkmsg_provider provider;
|
|
|
|
|
u8 msg_size;
|
|
|
|
|
|
|
|
|
|
provider = get_blkmsg_response_provider(type);
|
|
|
|
|
|
|
|
|
|
if (unlikely(!provider)) {
|
|
|
|
|
pr_err("QAT: No registered provider for message %d\n", type);
|
|
|
|
|
*data = ADF_PF2VF_INVALID_BLOCK_TYPE;
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (unlikely((*provider)(accel_dev, blkmsg, vf_info->vf_compat_ver))) {
|
|
|
|
|
pr_err("QAT: unknown error from provider for message %d\n", type);
|
|
|
|
|
*data = ADF_PF2VF_UNSPECIFIED_ERROR;
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
msg_size = ADF_PFVF_BLKMSG_HEADER_SIZE + blkmsg[ADF_PFVF_BLKMSG_LEN_BYTE];
|
|
|
|
|
|
|
|
|
|
if (unlikely(msg_size >= max_size)) {
|
|
|
|
|
pr_err("QAT: Invalid size %d provided for message type %d\n",
|
|
|
|
|
msg_size, type);
|
|
|
|
|
*data = ADF_PF2VF_PAYLOAD_TRUNCATED;
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (unlikely(byte >= msg_size)) {
|
|
|
|
|
pr_err("QAT: Out-of-bound byte number %d (msg size %d)\n",
|
|
|
|
|
byte, msg_size);
|
|
|
|
|
*data = ADF_PF2VF_INVALID_BYTE_NUM_REQ;
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*data = data_getter(blkmsg, byte);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct pfvf_message handle_blkmsg_req(struct adf_accel_vf_info *vf_info,
|
|
|
|
|
struct pfvf_message req)
|
|
|
|
|
{
|
|
|
|
|
u8 resp_type = ADF_PF2VF_BLKMSG_RESP_TYPE_ERROR;
|
|
|
|
|
struct pfvf_message resp = { 0 };
|
|
|
|
|
u8 resp_data = 0;
|
|
|
|
|
u8 blk_type;
|
|
|
|
|
u8 blk_byte;
|
|
|
|
|
u8 byte_max;
|
|
|
|
|
|
|
|
|
|
switch (req.type) {
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_LARGE_BLOCK_REQ:
|
|
|
|
|
blk_type = FIELD_GET(ADF_VF2PF_LARGE_BLOCK_TYPE_MASK, req.data)
|
|
|
|
|
+ ADF_VF2PF_MEDIUM_BLOCK_TYPE_MAX + 1;
|
|
|
|
|
blk_byte = FIELD_GET(ADF_VF2PF_LARGE_BLOCK_BYTE_MASK, req.data);
|
|
|
|
|
byte_max = ADF_VF2PF_LARGE_BLOCK_BYTE_MAX;
|
|
|
|
|
break;
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_MEDIUM_BLOCK_REQ:
|
|
|
|
|
blk_type = FIELD_GET(ADF_VF2PF_MEDIUM_BLOCK_TYPE_MASK, req.data)
|
|
|
|
|
+ ADF_VF2PF_SMALL_BLOCK_TYPE_MAX + 1;
|
|
|
|
|
blk_byte = FIELD_GET(ADF_VF2PF_MEDIUM_BLOCK_BYTE_MASK, req.data);
|
|
|
|
|
byte_max = ADF_VF2PF_MEDIUM_BLOCK_BYTE_MAX;
|
|
|
|
|
break;
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_SMALL_BLOCK_REQ:
|
|
|
|
|
blk_type = FIELD_GET(ADF_VF2PF_SMALL_BLOCK_TYPE_MASK, req.data);
|
|
|
|
|
blk_byte = FIELD_GET(ADF_VF2PF_SMALL_BLOCK_BYTE_MASK, req.data);
|
|
|
|
|
byte_max = ADF_VF2PF_SMALL_BLOCK_BYTE_MAX;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Is this a request for CRC or data? */
|
|
|
|
|
if (FIELD_GET(ADF_VF2PF_BLOCK_CRC_REQ_MASK, req.data)) {
|
|
|
|
|
dev_dbg(&GET_DEV(vf_info->accel_dev),
|
|
|
|
|
"BlockMsg of type %d for CRC over %d bytes received from VF%d\n",
|
2022-04-07 16:54:50 +00:00
|
|
|
blk_type, blk_byte + 1, vf_info->vf_nr);
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
|
|
|
|
|
if (!adf_pf2vf_blkmsg_get_data(vf_info, blk_type, blk_byte,
|
|
|
|
|
byte_max, &resp_data,
|
|
|
|
|
adf_pf2vf_blkmsg_get_crc))
|
|
|
|
|
resp_type = ADF_PF2VF_BLKMSG_RESP_TYPE_CRC;
|
|
|
|
|
} else {
|
|
|
|
|
dev_dbg(&GET_DEV(vf_info->accel_dev),
|
|
|
|
|
"BlockMsg of type %d for data byte %d received from VF%d\n",
|
|
|
|
|
blk_type, blk_byte, vf_info->vf_nr);
|
|
|
|
|
|
|
|
|
|
if (!adf_pf2vf_blkmsg_get_data(vf_info, blk_type, blk_byte,
|
|
|
|
|
byte_max, &resp_data,
|
|
|
|
|
adf_pf2vf_blkmsg_get_byte))
|
|
|
|
|
resp_type = ADF_PF2VF_BLKMSG_RESP_TYPE_DATA;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
resp.type = ADF_PF2VF_MSGTYPE_BLKMSG_RESP;
|
|
|
|
|
resp.data = FIELD_PREP(ADF_PF2VF_BLKMSG_RESP_TYPE_MASK, resp_type) |
|
|
|
|
|
FIELD_PREP(ADF_PF2VF_BLKMSG_RESP_DATA_MASK, resp_data);
|
|
|
|
|
|
|
|
|
|
return resp;
|
|
|
|
|
}
|
|
|
|
|
|
2021-12-16 09:13:32 +00:00
|
|
|
static struct pfvf_message handle_rp_reset_req(struct adf_accel_dev *accel_dev, u8 vf_nr,
|
|
|
|
|
struct pfvf_message req)
|
|
|
|
|
{
|
|
|
|
|
struct adf_hw_device_data *hw_data = accel_dev->hw_device;
|
|
|
|
|
struct pfvf_message resp = {
|
|
|
|
|
.type = ADF_PF2VF_MSGTYPE_RP_RESET_RESP,
|
|
|
|
|
.data = RPRESET_SUCCESS
|
|
|
|
|
};
|
|
|
|
|
u32 bank_number;
|
|
|
|
|
u32 rsvd_field;
|
|
|
|
|
|
|
|
|
|
bank_number = FIELD_GET(ADF_VF2PF_RNG_RESET_RP_MASK, req.data);
|
|
|
|
|
rsvd_field = FIELD_GET(ADF_VF2PF_RNG_RESET_RSVD_MASK, req.data);
|
|
|
|
|
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
|
|
|
|
"Ring Pair Reset Message received from VF%d for bank 0x%x\n",
|
|
|
|
|
vf_nr, bank_number);
|
|
|
|
|
|
|
|
|
|
if (!hw_data->ring_pair_reset || rsvd_field) {
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
|
|
|
|
"Ring Pair Reset for VF%d is not supported\n", vf_nr);
|
|
|
|
|
resp.data = RPRESET_NOT_SUPPORTED;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (bank_number >= hw_data->num_banks_per_vf) {
|
|
|
|
|
dev_err(&GET_DEV(accel_dev),
|
|
|
|
|
"Invalid bank number (0x%x) from VF%d for Ring Reset\n",
|
|
|
|
|
bank_number, vf_nr);
|
|
|
|
|
resp.data = RPRESET_INVAL_BANK;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Convert the VF provided value to PF bank number */
|
|
|
|
|
bank_number = vf_nr * hw_data->num_banks_per_vf + bank_number;
|
|
|
|
|
if (hw_data->ring_pair_reset(accel_dev, bank_number)) {
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
|
|
|
|
"Ring pair reset for VF%d failure\n", vf_nr);
|
|
|
|
|
resp.data = RPRESET_TIMEOUT;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
|
|
|
|
"Ring pair reset for VF%d successfully\n", vf_nr);
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
return resp;
|
|
|
|
|
}
|
|
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
static int adf_handle_vf2pf_msg(struct adf_accel_dev *accel_dev, u8 vf_nr,
|
|
|
|
|
struct pfvf_message msg, struct pfvf_message *resp)
|
2015-08-24 18:56:02 +00:00
|
|
|
{
|
2021-11-17 14:30:39 +00:00
|
|
|
struct adf_accel_vf_info *vf_info = &accel_dev->pf.vf_info[vf_nr];
|
2021-11-17 14:30:40 +00:00
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
switch (msg.type) {
|
2015-08-24 18:56:02 +00:00
|
|
|
case ADF_VF2PF_MSGTYPE_COMPAT_VER_REQ:
|
|
|
|
|
{
|
2021-12-16 09:13:20 +00:00
|
|
|
u8 vf_compat_ver = msg.data;
|
2021-11-17 14:30:55 +00:00
|
|
|
u8 compat;
|
2015-08-24 18:56:02 +00:00
|
|
|
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
2021-11-17 14:30:58 +00:00
|
|
|
"VersionRequest received from VF%d (vers %d) to PF (vers %d)\n",
|
|
|
|
|
vf_nr, vf_compat_ver, ADF_PFVF_COMPAT_THIS_VERSION);
|
2015-08-24 18:56:02 +00:00
|
|
|
|
2022-04-07 16:54:47 +00:00
|
|
|
if (vf_compat_ver == 0)
|
|
|
|
|
compat = ADF_PF2VF_VF_INCOMPATIBLE;
|
|
|
|
|
else if (vf_compat_ver <= ADF_PFVF_COMPAT_THIS_VERSION)
|
2021-11-17 14:30:56 +00:00
|
|
|
compat = ADF_PF2VF_VF_COMPATIBLE;
|
2021-11-17 14:30:58 +00:00
|
|
|
else
|
2021-11-17 14:30:56 +00:00
|
|
|
compat = ADF_PF2VF_VF_COMPAT_UNKNOWN;
|
2021-11-17 14:30:55 +00:00
|
|
|
|
2021-12-16 09:13:24 +00:00
|
|
|
vf_info->vf_compat_ver = vf_compat_ver;
|
|
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
resp->type = ADF_PF2VF_MSGTYPE_VERSION_RESP;
|
2021-12-16 09:13:21 +00:00
|
|
|
resp->data = FIELD_PREP(ADF_PF2VF_VERSION_RESP_VERS_MASK,
|
|
|
|
|
ADF_PFVF_COMPAT_THIS_VERSION) |
|
|
|
|
|
FIELD_PREP(ADF_PF2VF_VERSION_RESP_RESULT_MASK, compat);
|
2015-08-24 18:56:02 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_VERSION_REQ:
|
2021-11-17 14:30:55 +00:00
|
|
|
{
|
|
|
|
|
u8 compat;
|
|
|
|
|
|
2015-08-24 18:56:02 +00:00
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
2021-11-17 14:30:58 +00:00
|
|
|
"Legacy VersionRequest received from VF%d to PF (vers 1.1)\n",
|
|
|
|
|
vf_nr);
|
2021-11-17 14:30:55 +00:00
|
|
|
|
2021-12-16 09:13:24 +00:00
|
|
|
/* legacy driver, VF compat_ver is 0 */
|
|
|
|
|
vf_info->vf_compat_ver = 0;
|
|
|
|
|
|
2021-11-17 14:30:55 +00:00
|
|
|
/* PF always newer than legacy VF */
|
|
|
|
|
compat = ADF_PF2VF_VF_COMPATIBLE;
|
|
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
/* Set legacy major and minor version to the latest, 1.1 */
|
2021-12-16 09:13:21 +00:00
|
|
|
resp->type = ADF_PF2VF_MSGTYPE_VERSION_RESP;
|
|
|
|
|
resp->data = FIELD_PREP(ADF_PF2VF_VERSION_RESP_VERS_MASK, 0x11) |
|
|
|
|
|
FIELD_PREP(ADF_PF2VF_VERSION_RESP_RESULT_MASK, compat);
|
2021-11-17 14:30:55 +00:00
|
|
|
}
|
2015-08-24 18:56:02 +00:00
|
|
|
break;
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_INIT:
|
|
|
|
|
{
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
2021-11-17 14:30:58 +00:00
|
|
|
"Init message received from VF%d\n", vf_nr);
|
2015-08-24 18:56:02 +00:00
|
|
|
vf_info->init = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_SHUTDOWN:
|
|
|
|
|
{
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
2021-11-17 14:30:58 +00:00
|
|
|
"Shutdown message received from VF%d\n", vf_nr);
|
2015-08-24 18:56:02 +00:00
|
|
|
vf_info->init = false;
|
|
|
|
|
}
|
|
|
|
|
break;
|
2024-02-02 10:53:19 +00:00
|
|
|
case ADF_VF2PF_MSGTYPE_RESTARTING_COMPLETE:
|
|
|
|
|
{
|
|
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
|
|
|
|
"Restarting Complete received from VF%d\n", vf_nr);
|
|
|
|
|
vf_info->restarting = false;
|
|
|
|
|
vf_info->init = false;
|
|
|
|
|
}
|
|
|
|
|
break;
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
case ADF_VF2PF_MSGTYPE_LARGE_BLOCK_REQ:
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_MEDIUM_BLOCK_REQ:
|
|
|
|
|
case ADF_VF2PF_MSGTYPE_SMALL_BLOCK_REQ:
|
|
|
|
|
*resp = handle_blkmsg_req(vf_info, msg);
|
|
|
|
|
break;
|
2021-12-16 09:13:32 +00:00
|
|
|
case ADF_VF2PF_MSGTYPE_RP_RESET:
|
|
|
|
|
*resp = handle_rp_reset_req(accel_dev, vf_nr, msg);
|
|
|
|
|
break;
|
2015-08-24 18:56:02 +00:00
|
|
|
default:
|
2021-12-16 09:13:20 +00:00
|
|
|
dev_dbg(&GET_DEV(accel_dev),
|
|
|
|
|
"Unknown message from VF%d (type 0x%.4x, data: 0x%.4x)\n",
|
|
|
|
|
vf_nr, msg.type, msg.data);
|
2021-11-17 14:30:42 +00:00
|
|
|
return -ENOMSG;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool adf_recv_and_handle_vf2pf_msg(struct adf_accel_dev *accel_dev, u32 vf_nr)
|
|
|
|
|
{
|
2021-12-16 09:13:20 +00:00
|
|
|
struct pfvf_message req;
|
|
|
|
|
struct pfvf_message resp = {0};
|
2021-11-17 14:30:42 +00:00
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
req = adf_recv_vf2pf_msg(accel_dev, vf_nr);
|
|
|
|
|
if (!req.type) /* Legacy or no message */
|
2021-11-17 14:30:42 +00:00
|
|
|
return true;
|
|
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
if (adf_handle_vf2pf_msg(accel_dev, vf_nr, req, &resp))
|
2021-11-17 14:30:42 +00:00
|
|
|
return false;
|
|
|
|
|
|
2021-12-16 09:13:20 +00:00
|
|
|
if (resp.type && adf_send_pf2vf_msg(accel_dev, vf_nr, resp))
|
2021-11-17 14:30:58 +00:00
|
|
|
dev_err(&GET_DEV(accel_dev),
|
|
|
|
|
"Failed to send response to VF%d\n", vf_nr);
|
2015-08-24 18:56:02 +00:00
|
|
|
|
2021-11-17 14:30:39 +00:00
|
|
|
return true;
|
2015-08-24 18:56:02 +00:00
|
|
|
}
|
|
|
|
|
|
2021-09-28 11:44:40 +00:00
|
|
|
/**
|
|
|
|
|
* adf_enable_pf2vf_comms() - Function enables communication from pf to vf
|
|
|
|
|
*
|
|
|
|
|
* @accel_dev: Pointer to acceleration device virtual function.
|
|
|
|
|
*
|
|
|
|
|
* This function carries out the necessary steps to setup and start the PFVF
|
|
|
|
|
* communication channel, if any.
|
|
|
|
|
*
|
|
|
|
|
* Return: 0 on success, error code otherwise.
|
|
|
|
|
*/
|
|
|
|
|
int adf_enable_pf2vf_comms(struct adf_accel_dev *accel_dev)
|
|
|
|
|
{
|
crypto: qat - introduce support for PFVF block messages
GEN2 devices use a single CSR for PFVF messages, which leaves up to 10 bits
of payload per single message. While such amount is sufficient for the
currently defined messages, the transfer of bigger and more complex data
streams from the PF to the VF requires a new mechanism that extends the
protocol.
This patch adds a new layer on top of the basic PFVF messaging, called
Block Messages, to encapsulate up to 126 bytes of data in a single
logical message across multiple PFVF messages of new types (SMALL,
MEDIUM and LARGE BLOCK), including (sub)types (BLKMSG_TYPE) to carry the
information about the actual Block Message.
Regardless of the size, each Block Message uses a two bytes header,
containing the version and size, to allow for extension while
maintaining compatibility. The size and the types of Block Messages are
defined as follow:
- small block messages: up to 16 BLKMSG types of up to 30 bytes
- medium block messages: up to 8 BLKMSG types of up to 62 bytes
- large block messages: up to 4 BLKMSG types of up to 126 bytes
It effectively works as reading a byte at a time from a block device and
for each of these new Block Messages:
- the requestor (always a VF) can either request a specific byte of the
larger message, in order to retrieve the full message, or request the
value of the CRC calculated for a specific message up to the provided
size (to allow for messages to grow while maintaining forward
compatibility)
- the responder (always the PF) will either return a single data or CRC
byte, along with the indication of response type (or error).
This patch provides the basic infrastructure to perform the above
operations, without defining any new message.
As CRCs are required, this code now depends on the CRC8 module.
Note: as a consequence of the Block Messages design, sending multiple
PFVF messages in bursts, the interrupt rate limiting values on the PF are
increased.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-12-16 09:13:26 +00:00
|
|
|
adf_pfvf_crc_init();
|
2021-09-28 11:44:40 +00:00
|
|
|
spin_lock_init(&accel_dev->pf.vf2pf_ints_lock);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(adf_enable_pf2vf_comms);
|