[SCSI] remove target parent limitiation
When James Smart fixed the issue of the userspace scan atributes crashing the system with the FC transport class he added a patch to let the transport class check if the parent is valid for a given transport class. When adding support for the integrated raid of fusion sas devices we ran into a problem with that, as it didn't allow adding virtual raid volumes without the transport class knowing about it. So this patch adds a user_scan attribute instead, that takes over from scsi_scan_host_selected if the transport class sets it and thus lets the transport class control the user-initiated scanning. As this plugs the hole about user-initiated scanning the target_parent hook goes away and we rely on callers of the scanning routines to do something sensible. For SAS this meant I had to switch from a spinlock to a mutex to synchronize the topology linked lists, in FC they were completely unsynchronized which seems wrong. Signed-off-by:Christoph Hellwig <hch@lst.de> Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com>
Showing
- drivers/scsi/scsi_priv.h 0 additions, 6 deletionsdrivers/scsi/scsi_priv.h
- drivers/scsi/scsi_proc.c 5 additions, 1 deletiondrivers/scsi/scsi_proc.c
- drivers/scsi/scsi_scan.c 2 additions, 14 deletionsdrivers/scsi/scsi_scan.c
- drivers/scsi/scsi_sysfs.c 4 additions, 1 deletiondrivers/scsi/scsi_sysfs.c
- drivers/scsi/scsi_transport_fc.c 14 additions, 8 deletionsdrivers/scsi/scsi_transport_fc.c
- drivers/scsi/scsi_transport_sas.c 24 additions, 18 deletionsdrivers/scsi/scsi_transport_sas.c
- include/scsi/scsi.h 6 additions, 0 deletionsinclude/scsi/scsi.h
- include/scsi/scsi_transport.h 2 additions, 5 deletionsinclude/scsi/scsi_transport.h
Loading
Please register or sign in to comment