[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <16fc19ea-308a-ceee-d2da-4de93c66e2d7@redhat.com>
Date: Fri, 13 May 2016 18:04:00 -0400
From: Doug Ledford <dledford@...hat.com>
To: Lijun Ou <oulijun@...wei.com>, sean.hefty@...el.com,
hal.rosenstock@...il.com, davem@...emloft.net,
jeffrey.t.kirsher@...el.com, jiri@...lanox.com,
ogerlitz@...lanox.com
Cc: linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, gongyangming@...wei.com,
xiaokun@...wei.com, tangchaofei@...wei.com, haifeng.wei@...wei.com,
yisen.zhuang@...wei.com, yankejian@...wei.com,
charles.chenxin@...wei.com, linuxarm@...wei.com
Subject: Re: [RESEND PATCH v7 17/21] IB/hns: Add QP operations support
On 05/09/2016 11:04 PM, Lijun Ou wrote:
> +static void hns_roce_v1_cq_clean(struct hns_roce_cq *hr_cq, u32 qpn,
> + struct hns_roce_srq *srq)
> +{
> + spin_lock_irq(&hr_cq->lock);
> + hns_roce_v1_clean_cq(hr_cq, qpn, srq);
> + spin_unlock_irq(&hr_cq->lock);
> +}
This is a perfect example of what I was talking about in my last email.
The convention here would be to name the main function
__hns_roce_v1_cq_clean and the wrapper hns_roce_v1_cq_clean. Instead,
you have one named cq_clean and one named clean_cq. Keeping straight
which of those locks itself and which needs to be called with the lock
held is nigh impossible.
--
Doug Ledford <dledford@...hat.com>
GPG KeyID: 0E572FDD
Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)
Powered by blists - more mailing lists