mbox series

[0/2] wifi: ath12k: Add support to allocate MLO global memory region

Message ID 20240730170910.3281816-1-quic_rajkbhag@quicinc.com
Headers show
Series wifi: ath12k: Add support to allocate MLO global memory region | expand

Message

Raj Kumar Bhagat July 30, 2024, 5:09 p.m. UTC 
To enable Multi Link Operation (MLO), QCN9274 firmware requests MLO
global memory (MLO_GLOBAL_MEM_REGION_TYPE). This memory region is
shared across all the firmware (SoC) that are participation in the
MLO.

Hence, add support to allocate and free MLO global memory region.
WCN7850 firmware doesn't request for this memory type, therefore this
change will have no impact on WCN7850 device.

Depends-On: [v9] wifi: ath12k: Introduce device group abstraction
Link: https://lore.kernel.org/linux-wireless/20240628095139.292952-1-quic_hprem@quicinc.com/

Karthikeyan Periyasamy (2):
  wifi: ath12k: Refactor ath12k_qmi_alloc_target_mem_chunk function
  wifi: ath12k: Add support to allocate MLO global memory region

 drivers/net/wireless/ath/ath12k/core.h |   7 +
 drivers/net/wireless/ath/ath12k/qmi.c  | 190 +++++++++++++++++++------
 drivers/net/wireless/ath/ath12k/qmi.h  |   1 +
 3 files changed, 155 insertions(+), 43 deletions(-)


base-commit: db1ce56e6e1d395dd42a3cd6332a871d9be59c45
prerequisite-patch-id: 9f11ba698b740286374ae7baaa0d40d3b3efa7ba
prerequisite-patch-id: 8bf59833c98c85c6aebb52378ff8b323dc082811
prerequisite-patch-id: f8075a6e30a91260aaa31d0b6b115f9243568d62
prerequisite-patch-id: 68ac72de019bf6c8485daa086daef7aef301bd84
prerequisite-patch-id: 06244ca08d9bed3834dc5315470a19d096d749ee
prerequisite-patch-id: 843ba59a8b315ddac081ad0c8ea9bdabce054373
prerequisite-patch-id: 47b63476fd4d8f34e8bc64c73a04f8a7c294416a
prerequisite-patch-id: 6bfca81d9f8674838d11a2987bff8bf039fca55e

Comments

Jeff Johnson July 31, 2024, 4:08 p.m. UTC | #1 
On 7/31/2024 8:45 AM, Jeff Johnson wrote:
> On 7/30/2024 10:09 AM, Raj Kumar Bhagat wrote:
>> +			ret = ath12k_qmi_alloc_chunk(ab, chunk);
> 
> seems like you need to test ret and return if non-zero here since currently if
> you get a bad ret in one loop but you continue and get a good ret on the
> remaining iterations then you'll end up returning success from this function.
> 
> In other words, your refactoring doesn't correct handle that the original
> "return -ENOMEM" would return from *this* function at this point

I see you handle this in patch 2, but that portion of patch 2 should be moved
to this patch