[PATCH v3 for-next 0/2] Bugfixes for eq support in hns

[PATCH v3 for-next 0/2] Bugfixes for eq support in hns

[Yixian Liu]

This patch set fixes the bugs according to Jason's two comments
on my previous patch set, which listed in the NOTE.

NOTE: This patch set is dependent on the following patches.
   "RDMA/hns: Add eq support of hip08"
   "RDMA/hns: Refactor eq code for hip06"

v2 -> v3:
1. Update according to Jason's comments
   - use dma_rmb instead of rmb in patch [1/2]
   - delete unnecessary assignment for doorbell64

v1 -> v2:
1. Update according to Leon's comment, see the changelog
   of patch [2/2].

Yixian Liu (2):
  RDMA/hns: Add detailed comments for mb() call
  RDMA/hns: Fix alignment problem of the doorbell

 drivers/infiniband/hw/hns/hns_roce_device.h |  5 ++++
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c  | 22 ++++++++++-----
 drivers/infiniband/hw/hns/hns_roce_hw_v2.c  | 42 ++++++++++++++---------------
 3 files changed, 42 insertions(+), 27 deletions(-)

-- 
1.9.1

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

[PATCH v3 for-next 1/2] RDMA/hns: Add detailed comments for mb() call

[Yixian Liu]

This patch adds more detailed comments when we call the
memory barrier function, such as rmb, wmb and mb. Three
mb() callers are deleted since they are unnecessary.

v3:
1. Subsitute rmb() with dma_rmb() according to Jason's comment,
   since using dma_rmb() is enough.

Signed-off-by: Yixian Liu <liuyixian-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
 drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 22 ++++++++++++++++------
 drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 26 +++++++++++++-------------
 2 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index 6100ace..47ef90b 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -3963,7 +3963,10 @@ static void set_eq_cons_index_v1(struct hns_roce_eq *eq, int req_not)
 {
 	roce_raw_write((eq->cons_index & HNS_ROCE_V1_CONS_IDX_M) |
 		      (req_not << eq->log_entries), eq->doorbell);
-	/* Memory barrier */
+
+	/* Make sure we update the consumer index of EQ before
+	 * accessing it later
+	 */
 	mb();
 }
 
@@ -4156,13 +4159,16 @@ static int hns_roce_v1_aeq_int(struct hns_roce_dev *hr_dev,
 	int event_type;
 
 	while ((aeqe = next_aeqe_sw_v1(eq))) {
+
+		/* Make sure we read the AEQ entry after we have checked the
+		 * ownership bit
+		 */
+		dma_rmb();
+
 		dev_dbg(dev, "aeqe = %p, aeqe->asyn.event_type = 0x%lx\n", aeqe,
 			roce_get_field(aeqe->asyn,
 				       HNS_ROCE_AEQE_U32_4_EVENT_TYPE_M,
 				       HNS_ROCE_AEQE_U32_4_EVENT_TYPE_S));
-		/* Memory barrier */
-		rmb();
-
 		event_type = roce_get_field(aeqe->asyn,
 					    HNS_ROCE_AEQE_U32_4_EVENT_TYPE_M,
 					    HNS_ROCE_AEQE_U32_4_EVENT_TYPE_S);
@@ -4260,8 +4266,12 @@ static int hns_roce_v1_ceq_int(struct hns_roce_dev *hr_dev,
 	u32 cqn;
 
 	while ((ceqe = next_ceqe_sw_v1(eq))) {
-		/* Memory barrier */
-		rmb();
+
+		/* Make sure we read CEQ entry after we have checked the
+		 * ownership bit
+		 */
+		dma_rmb();
+
 		cqn = roce_get_field(ceqe->comp,
 				     HNS_ROCE_CEQE_CEQE_COMP_CQN_M,
 				     HNS_ROCE_CEQE_CEQE_COMP_CQN_S);
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
index 04281d0..4b300c8 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
@@ -3200,7 +3200,9 @@ static void set_eq_cons_index_v2(struct hns_roce_eq *eq)
 
 	hns_roce_write64_k(doorbell, eq->doorbell);
 
-	/* Memory barrier */
+	/* Make sure we update the consumer index of EQ before
+	 * accessing it later
+	 */
 	mb();
 
 }
@@ -3384,8 +3386,11 @@ static int hns_roce_v2_aeq_int(struct hns_roce_dev *hr_dev,
 	int event_type;
 
 	while ((aeqe = next_aeqe_sw_v2(eq))) {
-		/* Memory barrier */
-		rmb();
+
+		/* Make sure we read AEQ entry after we have checked the
+		 * ownership bit
+		 */
+		dma_rmb();
 
 		event_type = roce_get_field(aeqe->asyn,
 					    HNS_ROCE_V2_AEQE_EVENT_TYPE_M,
@@ -3500,8 +3505,11 @@ static int hns_roce_v2_ceq_int(struct hns_roce_dev *hr_dev,
 
 	while ((ceqe = next_ceqe_sw_v2(eq))) {
 
-		/* Memory barrier */
-		rmb();
+		/* Make sure we read CEQ entry after we have checked the
+		 * ownership bit
+		 */
+		dma_rmb();
+
 		cqn = roce_get_field(ceqe->comp,
 				     HNS_ROCE_V2_CEQE_COMP_CQN_M,
 				     HNS_ROCE_V2_CEQE_COMP_CQN_S);
@@ -3556,9 +3564,6 @@ static irqreturn_t hns_roce_v2_msix_interrupt_abn(int irq, void *dev_id)
 		roce_set_bit(int_st, HNS_ROCE_V2_VF_INT_ST_AEQ_OVERFLOW_S, 1);
 		roce_write(hr_dev, ROCEE_VF_ABN_INT_ST_REG, int_st);
 
-		/* Memory barrier */
-		mb();
-
 		roce_set_bit(int_en, HNS_ROCE_V2_VF_ABN_INT_EN_S, 1);
 		roce_write(hr_dev, ROCEE_VF_ABN_INT_EN_REG, int_en);
 
@@ -3569,9 +3574,6 @@ static irqreturn_t hns_roce_v2_msix_interrupt_abn(int irq, void *dev_id)
 		roce_set_bit(int_st, HNS_ROCE_V2_VF_INT_ST_BUS_ERR_S, 1);
 		roce_write(hr_dev, ROCEE_VF_ABN_INT_ST_REG, int_st);
 
-		/* Memory barrier */
-		mb();
-
 		roce_set_bit(int_en, HNS_ROCE_V2_VF_ABN_INT_EN_S, 1);
 		roce_write(hr_dev, ROCEE_VF_ABN_INT_EN_REG, int_en);
 
@@ -3582,8 +3584,6 @@ static irqreturn_t hns_roce_v2_msix_interrupt_abn(int irq, void *dev_id)
 		roce_set_bit(int_st, HNS_ROCE_V2_VF_INT_ST_OTHER_ERR_S, 1);
 		roce_write(hr_dev, ROCEE_VF_ABN_INT_ST_REG, int_st);
 
-		/* Memory barrier */
-		mb();
 		roce_set_bit(int_en, HNS_ROCE_V2_VF_ABN_INT_EN_S, 1);
 		roce_write(hr_dev, ROCEE_VF_ABN_INT_EN_REG, int_en);
 
-- 
1.9.1

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

Re: [PATCH v3 for-next 1/2] RDMA/hns: Add detailed comments for mb() call

[Jason Gunthorpe]

On Thu, Dec 28, 2017 at 10:18:02PM +0800, Yixian Liu wrote:
> This patch adds more detailed comments when we call the
> memory barrier function, such as rmb, wmb and mb. Three
> mb() callers are deleted since they are unnecessary.
> 
> v3:
> 1. Subsitute rmb() with dma_rmb() according to Jason's comment,
>    since using dma_rmb() is enough.

This is such a big improvement, thanks

> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> index 6100ace..47ef90b 100644
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> @@ -3963,7 +3963,10 @@ static void set_eq_cons_index_v1(struct hns_roce_eq *eq, int req_not)
>  {
>  	roce_raw_write((eq->cons_index & HNS_ROCE_V1_CONS_IDX_M) |
>  		      (req_not << eq->log_entries), eq->doorbell);
> -	/* Memory barrier */
> +
> +	/* Make sure we update the consumer index of EQ before
> +	 * accessing it later
> +	 */
>  	mb();
>  }

This (and the other one below like it) is the only one that puzzles
me..

What are you trying to accomplish here? It looks like cons_index is
the tail pointer for a ring that the device DMA's into? And the
dma_rmb seems properly placed, so no barrier should be needed for DMA
when updating the tail pointer.

Is the barrier attempting to protect eq->cons_index in system memory?
If yes, shouldn't it be an atomic and/or locked?

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

Re: [PATCH v3 for-next 1/2] RDMA/hns: Add detailed comments for mb() call

[Liuyixian (Eason)]

On 2017/12/28 23:55, Jason Gunthorpe wrote:
> On Thu, Dec 28, 2017 at 10:18:02PM +0800, Yixian Liu wrote:
>> This patch adds more detailed comments when we call the
>> memory barrier function, such as rmb, wmb and mb. Three
>> mb() callers are deleted since they are unnecessary.
>>
>> v3:
>> 1. Subsitute rmb() with dma_rmb() according to Jason's comment,
>>    since using dma_rmb() is enough.
> 
> This is such a big improvement, thanks
> 
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
>> index 6100ace..47ef90b 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
>> @@ -3963,7 +3963,10 @@ static void set_eq_cons_index_v1(struct hns_roce_eq *eq, int req_not)
>>  {
>>  	roce_raw_write((eq->cons_index & HNS_ROCE_V1_CONS_IDX_M) |
>>  		      (req_not << eq->log_entries), eq->doorbell);
>> -	/* Memory barrier */
>> +
>> +	/* Make sure we update the consumer index of EQ before
>> +	 * accessing it later
>> +	 */
>>  	mb();
>>  }
> 
> This (and the other one below like it) is the only one that puzzles
> me..
> 
> What are you trying to accomplish here? It looks like cons_index is
> the tail pointer for a ring that the device DMA's into? And the
> dma_rmb seems properly placed, so no barrier should be needed for DMA
> when updating the tail pointer.
> 
> Is the barrier attempting to protect eq->cons_index in system memory?
> If yes, shouldn't it be an atomic and/or locked?
> 
> Jason
> 

You are right, here it write to the device register, so there is no need
to put a barrier there. I will eliminate them in patch v4.

Thanks.

> 

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

[PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Yixian Liu]

The array defined for doorbell is not guaranteed to be 64 bit
aligned while we write it to the hardware with 64 bit
alignment required.

This patch fixes this problem by defining a union for doorbell
to make sure it 64 bit alignment.

v2 -> v3:
1. delete the unnecessary assignment for doorbell64.

v2:
1. Consider with Leon's comments, make sure it is 64 bit
   alignment by assigning the expected value to the u64
   member of the union type, i.e., assign doorbell array
   to doorbell64.

Signed-off-by: Yixian Liu <liuyixian-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 drivers/infiniband/hw/hns/hns_roce_device.h |  5 +++++
 drivers/infiniband/hw/hns/hns_roce_hw_v2.c  | 16 ++++++++--------
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h b/drivers/infiniband/hw/hns/hns_roce_device.h
index dde5178..8d49f46 100644
--- a/drivers/infiniband/hw/hns/hns_roce_device.h
+++ b/drivers/infiniband/hw/hns/hns_roce_device.h
@@ -569,6 +569,11 @@ struct hns_roce_eq_table {
 	void __iomem		**eqc_base; /* only for hw v1 */
 };
 
+union hns_roce_eq_db {
+	__le64	doorbell64;
+	__le32	doorbell[2];
+};
+
 struct hns_roce_caps {
 	u8		num_ports;
 	int		gid_table_len[HNS_ROCE_MAX_PORTS];
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
index 4b300c8..499922a 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
@@ -3172,33 +3172,33 @@ static int hns_roce_v2_modify_cq(struct ib_cq *cq, u16 cq_count, u16 cq_period)
 
 static void set_eq_cons_index_v2(struct hns_roce_eq *eq)
 {
-	u32 doorbell[2];
+	union hns_roce_eq_db db;
 
-	doorbell[0] = 0;
-	doorbell[1] = 0;
+	db.doorbell[0] = 0;
+	db.doorbell[1] = 0;
 
 	if (eq->type_flag == HNS_ROCE_AEQ) {
-		roce_set_field(doorbell[0], HNS_ROCE_V2_EQ_DB_CMD_M,
+		roce_set_field(db.doorbell[0], HNS_ROCE_V2_EQ_DB_CMD_M,
 			       HNS_ROCE_V2_EQ_DB_CMD_S,
 			       eq->arm_st == HNS_ROCE_V2_EQ_ALWAYS_ARMED ?
 			       HNS_ROCE_EQ_DB_CMD_AEQ :
 			       HNS_ROCE_EQ_DB_CMD_AEQ_ARMED);
 	} else {
-		roce_set_field(doorbell[0], HNS_ROCE_V2_EQ_DB_TAG_M,
+		roce_set_field(db.doorbell[0], HNS_ROCE_V2_EQ_DB_TAG_M,
 			       HNS_ROCE_V2_EQ_DB_TAG_S, eq->eqn);
 
-		roce_set_field(doorbell[0], HNS_ROCE_V2_EQ_DB_CMD_M,
+		roce_set_field(db.doorbell[0], HNS_ROCE_V2_EQ_DB_CMD_M,
 			       HNS_ROCE_V2_EQ_DB_CMD_S,
 			       eq->arm_st == HNS_ROCE_V2_EQ_ALWAYS_ARMED ?
 			       HNS_ROCE_EQ_DB_CMD_CEQ :
 			       HNS_ROCE_EQ_DB_CMD_CEQ_ARMED);
 	}
 
-	roce_set_field(doorbell[1], HNS_ROCE_V2_EQ_DB_PARA_M,
+	roce_set_field(db.doorbell[1], HNS_ROCE_V2_EQ_DB_PARA_M,
 		       HNS_ROCE_V2_EQ_DB_PARA_S,
 		       (eq->cons_index & HNS_ROCE_V2_CONS_IDX_M));
 
-	hns_roce_write64_k(doorbell, eq->doorbell);
+	hns_roce_write64_k(db.doorbell, eq->doorbell);
 
 	/* Make sure we update the consumer index of EQ before
 	 * accessing it later
-- 
1.9.1

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

Re: [PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Jason Gunthorpe]

On Thu, Dec 28, 2017 at 10:18:03PM +0800, Yixian Liu wrote:

> -	hns_roce_write64_k(doorbell, eq->doorbell);
> +	hns_roce_write64_k(db.doorbell, eq->doorbell);

You need to pass &db to hns_roce_write64_k and have it deref the 64
bit value using the union. The point here is to eliminate the cast inside
hns_roce_write64_k.

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

Re: [PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Liuyixian (Eason)]

On 2017/12/28 23:57, Jason Gunthorpe wrote:
> 
> On Thu, Dec 28, 2017 at 10:18:03PM +0800, Yixian Liu wrote:
> 
>> -	hns_roce_write64_k(doorbell, eq->doorbell);
>> +	hns_roce_write64_k(db.doorbell, eq->doorbell);
> 
> You need to pass &db to hns_roce_write64_k and have it deref the 64
> bit value using the union. The point here is to eliminate the cast inside
> hns_roce_write64_k.
> 
> Jason
> --
> 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
> 

Hi Jason,

I know exactly what you mean, but the interface also called by lots of
other places in our driver, I plan to leave this revision in future work.
With db.doorbell input, we could get the correct value (64 bit) w/o *(u64 *).
Thus, this patch will not be updated in patch v4.

Thank you very much for clarify your solution.

> 

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

Re: [PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Jason Gunthorpe]

On Fri, Dec 29, 2017 at 06:29:35PM +0800, Liuyixian (Eason) wrote:
> 
> 
> On 2017/12/28 23:57, Jason Gunthorpe wrote:
> > 
> > On Thu, Dec 28, 2017 at 10:18:03PM +0800, Yixian Liu wrote:
> > 
> >> -	hns_roce_write64_k(doorbell, eq->doorbell);
> >> +	hns_roce_write64_k(db.doorbell, eq->doorbell);
> > 
> > You need to pass &db to hns_roce_write64_k and have it deref the 64
> > bit value using the union. The point here is to eliminate the cast inside
> > hns_roce_write64_k.
> > 
> > Jason
> 
> Hi Jason,
> 
> I know exactly what you mean, but the interface also called by lots of
> other places in our driver, I plan to leave this revision in future
> work.

Yes, exactly, and they all have the same problem, right?

The point of my original note was for you to fix the systemic problem
not just the single location I used as an example.
 
> With db.doorbell input, we could get the correct value (64 bit) w/o
> *(u64 *).  Thus, this patch will not be updated in patch v4.

Let us drop it then, resend it when you fix them all.

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

Re: [PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Liuyixian (Eason)]

On 2017/12/30 1:47, Jason Gunthorpe wrote:
> On Fri, Dec 29, 2017 at 06:29:35PM +0800, Liuyixian (Eason) wrote:
>>
>>
>> On 2017/12/28 23:57, Jason Gunthorpe wrote:
>>>
>>> On Thu, Dec 28, 2017 at 10:18:03PM +0800, Yixian Liu wrote:
>>>
>>>> -	hns_roce_write64_k(doorbell, eq->doorbell);
>>>> +	hns_roce_write64_k(db.doorbell, eq->doorbell);
>>>
>>> You need to pass &db to hns_roce_write64_k and have it deref the 64
>>> bit value using the union. The point here is to eliminate the cast inside
>>> hns_roce_write64_k.
>>>
>>> Jason
>>
>> Hi Jason,
>>
>> I know exactly what you mean, but the interface also called by lots of
>> other places in our driver, I plan to leave this revision in future
>> work.
> 
> Yes, exactly, and they all have the same problem, right?

Yes, they all have the same problem.

> 
> The point of my original note was for you to fix the systemic problem
> not just the single location I used as an example.
>  
>> With db.doorbell input, we could get the correct value (64 bit) w/o
>> *(u64 *).  Thus, this patch will not be updated in patch v4.
> 
> Let us drop it then, resend it when you fix them all.

Okay, I think your decision is reasonable.

> 
> Jason
> 
> 

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

Re: [PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Thu, Dec 28, 2017 at 10:18:03PM +0800, Yixian Liu wrote:
> The array defined for doorbell is not guaranteed to be 64 bit
> aligned while we write it to the hardware with 64 bit
> alignment required.
>
> This patch fixes this problem by defining a union for doorbell
> to make sure it 64 bit alignment.
>
> v2 -> v3:
> 1. delete the unnecessary assignment for doorbell64.
>
> v2:
> 1. Consider with Leon's comments, make sure it is 64 bit
>    alignment by assigning the expected value to the u64
>    member of the union type, i.e., assign doorbell array
>    to doorbell64.

Please put changelog after "---", so it won't be visible in git log.
See this patch as an example:
https://lkml.org/lkml/2017/8/18/785

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3 for-next 2/2] RDMA/hns: Fix alignment problem of the doorbell

[Liuyixian (Eason)]

On 2017/12/29 14:48, Leon Romanovsky wrote:
> On Thu, Dec 28, 2017 at 10:18:03PM +0800, Yixian Liu wrote:
>> The array defined for doorbell is not guaranteed to be 64 bit
>> aligned while we write it to the hardware with 64 bit
>> alignment required.
>>
>> This patch fixes this problem by defining a union for doorbell
>> to make sure it 64 bit alignment.
>>
>> v2 -> v3:
>> 1. delete the unnecessary assignment for doorbell64.
>>
>> v2:
>> 1. Consider with Leon's comments, make sure it is 64 bit
>>    alignment by assigning the expected value to the u64
>>    member of the union type, i.e., assign doorbell array
>>    to doorbell64.
> 
> Please put changelog after "---", so it won't be visible in git log.
> See this patch as an example:
> https://lkml.org/lkml/2017/8/18/785
> 
> Thanks
> 

Okay, I will, Thanks!

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