-----Original Message-----
From: Roland Dreier [mailto:roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org]
Sent: Wednesday, March 21, 2012 10:13 PM
To: Pandit, Parav
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 6/9] ocrdma: Driver for Emulex OneConnect RDMA
adapter

quoted

+struct ib_pd *ocrdma_alloc_pd(struct ib_device *ibdev,
+                             struct ib_ucontext *context,
+                             struct ib_udata *udata) {
+       struct ocrdma_dev *dev = get_ocrdma_dev(ibdev);
+       struct ocrdma_pd *pd;
+       int status;
+
+       pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+       if (!pd)
+               return ERR_PTR(-ENOMEM);
+       pd->dev = dev;
+       if (udata && context) {
+               pd->dpp_enabled = (dev->nic_info.dev_family ==
+                                       OCRDMA_GEN2_FAMILY) ? true :
+ false;

Writing

    (<bool expr>) ? true : false

is pretty silly, since it's just an obfuscated way of writing

    <bool expr>

IOW, you can just write

     pd->dpp_enabled = (dev->nic_info.dev_family ==
OCRDMA_GEN2_FAMILY);

quoted

+int ocrdma_dealloc_pd(struct ib_pd *ibpd) {
+       struct ocrdma_pd *pd = get_ocrdma_pd(ibpd);
+       struct ocrdma_dev *dev = pd->dev;
+       int status;
+       u64 usr_db;
+
+       if (atomic_read(&pd->use_cnt)) {
+               ocrdma_err("%s(%d) pd=0x%x is in use.\n",
+                          __func__, dev->id, pd->id);
+               status = -EFAULT;
+               goto dealloc_err;
+       }

all of the use_cnt tracking in this driver seems to duplicate what the rdma
midlayer already does... is there any reason we need that in the low-level
hardware driver too, or can we just get rid of the various use_cnt members?

This use_cnt can be removed from low-level hardware driver. I'll remove it.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html