qat: driver updates to enhance qat infrastructure

[hareshx.sankar.raj_intel.com]

Summary

• Updated QAT infrastructure FW version/AE mask/num_banks fields to facilitate integration of future QAT products.
• Exposed service as sym;asym instead of cy for gen4
• Enhanced cpaGetInstances() for accurate instance retrieval
• Added 57-bit virtual address support to lac_lock_free_stack
• Minor bug fixes and improvements

Signed-off-by: Hareshx Sankar Raj <[e-mail]>

[hareshx.sankar.raj_intel.com]

Minor update on removal of unwanted arcconfig file change

[markj]

sys/dev/qat/include/adf_gen4vf_hw_csr_data.h

91–94

Why did you drop the ADF_RING_CSR_ADDR_OFFSET_GEN4VF term here? All of the macros below still have it.

sys/dev/qat/qat_common/qat_hal.c

1070

Why is it ok to truncate the values here? Elsewhere you're widening the mask to 64 bits.

[hareshx.sankar.raj_intel.com]

sys/dev/qat/include/adf_gen4vf_hw_csr_data.h

91–94

Thanks for the feedback.

The ADF_RING_CSR_ADDR_OFFSET_GEN4VF is defined as 0x0 in this file (line 6), so its omission has no functional impact.
This change was ported from Linux and the changes were mainly focussing on WRITE_CSR_INT_SRCSEL_GEN4VF and the macro was not intended to be left out.

If there are no other changes required for this release, is it acceptable for us to log a ticket and fix in the next upstream release given that it has no functional impact? Let us know your thoughts.

sys/dev/qat/qat_common/qat_hal.c

1070

The truncation is safe and intentional:

struct icp_qat_fw_loader_hal_handle is the firmware loader structure with a fixed memory layout that firmware expects during initialization. Changing ae_mask from u32 to u64 would alter the structure's layout (field offsets), breaking compatibility with all existing firmware images.

Why the cast is safe:

All current QAT devices have ≤32 AEs (ICP_QAT_UCLO_MAX_AE = 32)
No data loss occurs since the upper 32 bits are always zero

Why we widened the driver-side to u64:

Future-proofs internal driver interfaces for devices with >32 AEs
When such devices arrive, both the firmware handle structure and driver will be updated in a coordinated manner
For now, the u32 cast maintains ABI stability with existing firmware while the driver is already prepared for future hardware

[markj]

sys/dev/qat/include/adf_gen4vf_hw_csr_data.h

91–94

That's okay with me.

sys/dev/qat/qat_common/qat_hal.c

1070

Okay.