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 */
|
|
|
|
#ifndef ADF_PFVF_MSG_H
|
|
|
|
#define ADF_PFVF_MSG_H
|
2015-08-07 18:34:25 +00:00
|
|
|
|
2021-12-16 09:13:21 +00:00
|
|
|
#include <linux/bits.h>
|
|
|
|
|
2015-08-07 18:34:25 +00:00
|
|
|
/*
|
2021-12-16 09:13:31 +00:00
|
|
|
* PF<->VF Gen2 Messaging format
|
|
|
|
*
|
2015-08-07 18:34:25 +00:00
|
|
|
* The PF has an array of 32-bit PF2VF registers, one for each VF. The
|
|
|
|
* PF can access all these registers; each VF can access only the one
|
|
|
|
* register associated with that particular VF.
|
|
|
|
*
|
|
|
|
* The register functionally is split into two parts:
|
|
|
|
* The bottom half is for PF->VF messages. In particular when the first
|
|
|
|
* bit of this register (bit 0) gets set an interrupt will be triggered
|
|
|
|
* in the respective VF.
|
|
|
|
* The top half is for VF->PF messages. In particular when the first bit
|
|
|
|
* of this half of register (bit 16) gets set an interrupt will be triggered
|
|
|
|
* in the PF.
|
|
|
|
*
|
|
|
|
* The remaining bits within this register are available to encode messages.
|
|
|
|
* and implement a collision control mechanism to prevent concurrent use of
|
|
|
|
* the PF2VF register by both the PF and VF.
|
|
|
|
*
|
|
|
|
* 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
|
|
|
|
* _______________________________________________
|
|
|
|
* | | | | | | | | | | | | | | | | |
|
|
|
|
* +-----------------------------------------------+
|
|
|
|
* \___________________________/ \_________/ ^ ^
|
|
|
|
* ^ ^ | |
|
|
|
|
* | | | VF2PF Int
|
|
|
|
* | | Message Origin
|
|
|
|
* | Message Type
|
|
|
|
* Message-specific Data/Reserved
|
|
|
|
*
|
|
|
|
* 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
|
|
|
* _______________________________________________
|
|
|
|
* | | | | | | | | | | | | | | | | |
|
|
|
|
* +-----------------------------------------------+
|
|
|
|
* \___________________________/ \_________/ ^ ^
|
|
|
|
* ^ ^ | |
|
|
|
|
* | | | PF2VF Int
|
|
|
|
* | | Message Origin
|
|
|
|
* | Message Type
|
|
|
|
* Message-specific Data/Reserved
|
|
|
|
*
|
|
|
|
* Message Origin (Should always be 1)
|
|
|
|
* A legacy out-of-tree QAT driver allowed for a set of messages not supported
|
|
|
|
* by this driver; these had a Msg Origin of 0 and are ignored by this driver.
|
|
|
|
*
|
|
|
|
* When a PF or VF attempts to send a message in the lower or upper 16 bits,
|
|
|
|
* respectively, the other 16 bits are written to first with a defined
|
2021-11-17 14:30:49 +00:00
|
|
|
* IN_USE_BY pattern as part of a collision control scheme (see function
|
|
|
|
* adf_gen2_pfvf_send() in adf_pf2vf_msg.c).
|
2021-12-16 09:13:31 +00:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* PF<->VF Gen4 Messaging format
|
|
|
|
*
|
|
|
|
* Similarly to the gen2 messaging format, 32-bit long registers are used for
|
|
|
|
* communication between PF and VFs. However, each VF and PF share a pair of
|
|
|
|
* 32-bits register to avoid collisions: one for PV to VF messages and one
|
|
|
|
* for VF to PF messages.
|
|
|
|
*
|
|
|
|
* Both the Interrupt bit and the Message Origin bit retain the same position
|
|
|
|
* and meaning, although non-system messages are now deprecated and not
|
|
|
|
* expected.
|
|
|
|
*
|
|
|
|
* 31 30 9 8 7 6 5 4 3 2 1 0
|
|
|
|
* _______________________________________________
|
|
|
|
* | | | . . . | | | | | | | | | | |
|
|
|
|
* +-----------------------------------------------+
|
|
|
|
* \_____________________/ \_______________/ ^ ^
|
|
|
|
* ^ ^ | |
|
|
|
|
* | | | PF/VF Int
|
|
|
|
* | | Message Origin
|
|
|
|
* | Message Type
|
|
|
|
* Message-specific Data/Reserved
|
|
|
|
*
|
|
|
|
* For both formats, the message reception is acknowledged by lowering the
|
|
|
|
* interrupt bit on the register where the message was sent.
|
2015-08-07 18:34:25 +00:00
|
|
|
*/
|
|
|
|
|
2021-12-16 09:13:17 +00:00
|
|
|
/* PFVF message common bits */
|
|
|
|
#define ADF_PFVF_INT BIT(0)
|
|
|
|
#define ADF_PFVF_MSGORIGIN_SYSTEM BIT(1)
|
2021-12-16 09:13:20 +00:00
|
|
|
|
|
|
|
/* Different generations have different CSR layouts, use this struct
|
|
|
|
* to abstract these differences away
|
|
|
|
*/
|
|
|
|
struct pfvf_message {
|
|
|
|
u8 type;
|
|
|
|
u32 data;
|
|
|
|
};
|
2021-11-17 14:30:53 +00:00
|
|
|
|
2021-12-16 09:13:17 +00:00
|
|
|
/* PF->VF messages */
|
2021-11-17 14:30:53 +00:00
|
|
|
enum pf2vf_msgtype {
|
|
|
|
ADF_PF2VF_MSGTYPE_RESTARTING = 0x01,
|
|
|
|
ADF_PF2VF_MSGTYPE_VERSION_RESP = 0x02,
|
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_PF2VF_MSGTYPE_BLKMSG_RESP = 0x03,
|
2021-12-16 09:13:32 +00:00
|
|
|
/* Values from 0x10 are Gen4 specific, message type is only 4 bits in Gen2 devices. */
|
|
|
|
ADF_PF2VF_MSGTYPE_RP_RESET_RESP = 0x10,
|
2021-11-17 14:30:53 +00:00
|
|
|
};
|
2015-08-07 18:34:25 +00:00
|
|
|
|
|
|
|
/* VF->PF messages */
|
2021-11-17 14:30:53 +00:00
|
|
|
enum vf2pf_msgtype {
|
|
|
|
ADF_VF2PF_MSGTYPE_INIT = 0x03,
|
|
|
|
ADF_VF2PF_MSGTYPE_SHUTDOWN = 0x04,
|
|
|
|
ADF_VF2PF_MSGTYPE_VERSION_REQ = 0x05,
|
|
|
|
ADF_VF2PF_MSGTYPE_COMPAT_VER_REQ = 0x06,
|
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_VF2PF_MSGTYPE_LARGE_BLOCK_REQ = 0x07,
|
|
|
|
ADF_VF2PF_MSGTYPE_MEDIUM_BLOCK_REQ = 0x08,
|
|
|
|
ADF_VF2PF_MSGTYPE_SMALL_BLOCK_REQ = 0x09,
|
2021-12-16 09:13:32 +00:00
|
|
|
/* Values from 0x10 are Gen4 specific, message type is only 4 bits in Gen2 devices. */
|
|
|
|
ADF_VF2PF_MSGTYPE_RP_RESET = 0x10,
|
2021-11-17 14:30:53 +00:00
|
|
|
};
|
2015-08-07 18:34:25 +00:00
|
|
|
|
2021-11-17 14:30:52 +00:00
|
|
|
/* VF/PF compatibility version. */
|
2021-11-17 14:30:53 +00:00
|
|
|
enum pfvf_compatibility_version {
|
2021-12-16 09:13:27 +00:00
|
|
|
/* Support for extended capabilities */
|
|
|
|
ADF_PFVF_COMPAT_CAPABILITIES = 0x02,
|
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
|
|
|
/* In-use pattern cleared by receiver */
|
|
|
|
ADF_PFVF_COMPAT_FAST_ACK = 0x03,
|
2021-12-16 09:13:29 +00:00
|
|
|
/* Ring to service mapping support for non-standard mappings */
|
|
|
|
ADF_PFVF_COMPAT_RING_TO_SVC_MAP = 0x04,
|
2021-12-16 09:13:27 +00:00
|
|
|
/* Reference to the latest version */
|
2021-12-16 09:13:29 +00:00
|
|
|
ADF_PFVF_COMPAT_THIS_VERSION = 0x04,
|
2021-11-17 14:30:53 +00:00
|
|
|
};
|
2021-11-17 14:30:52 +00:00
|
|
|
|
|
|
|
/* PF->VF Version Response */
|
2021-12-16 09:13:21 +00:00
|
|
|
#define ADF_PF2VF_VERSION_RESP_VERS_MASK GENMASK(7, 0)
|
|
|
|
#define ADF_PF2VF_VERSION_RESP_RESULT_MASK GENMASK(9, 8)
|
2021-11-17 14:30:53 +00:00
|
|
|
|
|
|
|
enum pf2vf_compat_response {
|
|
|
|
ADF_PF2VF_VF_COMPATIBLE = 0x01,
|
|
|
|
ADF_PF2VF_VF_INCOMPATIBLE = 0x02,
|
|
|
|
ADF_PF2VF_VF_COMPAT_UNKNOWN = 0x03,
|
|
|
|
};
|
2021-11-17 14:30:52 +00:00
|
|
|
|
2021-12-16 09:13:32 +00:00
|
|
|
enum ring_reset_result {
|
2021-12-24 11:05:32 +00:00
|
|
|
RPRESET_SUCCESS = 0x00,
|
|
|
|
RPRESET_NOT_SUPPORTED = 0x01,
|
|
|
|
RPRESET_INVAL_BANK = 0x02,
|
|
|
|
RPRESET_TIMEOUT = 0x03,
|
2021-12-16 09:13:32 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define ADF_VF2PF_RNG_RESET_RP_MASK GENMASK(1, 0)
|
|
|
|
#define ADF_VF2PF_RNG_RESET_RSVD_MASK GENMASK(25, 2)
|
|
|
|
|
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
|
|
|
/* PF->VF Block Responses */
|
|
|
|
#define ADF_PF2VF_BLKMSG_RESP_TYPE_MASK GENMASK(1, 0)
|
|
|
|
#define ADF_PF2VF_BLKMSG_RESP_DATA_MASK GENMASK(9, 2)
|
|
|
|
|
|
|
|
enum pf2vf_blkmsg_resp_type {
|
|
|
|
ADF_PF2VF_BLKMSG_RESP_TYPE_DATA = 0x00,
|
|
|
|
ADF_PF2VF_BLKMSG_RESP_TYPE_CRC = 0x01,
|
|
|
|
ADF_PF2VF_BLKMSG_RESP_TYPE_ERROR = 0x02,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* PF->VF Block Error Code */
|
|
|
|
enum pf2vf_blkmsg_error {
|
|
|
|
ADF_PF2VF_INVALID_BLOCK_TYPE = 0x00,
|
|
|
|
ADF_PF2VF_INVALID_BYTE_NUM_REQ = 0x01,
|
|
|
|
ADF_PF2VF_PAYLOAD_TRUNCATED = 0x02,
|
|
|
|
ADF_PF2VF_UNSPECIFIED_ERROR = 0x03,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* VF->PF Block Requests */
|
|
|
|
#define ADF_VF2PF_LARGE_BLOCK_TYPE_MASK GENMASK(1, 0)
|
|
|
|
#define ADF_VF2PF_LARGE_BLOCK_BYTE_MASK GENMASK(8, 2)
|
|
|
|
#define ADF_VF2PF_MEDIUM_BLOCK_TYPE_MASK GENMASK(2, 0)
|
|
|
|
#define ADF_VF2PF_MEDIUM_BLOCK_BYTE_MASK GENMASK(8, 3)
|
|
|
|
#define ADF_VF2PF_SMALL_BLOCK_TYPE_MASK GENMASK(3, 0)
|
|
|
|
#define ADF_VF2PF_SMALL_BLOCK_BYTE_MASK GENMASK(8, 4)
|
|
|
|
#define ADF_VF2PF_BLOCK_CRC_REQ_MASK BIT(9)
|
|
|
|
|
|
|
|
/* PF->VF Block Request Types
|
|
|
|
* 0..15 - 32 byte message
|
|
|
|
* 16..23 - 64 byte message
|
|
|
|
* 24..27 - 128 byte message
|
|
|
|
*/
|
2021-12-16 09:13:27 +00:00
|
|
|
enum vf2pf_blkmsg_req_type {
|
|
|
|
ADF_VF2PF_BLKMSG_REQ_CAP_SUMMARY = 0x02,
|
2021-12-16 09:13:29 +00:00
|
|
|
ADF_VF2PF_BLKMSG_REQ_RING_SVC_MAP = 0x03,
|
2021-12-16 09:13:27 +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
|
|
|
|
|
|
|
#define ADF_VF2PF_SMALL_BLOCK_TYPE_MAX \
|
|
|
|
(FIELD_MAX(ADF_VF2PF_SMALL_BLOCK_TYPE_MASK))
|
|
|
|
|
|
|
|
#define ADF_VF2PF_MEDIUM_BLOCK_TYPE_MAX \
|
|
|
|
(FIELD_MAX(ADF_VF2PF_MEDIUM_BLOCK_TYPE_MASK) + \
|
|
|
|
ADF_VF2PF_SMALL_BLOCK_TYPE_MAX + 1)
|
|
|
|
|
|
|
|
#define ADF_VF2PF_LARGE_BLOCK_TYPE_MAX \
|
|
|
|
(FIELD_MAX(ADF_VF2PF_LARGE_BLOCK_TYPE_MASK) + \
|
|
|
|
ADF_VF2PF_MEDIUM_BLOCK_TYPE_MAX)
|
|
|
|
|
|
|
|
#define ADF_VF2PF_SMALL_BLOCK_BYTE_MAX \
|
|
|
|
FIELD_MAX(ADF_VF2PF_SMALL_BLOCK_BYTE_MASK)
|
|
|
|
|
|
|
|
#define ADF_VF2PF_MEDIUM_BLOCK_BYTE_MAX \
|
|
|
|
FIELD_MAX(ADF_VF2PF_MEDIUM_BLOCK_BYTE_MASK)
|
|
|
|
|
|
|
|
#define ADF_VF2PF_LARGE_BLOCK_BYTE_MAX \
|
|
|
|
FIELD_MAX(ADF_VF2PF_LARGE_BLOCK_BYTE_MASK)
|
|
|
|
|
|
|
|
struct pfvf_blkmsg_header {
|
|
|
|
u8 version;
|
|
|
|
u8 payload_size;
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
#define ADF_PFVF_BLKMSG_HEADER_SIZE (sizeof(struct pfvf_blkmsg_header))
|
|
|
|
#define ADF_PFVF_BLKMSG_PAYLOAD_SIZE(blkmsg) (sizeof(blkmsg) - \
|
|
|
|
ADF_PFVF_BLKMSG_HEADER_SIZE)
|
|
|
|
#define ADF_PFVF_BLKMSG_MSG_SIZE(blkmsg) (ADF_PFVF_BLKMSG_HEADER_SIZE + \
|
|
|
|
(blkmsg)->hdr.payload_size)
|
|
|
|
#define ADF_PFVF_BLKMSG_MSG_MAX_SIZE 128
|
|
|
|
|
|
|
|
/* PF->VF Block message header bytes */
|
|
|
|
#define ADF_PFVF_BLKMSG_VER_BYTE 0
|
|
|
|
#define ADF_PFVF_BLKMSG_LEN_BYTE 1
|
|
|
|
|
2021-12-16 09:13:27 +00:00
|
|
|
/* PF/VF Capabilities message values */
|
|
|
|
enum blkmsg_capabilities_versions {
|
|
|
|
ADF_PFVF_CAPABILITIES_V1_VERSION = 0x01,
|
|
|
|
ADF_PFVF_CAPABILITIES_V2_VERSION = 0x02,
|
|
|
|
ADF_PFVF_CAPABILITIES_V3_VERSION = 0x03,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct capabilities_v1 {
|
|
|
|
struct pfvf_blkmsg_header hdr;
|
|
|
|
u32 ext_dc_caps;
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
struct capabilities_v2 {
|
|
|
|
struct pfvf_blkmsg_header hdr;
|
|
|
|
u32 ext_dc_caps;
|
|
|
|
u32 capabilities;
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
struct capabilities_v3 {
|
|
|
|
struct pfvf_blkmsg_header hdr;
|
|
|
|
u32 ext_dc_caps;
|
|
|
|
u32 capabilities;
|
|
|
|
u32 frequency;
|
|
|
|
} __packed;
|
|
|
|
|
2021-12-16 09:13:29 +00:00
|
|
|
/* PF/VF Ring to service mapping values */
|
|
|
|
enum blkmsg_ring_to_svc_versions {
|
|
|
|
ADF_PFVF_RING_TO_SVC_VERSION = 0x01,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ring_to_svc_map_v1 {
|
|
|
|
struct pfvf_blkmsg_header hdr;
|
|
|
|
u16 map;
|
|
|
|
} __packed;
|
|
|
|
|
2021-11-17 14:30:51 +00:00
|
|
|
#endif /* ADF_PFVF_MSG_H */
|