Searched hist:"3 ac709c113daa19e375e8b0fef318fab1713f687" (Results 1 – 5 of 5) sorted by relevance
| /linux/drivers/scsi/ |
| H A D | bvme6000_scsi.c | diff 3ac709c113daa19e375e8b0fef318fab1713f687 Tue Jul 17 21:38:03 CEST 2007 Matthew Wilcox <matthew@wil.cx> [SCSI] a4000t, zorro7xx, mvme16x, bvme6000,sim710: xxx_device_remove seems buggy
Fix drivers misusing dev_to_shost
Some drivers were using dev_to_shost to go from a struct device to the
corresponding shost. Unfortunately, dev_to_shost only looks up the tree
to find an shost (it's designed to go from a scsi_device or a
scsi_target to the parent scsi_host), and these drivers were calling it
with the parent of the scsi_host.
I've fixed this by saving a pointer to the Scsi_Host in the drvdata,
which matches what most scsi drivers do.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
| H A D | mvme16x_scsi.c | diff 3ac709c113daa19e375e8b0fef318fab1713f687 Tue Jul 17 21:38:03 CEST 2007 Matthew Wilcox <matthew@wil.cx> [SCSI] a4000t, zorro7xx, mvme16x, bvme6000,sim710: xxx_device_remove seems buggy
Fix drivers misusing dev_to_shost
Some drivers were using dev_to_shost to go from a struct device to the
corresponding shost. Unfortunately, dev_to_shost only looks up the tree
to find an shost (it's designed to go from a scsi_device or a
scsi_target to the parent scsi_host), and these drivers were calling it
with the parent of the scsi_host.
I've fixed this by saving a pointer to the Scsi_Host in the drvdata,
which matches what most scsi drivers do.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
| H A D | zorro7xx.c | diff 3ac709c113daa19e375e8b0fef318fab1713f687 Tue Jul 17 21:38:03 CEST 2007 Matthew Wilcox <matthew@wil.cx> [SCSI] a4000t, zorro7xx, mvme16x, bvme6000,sim710: xxx_device_remove seems buggy
Fix drivers misusing dev_to_shost
Some drivers were using dev_to_shost to go from a struct device to the
corresponding shost. Unfortunately, dev_to_shost only looks up the tree
to find an shost (it's designed to go from a scsi_device or a
scsi_target to the parent scsi_host), and these drivers were calling it
with the parent of the scsi_host.
I've fixed this by saving a pointer to the Scsi_Host in the drvdata,
which matches what most scsi drivers do.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
| H A D | a4000t.c | diff 3ac709c113daa19e375e8b0fef318fab1713f687 Tue Jul 17 21:38:03 CEST 2007 Matthew Wilcox <matthew@wil.cx> [SCSI] a4000t, zorro7xx, mvme16x, bvme6000,sim710: xxx_device_remove seems buggy
Fix drivers misusing dev_to_shost
Some drivers were using dev_to_shost to go from a struct device to the
corresponding shost. Unfortunately, dev_to_shost only looks up the tree
to find an shost (it's designed to go from a scsi_device or a
scsi_target to the parent scsi_host), and these drivers were calling it
with the parent of the scsi_host.
I've fixed this by saving a pointer to the Scsi_Host in the drvdata,
which matches what most scsi drivers do.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
| H A D | sim710.c | diff 3ac709c113daa19e375e8b0fef318fab1713f687 Tue Jul 17 21:38:03 CEST 2007 Matthew Wilcox <matthew@wil.cx> [SCSI] a4000t, zorro7xx, mvme16x, bvme6000,sim710: xxx_device_remove seems buggy
Fix drivers misusing dev_to_shost
Some drivers were using dev_to_shost to go from a struct device to the
corresponding shost. Unfortunately, dev_to_shost only looks up the tree
to find an shost (it's designed to go from a scsi_device or a
scsi_target to the parent scsi_host), and these drivers were calling it
with the parent of the scsi_host.
I've fixed this by saving a pointer to the Scsi_Host in the drvdata,
which matches what most scsi drivers do.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|