Re: [PATCH 04/12] ath10k: add support to start and stop qmi service

[Govind Singh <govinds@codeaurora.org>]

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@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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k