[PATCH 04/12] ath10k: add support to start and stop qmi service
Govind Singh
govinds at codeaurora.org
Mon May 14 06:29:10 PDT 2018
On 2018-05-11 23:13, Bjorn Andersson wrote:
> On Sun 25 Mar 22:39 PDT 2018, Govind Singh wrote:
>
>> Add support to start qmi service to configure the wlan
>> firmware component and register event notifier to communicate
>> with the WLAN firmware over qmi communication interface.
>>
>> Signed-off-by: Govind Singh <govinds at codeaurora.org>
>> ---
>> drivers/net/wireless/ath/ath10k/qmi.c | 155
>> ++++++++++++++++++++++++++++++++--
>> drivers/net/wireless/ath/ath10k/qmi.h | 13 +++
>> 2 files changed, 160 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
>> b/drivers/net/wireless/ath/ath10k/qmi.c
>> index 2235182..3a7fcc6 100644
>> --- a/drivers/net/wireless/ath/ath10k/qmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
>> @@ -31,15 +31,115 @@
>>
>> static struct ath10k_qmi *qmi;
>>
>> +static int ath10k_qmi_event_fw_ready_ind(struct ath10k_qmi *qmi)
>> +{
>> + pr_debug("fw ready event received\n");
>
> Please use dev_dbg.
>
I have migrated from pr_ to dev_ logging for the whole set, will share
in next version.
>> + spin_lock(&qmi->event_lock);
>> + qmi->fw_ready = true;
>> + spin_unlock(&qmi->event_lock);
>
> I see no reason for not just putting this code in
> ath10k_qmi_fw_ready_ind().
>
>> +
>
> fw_ready isn't used for anything, what purpose does this code have?
>
fw_ready will be used in later set of changes for qmi client debugfs and
for synchronization.I will decouple this and add as bit mask in
appropriate change.
>> + return 0;
>> +}
>> +
>> +static void ath10k_qmi_fw_ready_ind(struct qmi_handle *qmi_hdl,
>> + struct sockaddr_qrtr *sq,
>> + struct qmi_txn *txn, const void *data)
>> +{
>> + struct ath10k_qmi *qmi = container_of(qmi_hdl, struct ath10k_qmi,
>> qmi_hdl);
>> +
>> + ath10k_qmi_event_fw_ready_ind(qmi);
>> +}
>> +
>> +static void ath10k_qmi_msa_ready_ind(struct qmi_handle *qmi_hdl,
>> + struct sockaddr_qrtr *sq,
>> + struct qmi_txn *txn, const void *data)
>> +{
>> + struct ath10k_qmi *qmi = container_of(qmi_hdl, struct ath10k_qmi,
>> qmi_hdl);
>> +
>> + qmi->msa_ready = true;
>
> msa_ready is not only unused in this patch, it's unused after all 11
> patches. Can you drop it?
>
Sure, will remove in next version.
>> +static void ath10k_qmi_event_server_arrive(struct work_struct *work)
>> +{
>> + struct ath10k_qmi *qmi = container_of(work, struct ath10k_qmi,
>> + work_svc_arrive);
>> + int ret;
>> +
>> + ret = ath10k_qmi_connect_to_fw_server(qmi);
>> + if (ret)
>> + return;
>> +
>> + pr_debug("qmi server arrive\n");
>> +}
>> +
>> static int ath10k_qmi_new_server(struct qmi_handle *qmi_hdl,
>> struct qmi_service *service)
>> {
>> + struct ath10k_qmi *qmi = container_of(qmi_hdl, struct ath10k_qmi,
>> qmi_hdl);
>> + struct sockaddr_qrtr *sq = &qmi->sq;
>> +
>> + sq->sq_family = AF_QIPCRTR;
>> + sq->sq_node = service->node;
>> + sq->sq_port = service->port;
>> +
>> + queue_work(qmi->event_wq, &qmi->work_svc_arrive);
>
> This is being called in a sleepable context and kernel_connect() will
> not block, so I see no reason for queue work here to invoke
> ath10k_qmi_event_server_arrive() just to call
> ath10k_qmi_connect_to_fw_server().
>
> Just put the kernel_connect() call here.
>
>
In this change it just calls ath10k_qmi_connect_to_fw_server, but most
of the handshaking is done in server arrive callback.
Successive changes adds the request/response of each handshake.
Is it ok to block new_server callback till all client handshaking gets
completed. I thought it might block other client
notification overlapped on the same time slot(ex: IPA). Do you see any
concern here or should be ok.
I have not profiled yet, i will share the approx time it can take.
> This gives the added benefit that you don't need to use qmi->sq as a
> way
> to pass parameters to ath10k_qmi_connect_to_fw_server().
>
>> +
>> return 0;
>> }
>>
>> static void ath10k_qmi_del_server(struct qmi_handle *qmi_hdl,
>> struct qmi_service *service)
>> {
>> + struct ath10k_qmi *qmi =
>> + container_of(qmi_hdl, struct ath10k_qmi, qmi_hdl);
>> +
>> + queue_work(qmi->event_wq, &qmi->work_svc_exit);
>
> I see no reason to queue work to set a boolean to false, just inline
> the
> code here.
>
sure, this i can remove.
>>
>> static struct qmi_ops ath10k_qmi_ops = {
>> @@ -47,6 +147,51 @@ static void ath10k_qmi_del_server(struct
>> qmi_handle *qmi_hdl,
>> .del_server = ath10k_qmi_del_server,
>> };
>>
>> +static int ath10k_alloc_qmi_resources(struct ath10k_qmi *qmi)
>> +{
>> + int ret;
>> +
>> + ret = qmi_handle_init(&qmi->qmi_hdl,
>> + WLFW_BDF_DOWNLOAD_REQ_MSG_V01_MAX_MSG_LEN,
>> + &ath10k_qmi_ops, qmi_msg_handler);
>> + if (ret)
>> + goto err;
>> +
>> + qmi->event_wq = alloc_workqueue("qmi_driver_event",
>> + WQ_UNBOUND, 1);
>> + if (!qmi->event_wq) {
>> + pr_err("workqueue alloc failed\n");
>> + ret = -EFAULT;
>> + goto err_qmi_service;
>> + }
>> +
>> + spin_lock_init(&qmi->event_lock);
>
> All calls from the qmi helpers are done from a single context, so
> there's no reason to use this lock.
>
>> + INIT_WORK(&qmi->work_svc_arrive, ath10k_qmi_event_server_arrive);
>> + INIT_WORK(&qmi->work_svc_exit, ath10k_qmi_event_server_exit);
>> +
>> + ret = qmi_add_lookup(&qmi->qmi_hdl, WLFW_SERVICE_ID_V01,
>> + WLFW_SERVICE_VERS_V01, 0);
>> + if (ret)
>> + goto err_qmi_service;
>> +
>> + return 0;
>> +
>> +err_qmi_service:
>> + qmi_handle_release(&qmi->qmi_hdl);
>> +
>> +err:
>> + return ret;
>> +}
>> +
>> +static void ath10k_remove_qmi_resources(struct ath10k_qmi *qmi)
>> +{
>> + cancel_work_sync(&qmi->work_svc_arrive);
>> + cancel_work_sync(&qmi->work_svc_exit);
>> + destroy_workqueue(qmi->event_wq);
>> + qmi_handle_release(&qmi->qmi_hdl);
>> + qmi = NULL;
>> +}
>> +
>> static int ath10k_qmi_probe(struct platform_device *pdev)
>> {
>> int ret;
>> @@ -58,14 +203,8 @@ static int ath10k_qmi_probe(struct platform_device
>> *pdev)
>>
>> qmi->pdev = pdev;
>> platform_set_drvdata(pdev, qmi);
>> - ret = qmi_handle_init(&qmi->qmi_hdl,
>> - WLFW_BDF_DOWNLOAD_REQ_MSG_V01_MAX_MSG_LEN,
>> - &ath10k_qmi_ops, NULL);
>> - if (ret < 0)
>> - goto err;
>>
>> - ret = qmi_add_lookup(&qmi->qmi_hdl, WLFW_SERVICE_ID_V01,
>> - WLFW_SERVICE_VERS_V01, 0);
>
> Please plan ahead, there's no reason for adding this here in patch 3
> and
> then just move it in patch 4. That said, with the removal of the queues
> I don't see a good reason to create a helper for this.
>
Sure, will do in next version.
>> + ret = ath10k_alloc_qmi_resources(qmi);
>> if (ret < 0)
>> goto err;
>>
>> @@ -81,7 +220,7 @@ static int ath10k_qmi_remove(struct platform_device
>> *pdev)
>> {
>> struct ath10k_qmi *qmi = platform_get_drvdata(pdev);
>>
>> - qmi_handle_release(&qmi->qmi_hdl);
>> + ath10k_remove_qmi_resources(qmi);
>
> Just inline ath10k_remove_qmi_resources() here, so one doesn't have to
> jump around to figure out what's actually going on.
>
Sure, will do in next version.
return 0;
>
> Regards,
> Bjorn
>>
BR,
Govind
More information about the ath10k
mailing list