Re: [PATCH net] wifi: ath12k: properly set single_chip_mlo_supp to true in ath12k_core_alloc()

[Krzysztof Kozlowski <krzk@kernel.org>]

On 19/03/2025 11:18, Dmitry Baryshkov wrote:
> On Wed, Mar 19, 2025 at 11:00:34AM +0100, neil.armstrong@linaro.org wrote:
>> Hi,
>>
>> On 19/03/2025 10:46, Baochen Qiang wrote:
>>>
>>>
>>> On 3/19/2025 5:12 PM, neil.armstrong@linaro.org wrote:
>>>> Hi,
>>>>
>>>> On 19/03/2025 10:06, Vasanthakumar Thiagarajan wrote:
>>>>>
>>>>>
>>>>> On 3/19/2025 1:34 PM, Neil Armstrong wrote:
>>>>>> On 18/03/2025 17:35, Jeff Johnson wrote:
>>>>>>> On 3/3/2025 7:00 AM, Neil Armstrong wrote:
>>>>>>>> In commit 46d16f7e1d14 ("wifi: ath12k: rename mlo_capable_flags to
>>>>>>>> single_chip_mlo_supp")
>>>>>>>> the line:
>>>>>>>>      ab->mlo_capable_flags = ATH12K_INTRA_DEVICE_MLO_SUPPORT;
>>>>>>>> was incorrectly updated to:
>>>>>>>>      ab->single_chip_mlo_supp = false;
>>>>>>>> leading to always disabling INTRA_DEVICE_MLO even if the device supports it.
>>>>>>>>
>>>>>>>> The firmware "WLAN.HMT.1.1.c5-00156-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1"
>>>>>>>> crashes on driver initialization with:
>>>>>>>>    ath12k_pci 0000:01:00.0: chip_id 0x2 chip_family 0x4 board_id 0x3d soc_id 0x40170200
>>>>>>>>    ath12k_pci 0000:01:00.0: fw_version 0x110f009c fw_build_timestamp 2024-05-30 11:35
>>>>>>>> fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00156-
>>>>>>>> QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
>>>
>>> this FW version is not upstream yet, why are you testing with it?
>>
>> I was not aware the driver supported only a small subset of firmwares.
> 
> Yes, this has been communicated by Kalle (and now by Jeff) for ages:
> using any firmware outside of linux-firmware is not supported, unless
> you have been explicitly told to use a particular binary. Firmware
> coming from the Android / Mobile might use different knobs and have
> different expectations regarding driver behaviour.
Sure, fine, but that's not what is happening here. Look at the replies
from Qualcomm - not responding to actual issue here but instantly
rejecting a patch for regression just on basis of:

1. "series under internal review to address MLO issues"
2. "when all the necessary driver changes
(in development, public posting in near future)"
3. "Generally we only support upstrmea driver + upstream FW."

Instead of talking about actual problem, I see only avoidance of
responsibility and just sticking to whatever they have planned internally.

That's not how work with upstream is done and is really disappointing to
see.

Remember Tuxedo computers folks who said we want to control usptream
process, thus we will release source code under incompatible license to
prohibit community from working on their own.

This is the same Qualcomm behavior.

Best regards,
Krzysztof