[ Upstream commit a238487f7965d102794ed9f8aff0b667cd2ae886 ]
The 4xxx drivers hardcode the ring to service mapping. However, when additional configurations where added to the driver, the mappings were not updated. This implies that an incorrect mapping might be reported through pfvf for certain configurations.
This is a backport of the upstream commit with modifications, as the original patch does not apply cleanly to kernel v6.1.x. The logic has been simplified to reflect the limited configurations of the QAT driver in this version: crypto-only and compression.
Instead of dynamically computing the ring to service mappings, these are now hardcoded to simplify the backport.
Fixes: 0cec19c761e5 ("crypto: qat - add support for compression for 4xxx") Signed-off-by: Giovanni Cabiddu giovanni.cabiddu@intel.com Reviewed-by: Damian Muszynski damian.muszynski@intel.com Reviewed-by: Tero Kristo tero.kristo@linux.intel.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Cc: stable@vger.kernel.org # 6.1.x Reviewed-by: Ahsan Atta ahsan.atta@intel.com Tested-by: Ahsan Atta ahsan.atta@intel.com --- drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c | 13 +++++++++++++ drivers/crypto/qat/qat_common/adf_accel_devices.h | 1 + drivers/crypto/qat/qat_common/adf_gen4_hw_data.h | 6 ++++++ drivers/crypto/qat/qat_common/adf_init.c | 3 +++ 4 files changed, 23 insertions(+)
diff --git a/drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c b/drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c index fda5f699ff57..65b52c692add 100644 --- a/drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c +++ b/drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c @@ -297,6 +297,18 @@ static char *uof_get_name(struct adf_accel_dev *accel_dev, u32 obj_num) return NULL; }
+static u16 get_ring_to_svc_map(struct adf_accel_dev *accel_dev) +{ + switch (get_service_enabled(accel_dev)) { + case SVC_CY: + return ADF_GEN4_DEFAULT_RING_TO_SRV_MAP; + case SVC_DC: + return ADF_GEN4_DEFAULT_RING_TO_SRV_MAP_DC; + } + + return 0; +} + static u32 uof_get_ae_mask(struct adf_accel_dev *accel_dev, u32 obj_num) { switch (get_service_enabled(accel_dev)) { @@ -353,6 +365,7 @@ void adf_init_hw_data_4xxx(struct adf_hw_device_data *hw_data) hw_data->uof_get_ae_mask = uof_get_ae_mask; hw_data->set_msix_rttable = set_msix_default_rttable; hw_data->set_ssm_wdtimer = adf_gen4_set_ssm_wdtimer; + hw_data->get_ring_to_svc_map = get_ring_to_svc_map; hw_data->disable_iov = adf_disable_sriov; hw_data->ring_pair_reset = adf_gen4_ring_pair_reset; hw_data->enable_pm = adf_gen4_enable_pm; diff --git a/drivers/crypto/qat/qat_common/adf_accel_devices.h b/drivers/crypto/qat/qat_common/adf_accel_devices.h index ad01d99e6e2b..7993d0f82dea 100644 --- a/drivers/crypto/qat/qat_common/adf_accel_devices.h +++ b/drivers/crypto/qat/qat_common/adf_accel_devices.h @@ -176,6 +176,7 @@ struct adf_hw_device_data { void (*get_arb_info)(struct arb_info *arb_csrs_info); void (*get_admin_info)(struct admin_info *admin_csrs_info); enum dev_sku_info (*get_sku)(struct adf_hw_device_data *self); + u16 (*get_ring_to_svc_map)(struct adf_accel_dev *accel_dev); int (*alloc_irq)(struct adf_accel_dev *accel_dev); void (*free_irq)(struct adf_accel_dev *accel_dev); void (*enable_error_correction)(struct adf_accel_dev *accel_dev); diff --git a/drivers/crypto/qat/qat_common/adf_gen4_hw_data.h b/drivers/crypto/qat/qat_common/adf_gen4_hw_data.h index 4fb4b3df5a18..5e653ec755e6 100644 --- a/drivers/crypto/qat/qat_common/adf_gen4_hw_data.h +++ b/drivers/crypto/qat/qat_common/adf_gen4_hw_data.h @@ -95,6 +95,12 @@ do { \ ADF_RING_BUNDLE_SIZE * (bank) + \ ADF_RING_CSR_RING_SRV_ARB_EN, (value))
+#define ADF_GEN4_DEFAULT_RING_TO_SRV_MAP_DC \ + (COMP << ADF_CFG_SERV_RING_PAIR_0_SHIFT | \ + COMP << ADF_CFG_SERV_RING_PAIR_1_SHIFT | \ + COMP << ADF_CFG_SERV_RING_PAIR_2_SHIFT | \ + COMP << ADF_CFG_SERV_RING_PAIR_3_SHIFT) + /* Default ring mapping */ #define ADF_GEN4_DEFAULT_RING_TO_SRV_MAP \ (ASYM << ADF_CFG_SERV_RING_PAIR_0_SHIFT | \ diff --git a/drivers/crypto/qat/qat_common/adf_init.c b/drivers/crypto/qat/qat_common/adf_init.c index 2e3481270c4b..49f07584f8c9 100644 --- a/drivers/crypto/qat/qat_common/adf_init.c +++ b/drivers/crypto/qat/qat_common/adf_init.c @@ -95,6 +95,9 @@ int adf_dev_init(struct adf_accel_dev *accel_dev) return -EFAULT; }
+ if (hw_data->get_ring_to_svc_map) + hw_data->ring_to_svc_map = hw_data->get_ring_to_svc_map(accel_dev); + if (adf_ae_init(accel_dev)) { dev_err(&GET_DEV(accel_dev), "Failed to initialise Acceleration Engine\n");
[ Sasha's backport helper bot ]
Hi,
Summary of potential issues: ⚠️ Found follow-up fixes in mainline
The upstream commit SHA1 provided is correct: a238487f7965d102794ed9f8aff0b667cd2ae886
Status in newer kernel trees: 6.15.y | Present (exact SHA1) 6.12.y | Present (exact SHA1) 6.6.y | Present (different SHA1: 82e4aa18bb6d)
Found fixes commits: df018f82002a crypto: qat - fix ring to service map for dcc in 4xxx
Note: The patch differs from the upstream commit: --- 1: a238487f7965 < -: ------------ crypto: qat - fix ring to service map for QAT GEN4 -: ------------ > 1: 1c3a13c46a06 crypto: qat - fix ring to service map for QAT GEN4
---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | origin/linux-6.1.y | Success | Success |
Hi Sasha,
On Thu, Jul 17, 2025 at 09:34:36PM -0400, Sasha Levin wrote:
[ Sasha's backport helper bot ]
Hi,
Summary of potential issues: ⚠️ Found follow-up fixes in mainline
The upstream commit SHA1 provided is correct: a238487f7965d102794ed9f8aff0b667cd2ae886
Status in newer kernel trees: 6.15.y | Present (exact SHA1) 6.12.y | Present (exact SHA1) 6.6.y | Present (different SHA1: 82e4aa18bb6d)
This patch applies only to the v6.1.y kernel, as it is already present in the other long-term stable branches.
Found fixes commits: df018f82002a crypto: qat - fix ring to service map for dcc in 4xxx
Regarding the follow-up fix:
df018f82002a crypto: qat - fix ring to service map for dcc in 4xxx
Not sending this to stable is intentional.
The QAT driver in v6.1 does not support the DCC (data compression chaining) service, which was introduced later in kernel v6.7 with commit 37b14f2dfa79 crypto: qat - enable dc chaining service.
The original fix (a238487f7965 crypto: qat - fix ring to service map for QAT GEN4) was supposed to address the problem also for DCC (as it landed after the introduction of that service), but did not. Therefore the follow-up fix df018f82002a was merged in kernel v6.9.
Hope this clarifies.
Note: The patch differs from the upstream commit:
1: a238487f7965 < -: ------------ crypto: qat - fix ring to service map for QAT GEN4 -: ------------ > 1: 1c3a13c46a06 crypto: qat - fix ring to service map for QAT GEN4
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | origin/linux-6.1.y | Success | Success |
Regards,
On Fri, Jul 18, 2025 at 07:54:35AM +0100, Giovanni Cabiddu wrote:
Hi Sasha,
On Thu, Jul 17, 2025 at 09:34:36PM -0400, Sasha Levin wrote:
[ Sasha's backport helper bot ]
Hi,
Summary of potential issues: ⚠️ Found follow-up fixes in mainline
The upstream commit SHA1 provided is correct: a238487f7965d102794ed9f8aff0b667cd2ae886
Status in newer kernel trees: 6.15.y | Present (exact SHA1) 6.12.y | Present (exact SHA1) 6.6.y | Present (different SHA1: 82e4aa18bb6d)
This patch applies only to the v6.1.y kernel, as it is already present in the other long-term stable branches.
Yup - this part just verifies that the patch exists in all never trees.
Found fixes commits: df018f82002a crypto: qat - fix ring to service map for dcc in 4xxx
Regarding the follow-up fix:
df018f82002a crypto: qat - fix ring to service map for dcc in 4xxx
Not sending this to stable is intentional.
The QAT driver in v6.1 does not support the DCC (data compression chaining) service, which was introduced later in kernel v6.7 with commit 37b14f2dfa79 crypto: qat - enable dc chaining service.
The original fix (a238487f7965 crypto: qat - fix ring to service map for QAT GEN4) was supposed to address the problem also for DCC (as it landed after the introduction of that service), but did not. Therefore the follow-up fix df018f82002a was merged in kernel v6.9.
Hope this clarifies.
That helps, thanks!
On Thu, Jul 17, 2025 at 06:06:38PM +0100, Giovanni Cabiddu wrote:
[ Upstream commit a238487f7965d102794ed9f8aff0b667cd2ae886 ]
The 4xxx drivers hardcode the ring to service mapping. However, when additional configurations where added to the driver, the mappings were not updated. This implies that an incorrect mapping might be reported through pfvf for certain configurations.
This is a backport of the upstream commit with modifications, as the original patch does not apply cleanly to kernel v6.1.x. The logic has been simplified to reflect the limited configurations of the QAT driver in this version: crypto-only and compression.
Instead of dynamically computing the ring to service mappings, these are now hardcoded to simplify the backport.
Fixes: 0cec19c761e5 ("crypto: qat - add support for compression for 4xxx") Signed-off-by: Giovanni Cabiddu giovanni.cabiddu@intel.com Reviewed-by: Damian Muszynski damian.muszynski@intel.com Reviewed-by: Tero Kristo tero.kristo@linux.intel.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Cc: stable@vger.kernel.org # 6.1.x Reviewed-by: Ahsan Atta ahsan.atta@intel.com Tested-by: Ahsan Atta ahsan.atta@intel.com
You did not mention anywhere what changed from the original commit (and it changed a lot...) So this looks to me like an incorrect backport, so I have to just delete it :(
Please fix up and send it again.
thanks,
greg k-h
On Tue, Jul 22, 2025 at 11:42:37AM +0200, Greg KH wrote:
On Thu, Jul 17, 2025 at 06:06:38PM +0100, Giovanni Cabiddu wrote:
[ Upstream commit a238487f7965d102794ed9f8aff0b667cd2ae886 ]
The 4xxx drivers hardcode the ring to service mapping. However, when additional configurations where added to the driver, the mappings were not updated. This implies that an incorrect mapping might be reported through pfvf for certain configurations.
This is a backport of the upstream commit with modifications, as the original patch does not apply cleanly to kernel v6.1.x. The logic has been simplified to reflect the limited configurations of the QAT driver in this version: crypto-only and compression.
Instead of dynamically computing the ring to service mappings, these are now hardcoded to simplify the backport.
Fixes: 0cec19c761e5 ("crypto: qat - add support for compression for 4xxx") Signed-off-by: Giovanni Cabiddu giovanni.cabiddu@intel.com Reviewed-by: Damian Muszynski damian.muszynski@intel.com Reviewed-by: Tero Kristo tero.kristo@linux.intel.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Cc: stable@vger.kernel.org # 6.1.x Reviewed-by: Ahsan Atta ahsan.atta@intel.com Tested-by: Ahsan Atta ahsan.atta@intel.com
You did not mention anywhere what changed from the original commit (and it changed a lot...) So this looks to me like an incorrect backport, so I have to just delete it :(
It is mentioned in the commit message:
This is a backport of the upstream commit with modifications, as the original patch does not apply cleanly to kernel v6.1.x. The logic has been simplified to reflect the limited configurations of the QAT driver in this version: crypto-only and compression.
Instead of dynamically computing the ring to service mappings, these are now hardcoded to simplify the backport.
I didn't port the original algorithm that builds the ring to service mapping as the QAT driver in v6.1 only supports two configurations (crypto and compression), therefore I simplified the logic in the function get_ring_to_svc_map() to just returns the mask associated to each configuration.
BTW, I'm also the author of the original patch.
Please fix up and send it again.
Is this sufficient or shall I resend?
Thanks,
On Tue, Jul 22, 2025 at 02:29:32PM +0100, Giovanni Cabiddu wrote:
On Tue, Jul 22, 2025 at 11:42:37AM +0200, Greg KH wrote:
On Thu, Jul 17, 2025 at 06:06:38PM +0100, Giovanni Cabiddu wrote:
[ Upstream commit a238487f7965d102794ed9f8aff0b667cd2ae886 ]
The 4xxx drivers hardcode the ring to service mapping. However, when additional configurations where added to the driver, the mappings were not updated. This implies that an incorrect mapping might be reported through pfvf for certain configurations.
This is a backport of the upstream commit with modifications, as the original patch does not apply cleanly to kernel v6.1.x. The logic has been simplified to reflect the limited configurations of the QAT driver in this version: crypto-only and compression.
Instead of dynamically computing the ring to service mappings, these are now hardcoded to simplify the backport.
Fixes: 0cec19c761e5 ("crypto: qat - add support for compression for 4xxx") Signed-off-by: Giovanni Cabiddu giovanni.cabiddu@intel.com Reviewed-by: Damian Muszynski damian.muszynski@intel.com Reviewed-by: Tero Kristo tero.kristo@linux.intel.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Cc: stable@vger.kernel.org # 6.1.x Reviewed-by: Ahsan Atta ahsan.atta@intel.com Tested-by: Ahsan Atta ahsan.atta@intel.com
You did not mention anywhere what changed from the original commit (and it changed a lot...) So this looks to me like an incorrect backport, so I have to just delete it :(
It is mentioned in the commit message:
This is a backport of the upstream commit with modifications, as the original patch does not apply cleanly to kernel v6.1.x. The logic has been simplified to reflect the limited configurations of the QAT driver in this version: crypto-only and compression.
Instead of dynamically computing the ring to service mappings, these are now hardcoded to simplify the backport.
I didn't port the original algorithm that builds the ring to service mapping as the QAT driver in v6.1 only supports two configurations (crypto and compression), therefore I simplified the logic in the function get_ring_to_svc_map() to just returns the mask associated to each configuration.
BTW, I'm also the author of the original patch.
Please fix up and send it again.
Is this sufficient or shall I resend?
Please resend and put the comments you made that differ from the original changelog text down in the signed-off-by area like other backports do.
Here is an example of that: https://lore.kernel.org/r/20250717124556.589696-2-harshit.m.mogalapalli@orac...
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org