linux.git/drivers/crypto/qat, branch v5.17

crypto: qat - fix definition of ring reset results

2021-12-31T07:10:56+00:00

The ring reset result values are defined starting from 0x1 instead of 0.
This causes out-of-tree drivers that support this message to understand
that a ring reset failed even if the operation was successful.

Fix by starting the definition of ring reset result values from 0.

Fixes: 0bba03ce9739 ("crypto: qat - add PFVF support to enable the reset of ring pairs")
Signed-off-by: Giovanni Cabiddu 
Reported-by: Adam Guerin 
Reviewed-by: Marco Chiappero 
Signed-off-by: Herbert Xu

crypto: qat - add support for compression for 4xxx

2021-12-24T03:18:27+00:00

Add the logic required to enable the compression service for 4xxx devices.
This allows to load the compression firmware image and report
the appropriate compression capabilities.

The firmware image selection for a given device is based on the
'ServicesEnabled' key stored in the internal configuration, which is
added statically at the probe of the device according to the following
rule, by default:
- odd numbered devices assigned to compression services
- even numbered devices assigned to crypto services

In addition, restore the 'ServicesEnabled' key, if present, when SRIOV
is enabled on the device.

Signed-off-by: Tomasz Kowalik 
Co-developed-by: Mateuszx Potrola 
Signed-off-by: Mateuszx Potrola 
Co-developed-by: Giovanni Cabiddu 
Signed-off-by: Giovanni Cabiddu 
Signed-off-by: Marco Chiappero 
Reviewed-by: Fiona Trahe 
Reviewed-by: Marco Chiappero 
Signed-off-by: Herbert Xu

crypto: qat - allow detection of dc capabilities for 4xxx

2021-12-24T03:18:27+00:00

Add logic to allow the detection of data compression capabilities for
4xxx devices.
The capability detection logic has been refactored to separate the
crypto capabilities from the compression ones.

This patch is not updating the returned capability mask as, up to now,
4xxx devices are configured only to handle crypto operations.

Signed-off-by: Giovanni Cabiddu 
Signed-off-by: Marco Chiappero 
Reviewed-by: Fiona Trahe 
Reviewed-by: Marco Chiappero 
Signed-off-by: Herbert Xu

crypto: qat - add PFVF support to enable the reset of ring pairs

2021-12-24T03:18:27+00:00

Extend support for resetting ring pairs on the device to VFs. Such
reset happens by sending a request to the PF over the PFVF protocol.

This patch defines two new PFVF messages and adds the PFVF logic for
handling the request on PF, triggering the reset, and VFs, accepting the
'success'/'error' response.

This feature is GEN4 specific.

This patch is based on earlier work done by Zelin Deng.

Signed-off-by: Marco Chiappero 
Reviewed-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu

crypto: qat - add PFVF support to the GEN4 host driver

2021-12-24T03:18:27+00:00

So far PFVF support for GEN4 devices has been kept effectively disabled
due to lack of support. This patch adds all the GEN4 specific logic to
make PFVF fully functional on PF.

Signed-off-by: Marco Chiappero 
Co-developed-by: Giovanni Cabiddu 
Signed-off-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu

crypto: qat - config VFs based on ring-to-svc mapping

2021-12-24T03:18:27+00:00

Change the configuration logic for the VF driver to leverage the
ring-to-service mappings now received via PFVF.

While the driver config logic is not yet capable of supporting
configurations other than the default mapping, make sure that both VF
and PF share the same default configuration in order to work properly.

Signed-off-by: Marco Chiappero 
Reviewed-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu

crypto: qat - exchange ring-to-service mappings over PFVF

2021-12-24T03:18:26+00:00

In addition to retrieving the device capabilities, a VF may also need to
retrieve the mapping of its ring pairs to crypto and or compression
services in order to work properly.

Make the VF receive the ring-to-service mappings from the PF by means of a
new REQ_RING_SVC_MAP Block Message and add the request and response
logic on VF and PF respectively. This change requires to bump the PFVF
protocol to version 4.

Signed-off-by: Marco Chiappero 
Reviewed-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu

crypto: qat - support fast ACKs in the PFVF protocol

2021-12-24T03:18:26+00:00

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 
Reviewed-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu

crypto: qat - exchange device capabilities over PFVF

2021-12-24T03:18:26+00:00

Allow the VF driver to get the supported device capabilities through PFVF,
by adding a new block message, the Capability Summary.

This messages allows to exchange the capability through masks, which
report, depending on the Capability Summary version, up to the following
information:
- algorithms and/or services that are supported by the device (e.g.
  symmetric crypto, data compression, etc.)
- (extended) compression capabilities, with details about the compression
  service (e.g. if compress and verify is supported by this device)
- the frequency of the device

This patch supports the latest Capabilities Summary version 3 for VFs,
but will limit support for the PF driver to version 2. This change also
increases the PFVF protocol to version 2.

Signed-off-by: Marco Chiappero 
Reviewed-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu

crypto: qat - introduce support for PFVF block messages

2021-12-24T03:18:26+00:00

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 
Co-developed-by: Giovanni Cabiddu 
Signed-off-by: Giovanni Cabiddu 
Reviewed-by: Fiona Trahe 
Signed-off-by: Herbert Xu