summaryrefslogtreecommitdiff
path: root/drivers/mmc
diff options
context:
space:
mode:
authorBenjamin Block <bblock@linux.ibm.com>2020-05-08 20:23:30 +0300
committerMartin K. Petersen <martin.petersen@oracle.com>2020-05-12 06:19:48 +0300
commit52e61fde5ec95cb4011784fb0bc6b436e16fcaa8 (patch)
treeb6c33d6735df1feb850e0450cc16c05aeb244d77 /drivers/mmc
parentbd1684817d7d8d1a3b95a4347166246ad1f7670b (diff)
downloadlinux-52e61fde5ec95cb4011784fb0bc6b436e16fcaa8.tar.xz
scsi: zfcp: Move fc_host updates during xport data handling into fenced function
When executing exchange port data for a FCP device for the first time, or after an adapter recovery, we update several properties of the fibre channel host object which represents that FCP device. When moving the scsi host object allocation and registration - and thus also the fibre channel host object allocation - to after the first exchange config and exchange port data, this is not possible for the former case. Move all these update into separate, and fenced function that first checks whether the scsi host object already exists or not, before making the updates. During the first ever exchange port data in the adapter life cycle this will make the exchange port data handler skip over this update step, but we can repeat it later, after we allocated the scsi host object. For any further recovery of that adapter the work flow is only changed slightly because then the scsi host object already exists and we don't free it until we release the adapter completely at the end of its life cycle. Link: https://lore.kernel.org/r/ae454c2dc6da0b02907c489af91d0b211d331825.1588956679.git.bblock@linux.ibm.com Reviewed-by: Steffen Maier <maier@linux.ibm.com> Signed-off-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'drivers/mmc')
0 files changed, 0 insertions, 0 deletions