On 3/26/2024 10:51 AM, Dmitry Baryshkov wrote:
> On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez <mgonzalez@xxxxxxxxxx> wrote:
>>
>> [ It has been pointed out to me that the previous message was unclear. ]
>> [ Below is my 2nd attempt at a clearer message. ]
>>
>> Problem: firmware-5.bin has not been parsed yet when we have to handle
>> the ATH10K_QMI_EVENT_SERVER_ARRIVE case, so we can't rely on feature bits
>> to work around the lack of MSA_READY indicator.
>
> Then, I'd say, we have to resort to the DT property, unless Kalle or
> Jeff have other proposals.
Another option is to follow the downstream driver model and only expect this
based upon static configuration within the driver.
Downstream driver has:
if (priv->device_id == ADRASTEA_DEVICE_ID) {
ret = wlfw_msa_mem_info_send_sync_msg(priv);
ret = wlfw_msa_ready_send_sync_msg(priv);
}
https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r4-rel/icnss2/main.c?ref_type=heads#L968
The downstream MSA logic (including some other code that populates MSA-related
fields in the QMI messages) is only invoked for ADRASTEA_DEVICE_ID.
We could introduce a new hw_params parameter to have the same semantics.
But I'm OK with the DT option as well.
Kalle?
/jeff
