mpt3sas: remove unused variables
Subsystems (2)
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
@@ -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
@@ -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 )
James Bottomley
maintainerOK, 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
Signed-off-by Wei Yongjun <[email protected]>Acked-by Sreekanth Reddy <[email protected]>
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
Quoted 8 lines · <[email protected]> writes:
drivers/scsi/mpt3sas/mpt3sas_scsih.c +0
-0@@ -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
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@@ -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