Skip to contentSkip to conversation

mpt3sas: remove unused variables

PATCH In review [email protected] 4 participants 4 messages Dec 11, 2012 – Jan 9, 2013

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mpt3sas: remove unused variables

The variable 'chain_flags' and 'phy_number' are initialized but never used otherwise, So remove those unused variables.

---

drivers/scsi/mpt3sas/mpt3sas_base.c +1 -3
index 764f3fe..157746d 100644
@@ -1309,7 +1309,6 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc,
 	void *sg_local, *chain;
 	u32 chain_offset;
 	u32 chain_length;
-	u32 chain_flags;
 	int sges_left;
 	u32 sges_in_segment;
 	u8 simple_sgl_flags;
@@ -1355,8 +1354,7 @@ _base_build_sg_scmd_ieee(struct MPT3SAS_ADAPTER *ioc,
 		sges_in_segment--;
 	}
 
-	/* initializing the chain flags and pointers */
-	chain_flags = MPI2_SGE_FLAGS_CHAIN_ELEMENT << MPI2_SGE_FLAGS_SHIFT;
+	/* initializing the pointers */
 	chain_req = _base_get_chain_buffer_tracker(ioc, smid);
 	if (!chain_req)
 		return -1;
drivers/scsi/mpt3sas/mpt3sas_scsih.c +0 -2
index ac9dbc2..61a1a45 100644
@@ -2754,13 +2754,11 @@ _scsih_block_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc,
 	int i;
 	u16 handle;
 	u16 reason_code;
-	u8 phy_number;
 
 	for (i = 0; i < event_data->NumEntries; i++) {
 		handle = le16_to_cpu(event_data->PHY[i].AttachedDevHandle);
 		if (!handle)
 			continue;
-		phy_number = event_data->StartPhyNum + i;
 		reason_code = event_data->PHY[i].PhyStatus &
 		    MPI2_EVENT_SAS_TOPO_RC_MASK;
 		if (reason_code == MPI2_EVENT_SAS_TOPO_RC_DELAY_NOT_RESPONDING)
maintainer
#1 lore raw

OK, so I'll give you a B for effort on this one, but:

Quoted 3 lines · On Wed, 2012-12-12 at 02:26 +0530, [email protected] wrote:

The variable 'chain_flags' and 'phy_number' are initialized but never used otherwise,
So remove those unused variables.

There has to be a

From: Wei Yongjun <[email protected]>

At the beginning of this patch so git gets the authorship correct

Quoted 3 lines

And this should be Signed-off-by: you not acked-by, because you sent the patch to me (signoffs follow the trail of transmission).

I've fixed all of this up, for this one time.

James

#2 lore raw
In reply to [email protected]
Quoted 8 lines · <[email protected]> writes:
drivers/scsi/mpt3sas/mpt3sas_scsih.c +0 -0
index ac9dbc2..61a1a45 100644
@@ -2754,13 +2754,11 @@ _scsih_block_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc,
 	int i;
 	u16 handle;
 	u16 reason_code;

drivers/scsi/mpt3sas/mpt3sas_scsih.c _scsih_block_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc, · line 2764

Quoted 10 lines
drivers/scsi/mpt3sas/mpt3sas_scsih.c +0 -2
-	u8 phy_number;
 
 	for (i = 0; i < event_data->NumEntries; i++) {
 		handle = le16_to_cpu(event_data->PHY[i].AttachedDevHandle);
 		if (!handle)
 			continue;
-		phy_number = event_data->StartPhyNum + i;
 		reason_code = event_data->PHY[i].PhyStatus &
 		    MPI2_EVENT_SAS_TOPO_RC_MASK;
 		if (reason_code == MPI2_EVENT_SAS_TOPO_RC_DELAY_NOT_RESPONDING)

There is an identical copy of this code, including that bug, in drivers/scsi/mpt2sas/mpt2sas_scsih.c.

If you insist on the stupid code duplication, then please try to keep your bugs syncronized! If you are going to fix this bug for the mpt3sas driver, then you *have* to fix it for mpt2sas as well.

Yes, I believe this is a mess and you have already demonstrated that you are incapable of managing it.

Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#3 lore raw

Bjorn,

We will fix this bug in both mpt2sas and mpt3sas.
Please note that we currently periodically release new features and defect fixes for both mpt2sas and mpt3sas. Most of these are then posted to upstream. We have a very well defined LSI internal process for synchronizing the defect fixes across the 2 drivers. A deliberate choice was made to keep the mpt3sas separate from mpt2sas due to our 6 GIG product being truly mature with a noticeable ramping down of enhancements/releases.

mpt3sas is at it's initial baseline with a healthy roadmap ahead. Architecturally there will be changes to the headers that will be only mpt3sas specific.

From a maintenance and test perspective having the source base separate actually reduces the so called maintenance "hell".

This is not a “mess” . LSI is fully capable of managing this software.

Regards,
Nagalakshmi

-----Original Message-----
From: Bjørn Mork [mailto:[email protected]]
Sent: Monday, December 17, 2012 6:55 PM
To: Reddy, Sreekanth
Cc: [email protected]; [email protected]; [email protected]; [email protected]; Nandigama, Nagalakshmi
Subject: Re: [PATCH -next] [SCSI] mpt3sas: remove unused variables

Quoted 9 lines · <[email protected]> writes:
drivers/scsi/mpt3sas/mpt3sas_scsih.c +0 -0
index ac9dbc2..61a1a45 100644
@@ -2754,13 +2754,11 @@ _scsih_block_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc,
 	int i;
 	u16 handle;
 	u16 reason_code;

drivers/scsi/mpt3sas/mpt3sas_scsih.c _scsih_block_io_to_children_attached_directly(struct MPT3SAS_ADAPTER *ioc, · line 2764

Quoted 10 lines
drivers/scsi/mpt3sas/mpt3sas_scsih.c +0 -2
-	u8 phy_number;
 
 	for (i = 0; i < event_data->NumEntries; i++) {
 		handle = le16_to_cpu(event_data->PHY[i].AttachedDevHandle);
 		if (!handle)
 			continue;
-		phy_number = event_data->StartPhyNum + i;
 		reason_code = event_data->PHY[i].PhyStatus &
 		    MPI2_EVENT_SAS_TOPO_RC_MASK;
 		if (reason_code == MPI2_EVENT_SAS_TOPO_RC_DELAY_NOT_RESPONDING)

There is an identical copy of this code, including that bug, in drivers/scsi/mpt2sas/mpt2sas_scsih.c.

If you insist on the stupid code duplication, then please try to keep your bugs syncronized! If you are going to fix this bug for the mpt3sas driver, then you *have* to fix it for mpt2sas as well.

Yes, I believe this is a mess and you have already demonstrated that you are incapable of managing it.

Bjørn