[PATCH 1/2] staging: unisys: remove unused variable

[PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

The variables op, sd and zmotion were never being used.

Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 4 ----
 drivers/staging/unisys/visorinput/visorinput.c  | 4 +---
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c b/drivers/staging/unisys/visorhba/visorhba_main.c
index c119f20..593a486 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -453,7 +453,6 @@ visorhba_queue_command_lck(struct scsi_cmnd *scsicmd,
 	struct uiscmdrsp *cmdrsp;
 	struct scsi_device *scsidev = scsicmd->device;
 	int insert_location;
-	unsigned char op;
 	unsigned char *cdb = scsicmd->cmnd;
 	struct Scsi_Host *scsihost = scsidev->host;
 	unsigned int i;
@@ -511,7 +510,6 @@ visorhba_queue_command_lck(struct scsi_cmnd *scsicmd,
 	}
 	cmdrsp->scsi.guest_phys_entries = scsi_sg_count(scsicmd);
 
-	op = cdb[0];
 	if (!visorchannel_signalinsert(devdata->dev->visorchannel,
 				       IOCHAN_TO_IOPART,
 				       cmdrsp)) {
@@ -759,11 +757,9 @@ do_scsi_linuxstat(struct uiscmdrsp *cmdrsp, struct scsi_cmnd *scsicmd)
 	struct visorhba_devdata *devdata;
 	struct visordisk_info *vdisk;
 	struct scsi_device *scsidev;
-	struct sense_data *sd;
 
 	scsidev = scsicmd->device;
 	memcpy(scsicmd->sense_buffer, cmdrsp->scsi.sensebuf, MAX_SENSE_SIZE);
-	sd = (struct sense_data *)scsicmd->sense_buffer;
 
 	/* Do not log errors for disk-not-present inquiries */
 	if ((cmdrsp->scsi.cmnd[0] == INQUIRY) &&
diff --git a/drivers/staging/unisys/visorinput/visorinput.c b/drivers/staging/unisys/visorinput/visorinput.c
index 5c16f66..38d4d5b 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -523,7 +523,7 @@ visorinput_channel_interrupt(struct visor_device *dev)
 	struct ultra_inputreport r;
 	int scancode, keycode;
 	struct input_dev *visorinput_dev;
-	int xmotion, ymotion, zmotion, button;
+	int xmotion, ymotion, button;
 	int i;
 
 	struct visorinput_devdata *devdata = dev_get_drvdata(&dev->device);
@@ -604,12 +604,10 @@ visorinput_channel_interrupt(struct visor_device *dev)
 			}
 			break;
 		case inputaction_wheel_rotate_away:
-			zmotion = r.activity.arg1;
 			input_report_rel(visorinput_dev, REL_WHEEL, 1);
 			input_sync(visorinput_dev);
 			break;
 		case inputaction_wheel_rotate_toward:
-			zmotion = r.activity.arg1;
 			input_report_rel(visorinput_dev, REL_WHEEL, -1);
 			input_sync(visorinput_dev);
 			break;
-- 
1.9.1

[PATCH 2/2] staging: unisys: return error value directly

[Sudip Mukherjee]

In case of error we are jumping to err_del_scsipending_ent and always
returning SCSI_MLQUEUE_DEVICE_BUSY from error path. We donot need a
variable to return a fixed error value, it can be returned directly.

Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
 drivers/staging/unisys/visorhba/visorhba_main.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c b/drivers/staging/unisys/visorhba/visorhba_main.c
index 593a486..d5178b4 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -460,7 +460,6 @@ visorhba_queue_command_lck(struct scsi_cmnd *scsicmd,
 		(struct visorhba_devdata *)scsihost->hostdata;
 	struct scatterlist *sg = NULL;
 	struct scatterlist *sglist = NULL;
-	int err = 0;
 
 	if (devdata->serverdown || devdata->serverchangingstate)
 		return SCSI_MLQUEUE_DEVICE_BUSY;
@@ -495,10 +494,8 @@ visorhba_queue_command_lck(struct scsi_cmnd *scsicmd,
 	if (cmdrsp->scsi.bufflen > devdata->max_buff_len)
 		devdata->max_buff_len = cmdrsp->scsi.bufflen;
 
-	if (scsi_sg_count(scsicmd) > MAX_PHYS_INFO) {
-		err = SCSI_MLQUEUE_DEVICE_BUSY;
+	if (scsi_sg_count(scsicmd) > MAX_PHYS_INFO)
 		goto err_del_scsipending_ent;
-	}
 
 	/* convert buffer to phys information  */
 	/* buffer is scatterlist - copy it out */
@@ -512,16 +509,15 @@ visorhba_queue_command_lck(struct scsi_cmnd *scsicmd,
 
 	if (!visorchannel_signalinsert(devdata->dev->visorchannel,
 				       IOCHAN_TO_IOPART,
-				       cmdrsp)) {
+				       cmdrsp))
 		/* queue must be full and we aren't going to wait */
-		err = SCSI_MLQUEUE_DEVICE_BUSY;
 		goto err_del_scsipending_ent;
-	}
+
 	return 0;
 
 err_del_scsipending_ent:
 	del_scsipending_ent(devdata, insert_location);
-	return err;
+	return SCSI_MLQUEUE_DEVICE_BUSY;
 }
 
 /**
-- 
1.9.1

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

On Tue, Feb 10, 2015 at 02:34:15PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote:
> > > 
> > > But as I've missed this in the past, nevermind, I'll take it as is.  Can
> > > you resend your outstanding patches and I'll queue them up after
> > > 3.20-rc1 is out.
> > i will resend them now or should i send after the merge window closes?
> 
> You can send patches any time, I'll batch them up and apply them to my
> trees at the proper time.
i have sent them as v2, i think i should have sent as [PATCH resend]  :(

sudip 

> 

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

On Tue, Feb 10, 2015 at 02:34:15PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote:
> 
> Nothing to do on your side, I am on the road this week and will move
> those to my -next branch right now, thanks for reminding me.

welcome sir. If you ever need an assisstant (for reminding or for coding)  you can count me in :)

I can see that you are in HongKong now, please do let us know if you ever plan to be on the roads in India. I am sure all of us here will like to meet you. we can have a beer or two while learning few things from you.

sudip

> 
> greg k-h

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Greg Kroah-Hartman]

On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote:
> > > if you want I can add an extra From: line, but Dan has already given his commments for that at https://lkml.org/lkml/2014/9/3/135
> > > quoting him :
> > > 
> > > "If everyone starts using From headers like this then it becomes a pain to deal with."
> > 
> > It's not a pain to deal with on my end at all.
> > 
> > But as I've missed this in the past, nevermind, I'll take it as is.  Can
> > you resend your outstanding patches and I'll queue them up after
> > 3.20-rc1 is out.
> i will resend them now or should i send after the merge window closes?

You can send patches any time, I'll batch them up and apply them to my
trees at the proper time.

> and on 07th feb you have added my two patches to staging-testing, but
> it still is not in linux-next, do i need to resend them also or they
> are in process so nothing to do from my side?

Nothing to do on your side, I am on the road this week and will move
those to my -next branch right now, thanks for reminding me.

greg k-h

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

On Tue, Feb 10, 2015 at 05:35:40AM +0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 08, 2015 at 04:31:07PM +0530, Sudip Mukherjee wrote:
> > On Sat, Feb 07, 2015 at 05:22:16PM +0800, Greg Kroah-Hartman wrote:
> > > On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote:
> > > > we were getting lots of warnings about _tempresult set but not used.
> > > > _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
> > > > which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
> > > > but the vallue assigned to it was never used.
> > > > 
> > > > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> > > 
> > > Your From: address, and this address don't match, so I can't take this
> > > :(
> > 
> > all my patches have been like this way, and you have taken them before :)
> > the reason its like this way - (already discussed with Dan Carpenter, reference https://lkml.org/lkml/2014/9/3/473)
> > 
> > we have strict DMARC check for the corporate mail server. DMARC = domain based message authentication.
> > So the mail i sent reached all the list subscriber from a different server than our designated server,
> > and as a result it is marked as spam in many places and I have already received a few complaints regarding that.
> > 
> > so at https://lkml.org/lkml/2014/9/3/535 Dan said its ok for him, but depends on you if you want to accept.
> > And since you have accepted all my patches before so i thought it is ok with you.
> 
> I didn't notice it before, sorry.

no problem. we all know how much busy you are .. :)

> 
> > if you want I can add an extra From: line, but Dan has already given his commments for that at https://lkml.org/lkml/2014/9/3/135
> > quoting him :
> > 
> > "If everyone starts using From headers like this then it becomes a pain to deal with."
> 
> It's not a pain to deal with on my end at all.
> 
> But as I've missed this in the past, nevermind, I'll take it as is.  Can
> you resend your outstanding patches and I'll queue them up after
> 3.20-rc1 is out.
i will resend them now or should i send after the merge window closes?
and on 07th feb you have added my two patches to staging-testing, but it still is not in linux-next, do i need to resend them also or they are in process so nothing to do from my side?

regards
sudip

> 
> thanks,
> 
> greg k-h

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Greg Kroah-Hartman]

On Sun, Feb 08, 2015 at 04:31:07PM +0530, Sudip Mukherjee wrote:
> On Sat, Feb 07, 2015 at 05:22:16PM +0800, Greg Kroah-Hartman wrote:
> > On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote:
> > > we were getting lots of warnings about _tempresult set but not used.
> > > _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
> > > which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
> > > but the vallue assigned to it was never used.
> > > 
> > > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> > 
> > Your From: address, and this address don't match, so I can't take this
> > :(
> 
> all my patches have been like this way, and you have taken them before :)
> the reason its like this way - (already discussed with Dan Carpenter, reference https://lkml.org/lkml/2014/9/3/473)
> 
> we have strict DMARC check for the corporate mail server. DMARC = domain based message authentication.
> So the mail i sent reached all the list subscriber from a different server than our designated server,
> and as a result it is marked as spam in many places and I have already received a few complaints regarding that.
> 
> so at https://lkml.org/lkml/2014/9/3/535 Dan said its ok for him, but depends on you if you want to accept.
> And since you have accepted all my patches before so i thought it is ok with you.

I didn't notice it before, sorry.

> if you want I can add an extra From: line, but Dan has already given his commments for that at https://lkml.org/lkml/2014/9/3/135
> quoting him :
> 
> "If everyone starts using From headers like this then it becomes a pain to deal with."

It's not a pain to deal with on my end at all.

But as I've missed this in the past, nevermind, I'll take it as is.  Can
you resend your outstanding patches and I'll queue them up after
3.20-rc1 is out.

thanks,

greg k-h

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

On Sat, Feb 07, 2015 at 05:22:16PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote:
> > we were getting lots of warnings about _tempresult set but not used.
> > _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
> > which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
> > but the vallue assigned to it was never used.
> > 
> > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> 
> Your From: address, and this address don't match, so I can't take this
> :(

all my patches have been like this way, and you have taken them before :)
the reason its like this way - (already discussed with Dan Carpenter, reference https://lkml.org/lkml/2014/9/3/473)

we have strict DMARC check for the corporate mail server. DMARC = domain based message authentication.
So the mail i sent reached all the list subscriber from a different server than our designated server,
and as a result it is marked as spam in many places and I have already received a few complaints regarding that.

so at https://lkml.org/lkml/2014/9/3/535 Dan said its ok for him, but depends on you if you want to accept.
And since you have accepted all my patches before so i thought it is ok with you.

if you want I can add an extra From: line, but Dan has already given his commments for that at https://lkml.org/lkml/2014/9/3/135
quoting him :

"If everyone starts using From headers like this then it becomes a pain to deal with."

please let me know how you want me to send the patches if different email address is a problem. I thought different name is a problem, but different email address???

> 
> Fix that up please and resend.
> 
> Also, what tool generated those warnings?
just make W=1 will give these warnings.

regards
sudip
> 
> thanks,
> 
> greg k-h

Re: [PATCH 1/2] staging: unisys: remove unused variable

[Greg Kroah-Hartman]

On Fri, Feb 06, 2015 at 06:13:21PM +0530, Sudip Mukherjee wrote:
> we were getting lots of warnings about _tempresult set but not used.
> _tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
> which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
> but the vallue assigned to it was never used.
> 
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>

Your From: address, and this address don't match, so I can't take this
:(

Fix that up please and resend.

Also, what tool generated those warnings?

thanks,

greg k-h

[PATCH 1/2] staging: unisys: remove unused variable

[Sudip Mukherjee]

we were getting lots of warnings about _tempresult set but not used.
_tempresult was used in the macro ISSUE_IO_VMCALL_POSTCODE_SEVERITY
which was again using another macro ISSUE_IO_EXTENDED_VMCALL.
but the vallue assigned to it was never used.

Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
 drivers/staging/unisys/common-spar/include/vmcallinterface.h | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/common-spar/include/vmcallinterface.h b/drivers/staging/unisys/common-spar/include/vmcallinterface.h
index 7833371..59a7459 100644
--- a/drivers/staging/unisys/common-spar/include/vmcallinterface.h
+++ b/drivers/staging/unisys/common-spar/include/vmcallinterface.h
@@ -79,18 +79,15 @@ enum vmcall_monitor_interface_method_tuple { /* VMCALL identification tuples  */
 #define ISSUE_IO_VMCALL(method, param, result) \
 	(result = unisys_vmcall(method, (param) & 0xFFFFFFFF,	\
 				(param) >> 32))
-#define ISSUE_IO_EXTENDED_VMCALL(method, param1, param2,	\
-				 param3, result)			\
-	(result = unisys_extended_vmcall(method, param1,	\
-					 param2, param3))
+#define ISSUE_IO_EXTENDED_VMCALL(method, param1, param2, param3) \
+	unisys_extended_vmcall(method, param1, param2, param3)
 
     /* The following uses VMCALL_POST_CODE_LOGEVENT interface but is currently
      * not used much */
 #define ISSUE_IO_VMCALL_POSTCODE_SEVERITY(postcode, severity)		\
 do {									\
-	u32 _tempresult = VMCALL_SUCCESS;				\
 	ISSUE_IO_EXTENDED_VMCALL(VMCALL_POST_CODE_LOGEVENT, severity,	\
-				 MDS_APPOS, postcode, _tempresult);	\
+				 MDS_APPOS, postcode);			\
 } while (0)
 #endif
 
-- 
1.8.1.2