[PATCH ath-next v2] wifi: ath12k: add QMI capability negotiation for dynamic memory mode

[Aaradhana Sahu]

On 6/24/2026 5:12 AM, Jeff Johnson wrote:
> On 6/18/2026 11:58 PM, Aaradhana Sahu wrote:
>> On AHB platforms, firmware operates in two modes: fixed-memory mode where
>> firmware uses hardcoded addresses for memory regions such as BDF and does
>> not request HOST_DDR memory from the host, and dynamic-memory mode where
>> firmware expects the host to provide memory addresses including HOST_DDR
>> after the Q6 read-only region and relies on host allocation for all memory
>> types.
>>
>> Introduce QMI capability negotiation to support both modes. Add a new QMI
>> PHY capability flag dynamic_ddr_support which is advertised by firmware to
>> indicate it supports dynamic memory mode. When the host detects this
>> capability, set the dynamic_mem_support flag in the host capability message
>> to signal the host is ready to provide dynamic memory allocation. This
>> triggers firmware to send the HOST_DDR memory request and use the
>> host-provided address.
>>
>> For backward compatibility, if firmware doesn't advertise
>> dynamic_ddr_support, the firmware continues to operate in fixed-memory mode
>> where firmware uses predefined addresses.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Aaradhana Sahu <aaradhana.sahu at oss.qualcomm.com>
>> ---
>> v2:
>>   -Dropped QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN and QMI_WLANFW_PHY_CAP_RESP_MSG_V01_MAX_LEN changes.
> 
> I think you needed to keep the REQ_MSG MAX_LEN change.
> My prior comment that the REQ_MSG MAX_LEN macros are a layering violation was
> constrained with the observation "that is a preexisting issue with the QMI
> interface" so we must continue to pass valid MAX_LEN values unless the QMI
> interface itself is changed such QMI determines the MAX_LEN
> 

You're right. My bad, I mistakenly dropped the QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN
changes while updating the patch. I will restore in the next version.

>>   -Used %u instead of %d in the debug log.
>> ---
>>  drivers/net/wireless/ath/ath12k/qmi.c | 50 +++++++++++++++++++++++++--
>>  drivers/net/wireless/ath/ath12k/qmi.h |  6 +++-
>>  2 files changed, 52 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
>> index fd762b5d7bb5..e15a0c0120d3 100644
>> --- a/drivers/net/wireless/ath/ath12k/qmi.c
>> +++ b/drivers/net/wireless/ath/ath12k/qmi.c
>> @@ -506,6 +506,24 @@ static const struct qmi_elem_info qmi_wlanfw_host_cap_req_msg_v01_ei[] = {
>>  		.offset		= offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
>>  					   feature_list),
>>  	},
>> +	{
>> +		.data_type	= QMI_OPT_FLAG,
>> +		.elem_len	= 1,
>> +		.elem_size	= sizeof(u8),
>> +		.array_type	= NO_ARRAY,
>> +		.tlv_type	= 0x33,
>> +		.offset		= offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
>> +					   dynamic_mem_support_valid),
>> +	},
>> +	{
>> +		.data_type	= QMI_UNSIGNED_1_BYTE,
>> +		.elem_len	= 1,
>> +		.elem_size	= sizeof(u8),
>> +		.array_type	= NO_ARRAY,
>> +		.tlv_type	= 0x33,
>> +		.offset		= offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
>> +					   dynamic_mem_support),
>> +	},
> 
> Does QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN need to be updated to account for
> the new TLVs?
> 

You're right. I will update QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN by 4 bytes and
send it in the next version.

>>  	{
>>  		.data_type	= QMI_EOTI,
>>  		.array_type	= NO_ARRAY,