On 4/2/2024 11:25 AM, Alexey Minnekhanov wrote:
>
>
> On 02.04.2024 18:55, Dmitry Baryshkov wrote:
>> I'd say, we should take a step back and actually verify how this was
>> handled in the vendor kernel.
>
>
> AFAIK there is no such thing in vendor kernel driver for this, as
> this startup procedure is likely handled entirely in userspace in
> cnss_daemon.
>
So now I'm looking at the cnss-daemon, and there it appears that MSA READY is
always expected to be received.
There is target-specific logic to set the flags sent to firmware:
if (gdata->instance_id == ADRASTEA_ID) {
req.msa_ready_enable_valid = 1;
req.msa_ready_enable = 1;
} else { /* All targets other than Adrastea */
req.fw_mem_ready_enable_valid = 1;
req.fw_mem_ready_enable = 1;
}
Logic to set an internal flag if the message is received:
case QMI_WLFW_MSA_READY_IND_V01:
gdata->state |= CNSS_MSA_READY;
And Adrastea-specific logic to set that flag if it is set in a separate status
indicator:
static int wlfw_adrastea_init(struct wlfw_client_data *gdata)
[...]
if (fw_status & QMI_WLFW_MSA_READY_V01) {
wsvc_printf_dbg("MSA is ready");
gdata->state |= CNSS_MSA_READY;
}
So that flag is only set by receiving the QMI_WLFW_MSA_READY_IND_V01 message
or, only for Adrastea, if the response to wlfw_send_ind_register_req()
indicates MSA_READY
Later there is a wait for MSA_READY that has no conditions:
while (!CNSS_IS_MSA_READY(gdata->state))
Truthfully this is code I've never had to deal with before, and I've struggled
to find developers who have the necessary background. The least disruptive
paths seem to either be the DT item or adding a new item for this in struct
ath10k_hw_params.
Kalle, do you have any different guidance?
