All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: John Garry <john.garry@huawei.com>,
	Xiang Chen <chenxiang66@hisilicon.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: [patch] scsi: hisi_sas: shift vs compare typos
Date: Tue, 29 Nov 2016 10:47:25 +0000	[thread overview]
Message-ID: <20161129104725.GA7623@mwanda> (raw)

There are some typos where we intended "<<" but have "<".  Seems likely
to cause a bunch of problems.

Fixes: d3b688d3c69d ("scsi: hisi_sas: add v2 hw support for ECC and AXI bus fatal error")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
There is another static checker warning to fix perhaps:

	drivers/scsi/hisi_sas/hisi_sas_v2_hw.c:2015 phy_up_v2_hw()
	warn: was expecting a 64 bit value instead of '(2 | 1)'

The code is doing:

	phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA);

phy->phy_type is a u64 and PORT_TYPE_SAS is "1U << 1".  So this code
is clearing out the high 32 bits of ->phy_type uninitentionally.  It's
simple enough to make it 1ULL << 1 but the question is, do we really
need ->phy_type to be a 64 bit variable?  I'm pretty sure that a u32
will suffice.

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 15487f2..93876c0 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -64,19 +64,19 @@
 					 HGC_LM_DFX_STATUS2_ITCTLIST_OFF)
 #define HGC_CQE_ECC_ADDR		0x13c
 #define HGC_CQE_ECC_1B_ADDR_OFF	0
-#define HGC_CQE_ECC_1B_ADDR_MSK	(0x3f < HGC_CQE_ECC_1B_ADDR_OFF)
+#define HGC_CQE_ECC_1B_ADDR_MSK	(0x3f << HGC_CQE_ECC_1B_ADDR_OFF)
 #define HGC_CQE_ECC_MB_ADDR_OFF	8
-#define HGC_CQE_ECC_MB_ADDR_MSK (0x3f < HGC_CQE_ECC_MB_ADDR_OFF)
+#define HGC_CQE_ECC_MB_ADDR_MSK (0x3f << HGC_CQE_ECC_MB_ADDR_OFF)
 #define HGC_IOST_ECC_ADDR		0x140
 #define HGC_IOST_ECC_1B_ADDR_OFF	0
-#define HGC_IOST_ECC_1B_ADDR_MSK	(0x3ff < HGC_IOST_ECC_1B_ADDR_OFF)
+#define HGC_IOST_ECC_1B_ADDR_MSK	(0x3ff << HGC_IOST_ECC_1B_ADDR_OFF)
 #define HGC_IOST_ECC_MB_ADDR_OFF	16
-#define HGC_IOST_ECC_MB_ADDR_MSK	(0x3ff < HGC_IOST_ECC_MB_ADDR_OFF)
+#define HGC_IOST_ECC_MB_ADDR_MSK	(0x3ff << HGC_IOST_ECC_MB_ADDR_OFF)
 #define HGC_DQE_ECC_ADDR		0x144
 #define HGC_DQE_ECC_1B_ADDR_OFF	0
-#define HGC_DQE_ECC_1B_ADDR_MSK	(0xfff < HGC_DQE_ECC_1B_ADDR_OFF)
+#define HGC_DQE_ECC_1B_ADDR_MSK	(0xfff << HGC_DQE_ECC_1B_ADDR_OFF)
 #define HGC_DQE_ECC_MB_ADDR_OFF	16
-#define HGC_DQE_ECC_MB_ADDR_MSK (0xfff < HGC_DQE_ECC_MB_ADDR_OFF)
+#define HGC_DQE_ECC_MB_ADDR_MSK (0xfff << HGC_DQE_ECC_MB_ADDR_OFF)
 #define HGC_INVLD_DQE_INFO		0x148
 #define HGC_INVLD_DQE_INFO_FB_CH0_OFF	9
 #define HGC_INVLD_DQE_INFO_FB_CH0_MSK	(0x1 << HGC_INVLD_DQE_INFO_FB_CH0_OFF)

WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: John Garry <john.garry@huawei.com>,
	Xiang Chen <chenxiang66@hisilicon.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: [patch] scsi: hisi_sas: shift vs compare typos
Date: Tue, 29 Nov 2016 13:47:25 +0300	[thread overview]
Message-ID: <20161129104725.GA7623@mwanda> (raw)

There are some typos where we intended "<<" but have "<".  Seems likely
to cause a bunch of problems.

Fixes: d3b688d3c69d ("scsi: hisi_sas: add v2 hw support for ECC and AXI bus fatal error")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
There is another static checker warning to fix perhaps:

	drivers/scsi/hisi_sas/hisi_sas_v2_hw.c:2015 phy_up_v2_hw()
	warn: was expecting a 64 bit value instead of '(2 | 1)'

The code is doing:

	phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA);

phy->phy_type is a u64 and PORT_TYPE_SAS is "1U << 1".  So this code
is clearing out the high 32 bits of ->phy_type uninitentionally.  It's
simple enough to make it 1ULL << 1 but the question is, do we really
need ->phy_type to be a 64 bit variable?  I'm pretty sure that a u32
will suffice.

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 15487f2..93876c0 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -64,19 +64,19 @@
 					 HGC_LM_DFX_STATUS2_ITCTLIST_OFF)
 #define HGC_CQE_ECC_ADDR		0x13c
 #define HGC_CQE_ECC_1B_ADDR_OFF	0
-#define HGC_CQE_ECC_1B_ADDR_MSK	(0x3f < HGC_CQE_ECC_1B_ADDR_OFF)
+#define HGC_CQE_ECC_1B_ADDR_MSK	(0x3f << HGC_CQE_ECC_1B_ADDR_OFF)
 #define HGC_CQE_ECC_MB_ADDR_OFF	8
-#define HGC_CQE_ECC_MB_ADDR_MSK (0x3f < HGC_CQE_ECC_MB_ADDR_OFF)
+#define HGC_CQE_ECC_MB_ADDR_MSK (0x3f << HGC_CQE_ECC_MB_ADDR_OFF)
 #define HGC_IOST_ECC_ADDR		0x140
 #define HGC_IOST_ECC_1B_ADDR_OFF	0
-#define HGC_IOST_ECC_1B_ADDR_MSK	(0x3ff < HGC_IOST_ECC_1B_ADDR_OFF)
+#define HGC_IOST_ECC_1B_ADDR_MSK	(0x3ff << HGC_IOST_ECC_1B_ADDR_OFF)
 #define HGC_IOST_ECC_MB_ADDR_OFF	16
-#define HGC_IOST_ECC_MB_ADDR_MSK	(0x3ff < HGC_IOST_ECC_MB_ADDR_OFF)
+#define HGC_IOST_ECC_MB_ADDR_MSK	(0x3ff << HGC_IOST_ECC_MB_ADDR_OFF)
 #define HGC_DQE_ECC_ADDR		0x144
 #define HGC_DQE_ECC_1B_ADDR_OFF	0
-#define HGC_DQE_ECC_1B_ADDR_MSK	(0xfff < HGC_DQE_ECC_1B_ADDR_OFF)
+#define HGC_DQE_ECC_1B_ADDR_MSK	(0xfff << HGC_DQE_ECC_1B_ADDR_OFF)
 #define HGC_DQE_ECC_MB_ADDR_OFF	16
-#define HGC_DQE_ECC_MB_ADDR_MSK (0xfff < HGC_DQE_ECC_MB_ADDR_OFF)
+#define HGC_DQE_ECC_MB_ADDR_MSK (0xfff << HGC_DQE_ECC_MB_ADDR_OFF)
 #define HGC_INVLD_DQE_INFO		0x148
 #define HGC_INVLD_DQE_INFO_FB_CH0_OFF	9
 #define HGC_INVLD_DQE_INFO_FB_CH0_MSK	(0x1 << HGC_INVLD_DQE_INFO_FB_CH0_OFF)

             reply	other threads:[~2016-11-29 10:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29 10:47 Dan Carpenter [this message]
2016-11-29 10:47 ` [patch] scsi: hisi_sas: shift vs compare typos Dan Carpenter
2016-11-29 11:20 ` John Garry
2016-11-29 16:28 ` Martin K. Petersen
2016-11-29 16:28   ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161129104725.GA7623@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=john.garry@huawei.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.