summaryrefslogtreecommitdiffstats
path: root/drivers/s390/scsi
AgeCommit message (Collapse)AuthorFilesLines
2009-12-04[SCSI] zfcp: Update FCP protocol related codeChristof Schmitt7-169/+156
Use common data structures for FCP CMND, FCP RSP and related definitions and remove zfcp private definitions. Split the FCP CMND setup and FCP RSP evaluation code in seperate functions. Use inline functions to not negatively impact the I/O path. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rportChristof Schmitt1-2/+16
If an error occurs that triggers the call to fc_remote_port_delete, ideally this call would happen before any I/O is passed back to the SCSI midlayer through scsi_done. The SCSI midlayer will retry the commands and fc_remote_port_chkready will return the correct status code. But with the delay between calling scsi_done in softirq context and the call to fc_remote_port_delete from the workqueue, there is a window where zfcp returns DID_ERROR. This leads to SCSI error recovery which then leads to offline SCSI devices since all recovery actions will fail with the rport now being blocked. In this window, zfcp has to return DID_IMM_RETRY just as the FC transport class would do in fc_remote_port_chkready for the blocked fc_rport. As soon as the fc_rport is BLOCKED, fc_remote_port_chkready will do the right thing. Additionally, there are two more cases to catch in zfcp_scsi_queuecommand: - After the port has been opened, the unit has to be opened. During this period I/O has to be retried. This can also be handled with DID_IMM_RETRY. - If the access to the unit fails, but the port is good, then this single unit cannot be accessed and I/O to this unit has to fail without involving the FC transport class. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Assign scheduled work to driver queueSwen Schillig6-24/+17
The port_scan work was scheduled to the work_queue provided by the kernel. This resulted on SMP systems to a likely situation that more than one scan_work were processed in parallel. This is not required and openes the possibility of race conditions between the removal of invalid ports and the enqueue of just scanned ports. This patch synchronizes the scan_work tasks by scheduling them to adapter local work_queue. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Remove STATUS_COMMON_REMOVE flag as it is not required anymoreSwen Schillig6-78/+34
The flag ZFCP_STATUS_COMMON_REMOVE was used to indicate that a resource is not ready to be used or about to be removed from the system. This is now better done by an improved list handling and therefore the additional indicator is not required anymore. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Implement module unloadingChristof Schmitt3-13/+14
With the reference counting for zfcp data structures, it is now possible to implement module unloading again. Module unloading requires to free all data structures in the module exit function. This is done by unregistering zfcp from s390 cio and the SCSI midlayer first in the module exit function. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Merge trace code for fsf requests in one functionChristof Schmitt1-54/+39
The latencies traced per fsf request are traced for sysfs output and for blktrace, each in one function. Simplify the tracing code by merging both tracing functions into one. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Access ports and units with container_of in sysfs codeChristof Schmitt2-7/+10
When accessing port and unit attributes, use container_of instead of dev_get_drvdata. This eliminates some code checker warnings about aliased access of data structures. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Remove suspend callbackSwen Schillig1-17/+1
The callback for suspend is not required because it contains exactly the same functionality as the _set_offline routine does. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Remove global config_mutexSwen Schillig7-158/+232
The global config_mutex was required for the serialization of a configuration change within the zfcp driver. This global locking is now obsolete and can be removed. The requirement of serializing the access to a zfcp_adapter reference via a ccw_device is realized wth a static spinlock. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Replace local reference counting with common krefSwen Schillig11-258/+196
Replace the local reference counting by already available mechanisms offered by kref. Where possible existing device structures were used, including the same functionality. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Replace global config_lock with local list locksSwen Schillig8-200/+199
The global config_lock was used to protect the configuration organized in independent lists. It is not necessary to have a lock on driver level for this purpose. This patch replaces the global config_lock with a set of local list locks. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] zfcp: Adapt change_queue_depth for queue full trackingChristof Schmitt1-3/+12
Adapt the change_queue_depth callback in zfcp for the new reason parameter. Simply pass each call back to the SCSI midlayer, there are no resource adjustments necessary for zfcp. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Removes check for (depth <= default_depth) in case of SCSI_QDEPTH_RAMP_UP call back, not needed after added max_queue_depth per sdev. Signed-off-by: Vasu Dev <vasu.dev@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] modify change_queue_depth to take in reason why it is being calledMike Christie1-1/+5
This patch modifies scsi_host_template->change_queue_depth so that it takes an argument indicating why it is being called. This will be used so that if a LLD needs to do some extra processing when handling queue fulls or later ramp ups, it can do so. This is a simple port of the drivers setting a change_queue_depth callback. In the patch I just have these LLDs adjust the queue depth if the user was requesting it. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> [Vasu.Dev: v2 Also converted pmcraid_change_queue_depth and then verified all modules compile using "make allmodconfig" for any new build warnings on X86_64. Updated original description after combing two original patches from Mike to make this patch git bisectable.] Signed-off-by: Vasu Dev <vasu.dev@intel.com> [jejb: fixed up 53c700] Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-22[SCSI] zfcp: Flush SCSI registration work when adding unitChristof Schmitt1-0/+1
When configuring a LUN for use in zfcp, flush the SCSI work to ensure the SCSI device has been created before returning. This means that a configuration procedure can run these commands in a script and the SCSI device is available immediately after the unit_add: echo 1 > /sys/bus/ccw/drivers/zfcp/0.0.181d/online echo 0x401040C300000000 > \ /sys/bus/ccw/drivers/zfcp/0.0.181d/0x500507630313c562/unit_add lsscsi Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-22[SCSI] zfcp: Fix timer initialization for ct and els requestsChristof Schmitt1-1/+1
Add HZ since the start_timer function expects jiffies, not seconds. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-22[SCSI] zfcp: Warn about storage devices with broken PLOGI dataChristof Schmitt1-2/+9
After opening a remote port zfcp checks if the WWPN returned in the PLOGI maches the WWPN of the port that should have been opened. On a mismatch zfcp assumes that the DID just changed, queries the FC nameserver and tries again. If the situation persists the erp will give up. With this strategy, if the remote port always returns the wrong PLOGI data, the remote port will not be opened. Introduce a warning, so that the system administrator knows why the remote port is not being opened and to have a pointer to investigate the problem on the storage system. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-22[SCSI] zfcp: Handle WWPN mismatch in PLOGI payloadChristof Schmitt3-12/+22
For ports, zfcp gets the DID from the FC nameserver and tries to open the port. If the open succeeds, zfcp compares the WWPN from the nameserver with the WWPN in the PLOGI payload. In case of a mismatch, zfcp assumes that the DID of the port just changed and we opened the wrong port. This means that zfcp has to forget the DID, lookup the DID again and retry. This error case had a problem that zfcp forgets the DID, but never looks up a new one, stalling the ERP in this case. Fix this by triggering the DID lookup and properly exit from the ERP. The DID lookup will trigger a new ERP action. Also ensure when trying to open the port again with the new DID, first close the open port, even in the NOESC case. Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-22[SCSI] zfcp: fix kfree handling in zfcp_init_device_setupHeiko Carstens1-5/+6
The pointer that is allocated with kmalloc() is passed to strsep() which modifies it. Later on the modified pointer value will be passed to kfree. Save the original pointer and pass that one to kfree instead. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-02[SCSI] zfcp: Fix hang when offlining device with offline chpidChristof Schmitt2-5/+5
Running chchp --vary 0 and chccwdev -d on a FCP device with scsi devices attached can lead to this thread hanging: ================================================================ STACK TRACE FOR TASK: 0x2fbfcc00 (kslowcrw) STACK: 0 schedule+1136 [0x45f99c] 1 schedule_timeout+534 [0x46054e] 2 wait_for_common+374 [0x45f442] 3 blk_execute_rq+160 [0x217a2c] 4 scsi_execute+278 [0x26daf2] 5 scsi_execute_req+150 [0x26dc86] 6 sd_sync_cache+138 [0x28460a] 7 sd_shutdown+130 [0x28486a] 8 sd_remove+104 [0x284c84] 9 __device_release_driver+152 [0x257430] 10 device_release_driver+56 [0x2575c8] 11 bus_remove_device+214 [0x25672a] 12 device_del+352 [0x25456c] 13 __scsi_remove_device+108 [0x272630] 14 scsi_remove_device+66 [0x2726ba] 15 zfcp_ccw_remove+824 [0x335558] 16 ccw_device_remove+62 [0x2b3f2a] 17 __device_release_driver+152 [0x257430] 18 device_release_driver+56 [0x2575c8] 19 bus_remove_device+214 [0x25672a] 20 device_del+352 [0x25456c] 21 ccw_device_unregister+92 [0x2b48c4] 22 io_subchannel_remove+108 [0x2b4950] 23 css_remove+62 [0x2af7ee] 24 __device_release_driver+152 [0x257430] 25 device_release_driver+56 [0x2575c8] 26 bus_remove_device+214 [0x25672a] 27 device_del+352 [0x25456c] 28 device_unregister+38 [0x25464a] 29 css_sch_device_unregister+68 [0x2af97c] 30 ccw_device_call_sch_unregister+78 [0x2b581e] 31 worker_thread+604 [0x69eb0] 32 kthread+154 [0x6ff42] 33 kernel_thread_starter+6 [0x1c952] ================================================================ The problem is that the chchp --vary 0 leads to zfcp first calling fc_remote_port_delete which blocks all scsi devices on the remote port. Calling scsi_remove_device later lets the sd driver issue a SYNCHRONIZE_CACHE command. This command stays on the "stopped" request requeue because the SCSI device is blocked. Fix this by first removing the scsi and fc hosts which removes all scsi devices and do not use scsi_remove_device. Reviewed-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-02[SCSI] zfcp: Fix lockdep warning when offlining device with offline chpidChristof Schmitt2-1/+4
======================================================= [ INFO: possible circular locking dependency detected ] 2.6.31-39.x.20090917-s390xdefault #1 ------------------------------------------------------- kslowcrw/83 is trying to acquire lock: (&adapter->scan_work){+.+.+.}, at: [<0000000000169c5c>] __cancel_work_timer+0x64/0x3d4 but task is already holding lock: (&zfcp_data.config_mutex){+.+.+.}, at: [<00000000004671ea>] zfcp_ccw_remove+0x66/0x384 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&zfcp_data.config_mutex){+.+.+.}: [<0000000000189962>] __lock_acquire+0xe26/0x1834 [<000000000018a4b6>] lock_acquire+0x146/0x178 [<000000000058cb5a>] mutex_lock_nested+0x82/0x3ec [<0000000000477170>] zfcp_fc_scan_ports+0x3ec/0x728 [<0000000000168e34>] worker_thread+0x278/0x3a8 [<000000000016ff08>] kthread+0x9c/0xa4 [<0000000000109ebe>] kernel_thread_starter+0x6/0xc [<0000000000109eb8>] kernel_thread_starter+0x0/0xc -> #0 (&adapter->scan_work){+.+.+.}: [<0000000000189e60>] __lock_acquire+0x1324/0x1834 [<000000000018a4b6>] lock_acquire+0x146/0x178 [<0000000000169c9a>] __cancel_work_timer+0xa2/0x3d4 [<0000000000465cb2>] zfcp_adapter_dequeue+0x32/0x14c [<00000000004673e4>] zfcp_ccw_remove+0x260/0x384 [<00000000004250f6>] ccw_device_remove+0x42/0x1ac [<00000000003cb6be>] __device_release_driver+0x9a/0x10c [<00000000003cb856>] device_release_driver+0x3a/0x4c [<00000000003ca94c>] bus_remove_device+0xcc/0x114 [<00000000003c8506>] device_del+0x162/0x21c [<0000000000425ff2>] ccw_device_unregister+0x5e/0x7c [<000000000042607e>] io_subchannel_remove+0x6e/0x9c [<000000000041ff9a>] css_remove+0x3e/0x7c [<00000000003cb6be>] __device_release_driver+0x9a/0x10c [<00000000003cb856>] device_release_driver+0x3a/0x4c [<00000000003ca94c>] bus_remove_device+0xcc/0x114 [<00000000003c8506>] device_del+0x162/0x21c [<00000000003c85e8>] device_unregister+0x28/0x38 [<0000000000420152>] css_sch_device_unregister+0x46/0x58 [<00000000004276a6>] io_subchannel_sch_event+0x28e/0x794 [<0000000000420442>] css_evaluate_known_subchannel+0x46/0xd0 [<0000000000420ebc>] slow_eval_known_fn+0x88/0xa0 [<00000000003caffa>] bus_for_each_dev+0x7e/0xd0 [<000000000042188c>] for_each_subchannel_staged+0x6c/0xd4 [<0000000000421a00>] css_slow_path_func+0x54/0xd8 [<0000000000168e34>] worker_thread+0x278/0x3a8 [<000000000016ff08>] kthread+0x9c/0xa4 [<0000000000109ebe>] kernel_thread_starter+0x6/0xc [<0000000000109eb8>] kernel_thread_starter+0x0/0xc cancel_work_sync is called while holding the config_mutex. But the work that is being cancelled or flushed also uses the config_mutex. Fix the resulting deadlock possibility by calling cancel_work_sync earlier without holding the mutex. The best place to do is is after offlining the device. No new port scan work will be scheduled for the offline device, so this is a safe place to call cancel_work_sync. Reviewed-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-02[SCSI] zfcp: Fix oops during shutdown of offline deviceChristof Schmitt1-4/+4
With the change that the zfcp_adapter struct is only allocated when the device is set online, the shutdown handler has to check for a non-existing zfcp_adapter struct. On the other hand, this check is not necessary in the offline callback, since an online device has the zfcp_adapter allocated and we go through the offline callback before removing the ccw device. Reviewed-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-02[SCSI] zfcp: Fix initial device and cfdc for delayed adapter allocationChristof Schmitt4-31/+38
With the change for delaying the allocation of zfcp_adapter, the initial device parameter function has to first call ccw_device_set_online which allocates the zfcp_adapter structure. Change this and adapt the cfdc part accordingly. Reviewed-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-10-02[SCSI] zfcp: correctly initialize unchained requestsChristof Schmitt1-4/+18
The common initialization of ct/gs and els requests missed the initialization of unchained requests. Fix this by moving the common parts to a place that is called for all ct/gs and els requests. Reviewed-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-21trivial: remove unnecessary semicolonsJoe Perches1-1/+1
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-09-05[SCSI] zfcp: optimize zfcp_qdio_accountHeiko Carstens2-7/+6
Remove expensive ktime_get()/ktime_us_delta() functions from the hot path and use get_clock_monotonic() instead. This elimates seven function calls and avoids a lot of unnecessary calculations. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Remove duplicated code for debug timestampsChristof Schmitt1-16/+3
The timestamp calculation used for s390dbf output is the same in a private zfcp function and in debug.c. Replace both with a common inline function. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Handle failures during device allocation correctlyChristof Schmitt1-36/+29
dev_set_name tries to allocate memory, so check the return value for allocation failures. After dev_set_name succeeds, call device_register as next step to be able to use put_device during error handling. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: proper use of device registerSebastian Ott1-4/+8
Don't use kfree directly after device registration started. Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Replace config semaphore with mutexChristof Schmitt5-33/+32
The config semaphore is only used as a mutex, so replace it with a simple mutex. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Defer resource allocation to first ccw_set_online callChristof Schmitt3-31/+54
So far, zfcp allocated all resources required for FCP adapters/subchannels when the device was discovered in the ccw_probe callback. If there are lots of unused FCP subchannels attached to a system, this is a waste of resources. To alleviate this, defer the resource allocation to the first call to ccw_set_online. To avoid disruptions during possible following calls to ccw_set_offline and then ccw_set_online, keep the adapter resources until the device is finally being removed via ccw_remove. While doing this, also manage the zfcp erp thread together with all other adapter resources in zfcp_adapter_enqueue/dequeue. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Simplify and update ct/gs and els timeout handlingChristof Schmitt3-17/+6
The recommendation for a timeout of 2 * R_A_TOV is the same for ct/gs and els requests, so set it in the common function used for initializing both request types. Besides, the timer inside zfcp should only run longer than the timeout set for the channel, so 10 seconds more should be enough (instead of 60 seconds). Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Use kthread API for zfcp erp threadChristof Schmitt3-45/+27
Switch the creation of the zfcp erp thread from the deprecated kernel_thread API to the kthread API. This allows also the removal of some flags in zfcp since the kthread API handles thread creation and shutdown internally. To allow the usage of the kthread_stop function, replace the erp ready semaphore with a waitqueue for waiting until erp actions arrive on the ready queue. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: resolve false usage of dd_data in fc_rportSwen Schillig3-23/+5
The fc_rport structure reserves a reference where a LLD can put information required in a situation where the fc transport class is triggering LLD callbacks. The zfcp driver was using this variable directly which is discouraged. This patch solves this issue by making this reference unnecessary. In addition the dev_loss_tmo callback is removed, it is not required: zfcp does not access the fc_rport after calling fc_remote_port_delete. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Apply common naming conventions to zfcp_fcSwen Schillig5-36/+35
Update the Fibre Channel related code to use the zfcp_fc prefix. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: introduce _setup, _destroy for qdio and FCSwen Schillig4-64/+89
Extract independent data structures and introduce common _setup and _destroy routines for QDIO and Fibre Channel related data structures Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Update dbf callsSwen Schillig9-380/+347
Change the dbf data and functions to use the zfcp_dbf prefix throughout the code. Also change the calls to dbf to use zfcp_dbf instead of zfcp_adapter. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Decouple gid_pn requests from erpChristof Schmitt6-56/+47
Don't let the erp wait for gid_pn requests to complete. Instead, queue the gid_pn work, exit erp and let the finished gid_pn work trigger a new port reopen. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Move qdio related data out of zfcp_adapterSwen Schillig9-296/+343
The zfcp_adapter structure was growing over time to a size of almost one memory page. To reduce the size of the data structure and to seperate different layers, put all qdio related data in the new zfcp_qdio data structure. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Separate qdio attributes from zfcp_fsf_reqSwen Schillig5-115/+160
Split all qdio related attributes out of zfcp_fsf_req and put it in new structure. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Move workqueue to adapter structSwen Schillig6-8/+34
Remove the global driver work queue and replace it with a workqueue local to the adapter. The usage of this workqueue makes this the correct place for the structure. In addition multiple adapters won't block each other due to the serialization of the queued work. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Remove the useless ZFCP_REQ_AUTO_CLEANUP flagSwen Schillig1-35/+45
The flag ZFCP_REQ_AUTO_CLEANUP was useless as the ZFCP_STATUS_FSFREQ_CLEANUP flag is there for exactly the same purpose. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Improve request allocation through mempoolsSwen Schillig4-113/+127
Remove the special case for NO_QTCB requests and optimize the mempool and cache processing for fsfreqs. Especially use seperate mempools for the zfcp_fsf_req and zfcp_qtcb structs. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Replace fsf_req wait_queue with completionSwen Schillig4-28/+10
The combination wait_queue/wakeup in conjunction with the flag ZFCP_STATUS_FSFREQ_COMPLETED to signal the completion of an fsfreq was not race-safe and can be better solved by a completion. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: fix layering oddities between zfcp_fsf and zfcp_qdioSwen Schillig3-74/+73
There is no need for the QDIO layer to have knowledge or do things wich are done better by the FSF layer and vice versa. Straighten a few things to improve vividness. Signed-off-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Implicitly close all wka portsChristof Schmitt4-5/+13
An adapter shutdown implicitly closes all open ports. Make sure to mark all WKA ports as offline, not only the directory server. Also make sure that no pending wka port work is running when the adapter is being removed. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Only issue one test link command per portChristof Schmitt2-0/+10
When the FCP channel returns a series of commands with the error status "test link", zfcp will send a series of ELS ADISC commands. This is technically no problem, but it is enough to only issue one test command per remote port. So, track whether a ELS ADISC command is already pending, and do not send a new one if there is already a pending command. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Remove useless assignmentChristof Schmitt1-1/+0
Using a bitwise OR to not set anything at all is pointless so remove the useless statement. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Only collect FSF/HBA debug data for matching trace levelsChristof Schmitt3-39/+67
The default trace level is to only trace failed FSF commands. Thus it is not necessary to collect trace data for most FSF commands, since it will be thrown away later. Restructure the FSF/HBA trace infrastructure to first check the trace level in a inline function and only do the expensive data collection for matching trace levels. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Only collect SCSI debug data for matching trace levelsChristof Schmitt5-63/+73
The default trace level is to only trace failed SCSI commands. Thus it is not necessary to collect trace data for most SCSI commands since it will be thrown away later. Restructure the SCSI trace infrastructure to first check the trace level in a inline function and only do the expensive data collection for matching trace levels. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-09-05[SCSI] zfcp: Move debug data from zfcp_data to own data structureChristof Schmitt5-113/+143
The struct zfcp_adapter includes everything related to the debug traces. This introduces dependences between the definitions in zfcp_def.h and zfcp_dbf.h. Move all debug related data structures to a new data structure to break those dependencies and manage the debug data in zfcp_dbf.[hc]. Reviewed-by: Swen Schillig <swen@vnet.ibm.com> Signed-off-by: Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>