Introduce kmem_cache for ELS ADISC data to guarantee the required
hardware alignment and free the allocated memory in case the send
failes.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Remove some redundancies in FC related code and trace:
- drop redundant data from SAN trace (local s_id that only changes
  during link down, ls_code that is already part of payload, d_id in
  ct response trace that is always the same as in ct request trace)
- use one common fsf struct to hold zfcp data for ct and els requests
- leverage common fsf struct for FC passthrough job data, allocate it
  with dd_bsg_data for passthrough requests and unify common code for
  ct and els passthrough request
- simplify callback handling in zfcp_fc
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Instead of assigning 4 bytes with the highest byte masked out, use a 3
byte array with the ntoh24 and h24ton helper functions, thus
eliminating the need for the ZFCP_DID_MASK.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The well-known-address (WKA) port handling code is part of the FC code
in zfcp. Move everything WKA related to the zfcp_fc files and use the
common zfcp_fc prefix for structs and functions. Drop the unused key
management service while renaming the struct, no request could ever
reach this service in zfcp and it is obsolete anyway.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Use common code definitions for FC GPN_FT and GID_PN
instead of inventing private ones. Move the private structs still
required inside zfcp to zfcp_fc header file.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Use common code definitions for FC plogi, logo, rscn and adisc structs
instead of inventing private ones. Move the private struct for issuing
ELS ADISC inside zfcp to zfcp_fc header file.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The callback for suspend is not required because it contains exactly
the same functionality as the _set_offline routine does.
Signed-off-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NChristof 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: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NMike 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: NVasu Dev <vasu.dev@intel.com>
[jejb: fixed up 53c700]
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Add HZ since the start_timer function expects jiffies, not seconds.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NFelix Beck <felix.beck@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

=======================================================
[ 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: NFelix Beck <felix.beck@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NFelix Beck <felix.beck@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NFelix Beck <felix.beck@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NFelix Beck <felix.beck@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Don't use kfree directly after device registration started.
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The config semaphore is only used as a mutex, so replace it with a
simple mutex.
Reviewed-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

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: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Update the Fibre Channel related code to use the zfcp_fc prefix.
Signed-off-by: NSwen Schillig <swen@vnet.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>