Re: [dm-devel] [PATCH] scsi : Adding all the definitions of host bytes in hostbyte_table
On 07/27/2012 07:28 PM, Moger, Babu wrote: Submitted this patch earlier. But it still did not make it to kernel tree. Resubmitting again(recreated on top of 3.5 kernel). Adding all the definitions of host bytes in hostbyte_table. Without this patch, scsi_show_result prints hostbyte as invalid for statuses that are not defined in hostbyte_table(when scsi logging is enabled). Look at scsi_print_result function for better understanding. Signed-off-by: Babu Moger babu.mo...@netapp.com Acked-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. But if there are some HighMem pages in table-sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) may return NULL value. This will cause QEMU exit when virtqueue_map_sg is called in QEMU because an invalid GPA is passed by virtqueue. Two solutions are discussed here: http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/00675.html Finally, value assignment approach was adopted because: Value assignment creates a well-formed scatterlist, because the termination marker in source sg_list has been set in blk_rq_map_sg(). The last entry of the source sg_list is just copied to the the last entry in destination list. Note that, for now, virtio_ring does not care about the form of the scatterlist and simply processes the first out_num + in_num consecutive elements of the sg[] array. I have tested the patch on my workstation. QEMU would not crash any more. Cc: sta...@vger.kernel.org # 3.4: 4fe74b1: [SCSI] virtio-scsi: SCSI driver Signed-off-by: Wang Sen senw...@linux.vnet.ibm.com --- drivers/scsi/virtio_scsi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 1b38431..6661610 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -198,7 +198,7 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx, int i; for_each_sg(table-sgl, sg_elem, table-nents, i) - sg_set_buf(sg[idx++], sg_virt(sg_elem), sg_elem-length); + sg[idx++] = *sg_elem; *p_idx = idx; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: virtio(-scsi) vs. chained sg_lists (was Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list)
Il 30/07/2012 01:50, Rusty Russell ha scritto: Also, being the first user of chained scatterlist doesn't exactly give me warm fuzzies. We're far from the first user: they've been in the kernel for well over 7 years. They were introduced for the block layer, but they tended to ignore private uses of scatterlists like this one. Yeah, but sg_chain has no users in drivers, only a private one in lib/scatterlist.c. The internal API could be changed to something else and leave virtio-scsi screwed... Yes, we should do this. But note that this means an iteration, so we might as well combine the loops :) I'm really bad at posting pseudo-code, but you can count the number of physically-contiguous entries at the beginning of the list only. So if everything is contiguous, you use a single non-indirect buffer and save a kmalloc. If you use indirect buffers, I suspect it's much less effective to collapse physically-contiguous entries. More elaborate heuristics do need a loop, though. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 30/07/2012 08:25, Wang Sen ha scritto: When using the commands below to write some data to a virtio-scsi LUN of the QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash. # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.) # sudo mount /dev/sdb /mnt # dd if=/dev/zero of=/mnt/file bs=1M count=1024 In current implementation, sg_set_buf is called to add buffers to sg list which is put into the virtqueue eventually. But if there are some HighMem pages in table-sgl you can not get virtual address by sg_virt. So, sg_virt(sg_elem) may return NULL value. This will cause QEMU exit when virtqueue_map_sg is called in QEMU because an invalid GPA is passed by virtqueue. Two solutions are discussed here: http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/00675.html Finally, value assignment approach was adopted because: Value assignment creates a well-formed scatterlist, because the termination marker in source sg_list has been set in blk_rq_map_sg(). The last entry of the source sg_list is just copied to the the last entry in destination list. Note that, for now, virtio_ring does not care about the form of the scatterlist and simply processes the first out_num + in_num consecutive elements of the sg[] array. I have tested the patch on my workstation. QEMU would not crash any more. Cc: sta...@vger.kernel.org # 3.4: 4fe74b1: [SCSI] virtio-scsi: SCSI driver Signed-off-by: Wang Sen senw...@linux.vnet.ibm.com Acked-by: Paolo Bonzini pbonz...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2] [SCSI] ipr: missing unlock before a return
We recently changed the locking in this function, but this return was
missed. It needs an unlock and the IRQs need to be restored.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Applies to linux-next.
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 07b14ba..7a5ccb2c 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -5874,8 +5874,11 @@ static int ipr_queuecommand(struct Scsi_Host *shost,
goto err_nodev;
}
- if (ipr_is_gata(res) res-sata_port)
- return ata_sas_queuecmd(scsi_cmd, res-sata_port-ap);
+ if (ipr_is_gata(res) res-sata_port) {
+ rc = ata_sas_queuecmd(scsi_cmd, res-sata_port-ap);
+ spin_unlock_irqrestore(shost-host_lock, lock_flags);
+ return rc;
+ }
ipr_cmd = __ipr_get_free_ipr_cmnd(ioa_cfg);
spin_unlock_irqrestore(shost-host_lock, lock_flags);
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2] [SCSI] ipr: remove an unneeded check
rc is always zero here, so there is no need to check.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index 7a5ccb2c..fc49f17 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -5847,7 +5847,7 @@ static int ipr_queuecommand(struct Scsi_Host *shost,
struct ipr_ioarcb *ioarcb;
struct ipr_cmnd *ipr_cmd;
unsigned long lock_flags;
- int rc = 0;
+ int rc;
ioa_cfg = (struct ipr_ioa_cfg *)shost-hostdata;
@@ -5905,12 +5905,10 @@ static int ipr_queuecommand(struct Scsi_Host *shost,
(!ipr_is_gscsi(res) || scsi_cmd-cmnd[0] == IPR_QUERY_RSRC_STATE))
ioarcb-cmd_pkt.request_type = IPR_RQTYPE_IOACMD;
- if (likely(rc == 0)) {
- if (ioa_cfg-sis64)
- rc = ipr_build_ioadl64(ioa_cfg, ipr_cmd);
- else
- rc = ipr_build_ioadl(ioa_cfg, ipr_cmd);
- }
+ if (ioa_cfg-sis64)
+ rc = ipr_build_ioadl64(ioa_cfg, ipr_cmd);
+ else
+ rc = ipr_build_ioadl(ioa_cfg, ipr_cmd);
spin_lock_irqsave(shost-host_lock, lock_flags);
if (unlikely(rc || (!ioa_cfg-allow_cmds !ioa_cfg-ioa_is_dead))) {
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: virtio(-scsi) vs. chained sg_lists (was Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list)
On 07/30/2012 10:12 AM, Paolo Bonzini wrote: Il 30/07/2012 01:50, Rusty Russell ha scritto: Also, being the first user of chained scatterlist doesn't exactly give me warm fuzzies. We're far from the first user: they've been in the kernel for well over 7 years. They were introduced for the block layer, but they tended to ignore private uses of scatterlists like this one. Yeah, but sg_chain has no users in drivers, only a private one in lib/scatterlist.c. The internal API could be changed to something else and leave virtio-scsi screwed... Yes, we should do this. But note that this means an iteration, so we might as well combine the loops :) I'm really bad at posting pseudo-code, but you can count the number of physically-contiguous entries at the beginning of the list only. So if everything is contiguous, you use a single non-indirect buffer and save a kmalloc. If you use indirect buffers, I suspect it's much less effective to collapse physically-contiguous entries. More elaborate heuristics do need a loop, though. [All the below with a grain of salt, from my senile memory] You must not forget some facts about the scatterlist received here at the LLD. It has already been DMA mapped and locked by the generic layer. Which means that the DMA engine has already collapsed physically-contiguous entries. Those you get here are already unique physically. (There were bugs in the past, where this was not true, please complain if you find them again) A scatterlist is two different lists taking the same space, but with two different length. - One list is the PAGE pointers plus offset length, which is bigger or equal to the 2nd list. The end marker corresponds to this list. This list is the input into the DMA engine. - Second list is the physical DMA addresses list. With their physical-lengths. Offset is not needed because it is incorporated in the DMA address. This list is the output from the DMA engine. The reason 2nd list is shorter is because the DMA engine tries to minimize the physical scatter-list entries which is usually a limited HW resource. This list might follow chains but it's end is determined by the received sg_count from the DMA engine, not by the end marker. At the time my opinion, and I think Rusty agreed, was that the scatterlist should be split in two. The input page-ptr list is just the BIO, and the output of the DMA-engine should just be the physical part of the sg_list, as a separate parameter. But all this was berried under too much APIs and the noise was two strong, for any single brave sole. So I'd just trust blindly the returned sg_count from the DMA engine, it is already optimized. I THINK Paolo Boaz -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/2] [SCSI] ipr: remove an unneeded check
On 07/30/2012 03:18 AM, Dan Carpenter wrote: rc is always zero here, so there is no need to check. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Thanks! Acked-by: Brian King brk...@linux.vnet.ibm.com -- Brian King Power Linux I/O IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/2] [SCSI] ipr: missing unlock before a return
On 07/30/2012 03:16 AM, Dan Carpenter wrote: We recently changed the locking in this function, but this return was missed. It needs an unlock and the IRQs need to be restored. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com --- Thanks for catching this. Acked-by: Brian King brk...@linux.vnet.ibm.com -- Brian King Power Linux I/O IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Mon, Jul 30, Benjamin Herrenschmidt wrote: On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: From: Olaf Hering o...@aepfle.de The driver is named ibmvscsic, at runtime it its name is advertised as ibmvscsi. For this reason mkinitrd wont pickup the driver properly. Reported by IBM during SLES11 beta testing: https://bugzilla.novell.com/show_bug.cgi?id=459933 LTC50724 So while this would work, I do wonder however whether we could instead fix it by simplifying the whole thing as follow since iSeries is now gone and so we don't need split backends anymore: scsi/ibmvscsi: Remove backend abstraction I cant that these things myself anymore. Olaf -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise
Hello! Do you remember? I get it again, is there something I could do? I attached a file that contains the udevadm monitor log. I am using a v3.5.0 linux kernel (containing some gentoo patches). Should I test it with a vanilla one? Here the versions of some packages (kernel, udev, systemd): sys-kernel/gentoo-sources-3.5.0 sys-fs/udev-186 sys-apps/systemd-44-r1 Here (again) the information about the two sticks I run in trouble after plug them in: # udevadm info --path=/block/sdb P: /devices/pci:00/:00:04.1/usb5/5-4/5-4:1.0/host22/target22:0:0/22:0:0:0/block/sdb N: sdb S: disk/by-id/usb-SanDisk_Cruzer_07745302FB131CFA-0:0 S: disk/by-path/pci-:00:04.1-usb-0:4:1.0-scsi-0:0:0:0 E: DEVLINKS=/dev/disk/by-id/usb-SanDisk_Cruzer_07745302FB131CFA-0:0 /dev/disk/by-path/pci-:00:04.1-usb-0:4:1.0-scsi-0:0:0:0 E: DEVNAME=/dev/sdb E: DEVPATH=/devices/pci:00/:00:04.1/usb5/5-4/5-4:1.0/host22/target22:0:0/22:0:0:0/block/sdb E: DEVTYPE=disk E: ID_BUS=usb E: ID_DRIVE_THUMB=1 E: ID_INSTANCE=0:0 E: ID_MODEL=Cruzer E: ID_MODEL_ENC=Cruzer\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_MODEL_ID=5406 E: ID_PART_TABLE_TYPE=dos E: ID_PATH=pci-:00:04.1-usb-0:4:1.0-scsi-0:0:0:0 E: ID_PATH_TAG=pci-_00_04_1-usb-0_4_1_0-scsi-0_0_0_0 E: ID_REVISION=8.02 E: ID_SERIAL=SanDisk_Cruzer_07745302FB131CFA-0:0 E: ID_SERIAL_SHORT=07745302FB131CFA E: ID_TYPE=disk E: ID_USB_DRIVER=usb-storage E: ID_USB_INTERFACES=:080650: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=SanDisk E: ID_VENDOR_ENC=SanDisk\x20 E: ID_VENDOR_ID=0781 E: LVM_SBIN_PATH=/sbin E: MAJOR=8 E: MINOR=16 E: SUBSYSTEM=block E: TAGS=:systemd: E: UDISKS_PARTITION_TABLE=1 E: UDISKS_PARTITION_TABLE_COUNT=1 E: UDISKS_PARTITION_TABLE_SCHEME=mbr E: UDISKS_PRESENTATION_NOPOLICY=0 E: USEC_INITIALIZED=79287950141 # udevadm info --path=/block/sdb P: /devices/pci:00/:00:04.1/usb5/5-4/5-4:1.0/host23/target23:0:0/23:0:0:0/block/sdb N: sdb S: disk/by-id/usb-SanDisk_Cruzer_22427202FB10CD97-0:0 S: disk/by-path/pci-:00:04.1-usb-0:4:1.0-scsi-0:0:0:0 E: DEVLINKS=/dev/disk/by-id/usb-SanDisk_Cruzer_22427202FB10CD97-0:0 /dev/disk/by-path/pci-:00:04.1-usb-0:4:1.0-scsi-0:0:0:0 E: DEVNAME=/dev/sdb E: DEVPATH=/devices/pci:00/:00:04.1/usb5/5-4/5-4:1.0/host23/target23:0:0/23:0:0:0/block/sdb E: DEVTYPE=disk E: ID_BUS=usb E: ID_DRIVE_THUMB=1 E: ID_INSTANCE=0:0 E: ID_MODEL=Cruzer E: ID_MODEL_ENC=Cruzer\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_MODEL_ID=5406 E: ID_PART_TABLE_TYPE=dos E: ID_PATH=pci-:00:04.1-usb-0:4:1.0-scsi-0:0:0:0 E: ID_PATH_TAG=pci-_00_04_1-usb-0_4_1_0-scsi-0_0_0_0 E: ID_REVISION=8.02 E: ID_SERIAL=SanDisk_Cruzer_22427202FB10CD97-0:0 E: ID_SERIAL_SHORT=22427202FB10CD97 E: ID_TYPE=disk E: ID_USB_DRIVER=usb-storage E: ID_USB_INTERFACES=:080650: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=SanDisk E: ID_VENDOR_ENC=SanDisk\x20 E: ID_VENDOR_ID=0781 E: LVM_SBIN_PATH=/sbin E: MAJOR=8 E: MINOR=16 E: SUBSYSTEM=block E: TAGS=:systemd: E: UDISKS_PARTITION_TABLE=1 E: UDISKS_PARTITION_TABLE_COUNT=1 E: UDISKS_PARTITION_TABLE_SCHEME=mbr E: UDISKS_PRESENTATION_NOPOLICY=0 E: USEC_INITIALIZED=342063581 insert-stick.log.gz Description: GNU Zip compressed data
Re: [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise
On Mon, Jul 30, 2012 at 9:06 PM, Markus Rathgeb maggu2...@googlemail.com wrote: Hello! Do you remember? I get it again, is there something I could do? I attached a file that contains the udevadm monitor log. I am using a v3.5.0 linux kernel (containing some gentoo patches). Should I test it with a vanilla one? I have 3.5 here and see the loop too, but it stops after a couple of seconds: first: KERNEL[15636.368034] last: KERNEL[15638.879796] The kernel log says: [15634.066481] sr 13:0:0:1: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events Kay -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise
I have 3.5 here and see the loop too, but it stops after a couple of seconds:
first: KERNEL[15636.368034]
last: KERNEL[15638.879796]
Ah, sorry then.
The udev messages reported by the udev monitor reported up to 20
seconds of udev (userspace) events. I did not filter kernel reported
messages.
# for SRC in KERNEL UDEV; do for CMD in head tail; do less udev.log |
grep ${SRC} | ${CMD} -n1; done; done
KERNEL[83579.700428] add /devices/pci:00/:00:04.1/usb5/5-4 (usb)
KERNEL[83582.989470] change
/devices/pci:00/:00:04.1/usb5/5-4/5-4:1.0/host31/target31:0:0/31:0:0:1/block/sr1
(block)
UDEV [83579.747646] add /devices/pci:00/:00:04.1/usb5/5-4 (usb)
UDEV [83601.504952] add
/devices/pci:00/:00:04.1/usb5/5-4/5-4:1.0/host31/target31:0:0/31:0:0:0/block/sdb/sdb1
(block)
I should also disable the dbus logging verbosity:
journald reported 494 complete dbus messages and 846 (475 + 371)
suppressed dbus messages.
That is really too much (but not your problem).
Thanks!!
journald.log.gz
Description: GNU Zip compressed data
udev.log.gz
Description: GNU Zip compressed data
[GIT PULL] tcm_vhost: Initial merge of vhost level target fabric driver
Hi Linus, Here is the PULL request for the initial merge of tcm_vhost based on RFC-v5 code with MST's ACK appended to the initial merge commit. As promised, the commit is available from two different branches for you to consider merging as for-3.6 code. The 'for-next-merge' branch based on mainline commit 7409a6657ae using 3.5-rc2 code contains two duplicates of pre-merge vhost patch dependencies that have already been merged into mainline via net-next. This commit is also in the 07302012 -next patchset, and available here: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next-merge Or the 'for-linus' branch containing an -rc0 head @ commit bdc0077af57: Merge tag 'scsi-misc' of git://git.kernel.org/../jejb/scsi) rebased up to the last commit in scsi-misc required for virtio-scsi client LLD scanning logic to function properly with tcm_vhost fabric ports, is available here: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-linus Both branches have gotten recent testing and have been running over-night small block random I/O tests connected to raw block flash backends. The same diffstat below will result from pulling either branch. Also, the incremental patch to address MST's last round of post-merge comments has been sent to the lists for feedback this afternoon. This will be included into the usual post -rc1 PULL via 3.6-rc-fixes, along with any other bits that end up changing post-merge. Please let us know if you have any concerns. Thank you! --nab Nicholas Bellinger (1): tcm_vhost: Initial merge for vhost level target fabric driver drivers/vhost/Kconfig |3 + drivers/vhost/Kconfig.tcm |6 + drivers/vhost/Makefile|2 + drivers/vhost/tcm_vhost.c | 1628 + drivers/vhost/tcm_vhost.h | 101 +++ 5 files changed, 1740 insertions(+), 0 deletions(-) create mode 100644 drivers/vhost/Kconfig.tcm create mode 100644 drivers/vhost/tcm_vhost.c create mode 100644 drivers/vhost/tcm_vhost.h -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/7] ZPODD patches
Hi James, Any chance of these patches get merged into 3.6? Thanks, Aaron On 07/27/2012 05:00 PM, Aaron Lu wrote: v4: Rebase on top of Linus' tree, due to this, the problem of a missing flag in v3 is gone; Add a new function scsi_autopm_put_device_autosuspend to first mark last busy for the device and then put autosuspend it as suggested by Oliver Neukum. Typo fix as pointed by Sergei Shtylyov. Check can_power_off flag before any runtime pm operations in sr. v3: Rebase on top of scsi-misc tree; Add the sr related patches previously in Jeff's libata tree; Re-organize the sr patches. A problem for now: for patch scsi: sr: support zero power ODD(ZPODD) I can't set a flag in libata-acpi.c since a related function is missing in scsi-misc tree. Will fix this when 3.6-rc1 released. v2: Bug fix for v1; Use scsi_autopm_* in sr driver instead of pm_runtime_*; v1: Here are some patches to make ZPODD easier to use for end users and a fix for using ZPODD with system suspend. Aaron Lu (7): scsi: sr: check support for device busy class events scsi: pm: add interface to autosuspend scsi device scsi: sr: support zero power ODD(ZPODD) scsi: sr: block events when runtime suspended scsi: pm: use runtime resume callback if available scsi: sr: balance sr disk events block depth block: genhd: add an interface to set disk's poll interval block/genhd.c | 25 +-- drivers/ata/libata-acpi.c | 4 +- drivers/scsi/scsi_pm.c | 22 -- drivers/scsi/sr.c | 179 - drivers/scsi/sr.h | 3 + include/linux/cdrom.h | 43 +++ include/linux/genhd.h | 1 + include/scsi/scsi_device.h | 3 + 8 files changed, 267 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic
On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote: So while this would work, I do wonder however whether we could instead fix it by simplifying the whole thing as follow since iSeries is now gone and so we don't need split backends anymore: scsi/ibmvscsi: Remove backend abstraction I cant that these things myself anymore. Brian, can somebody from your side own these ? Cheers, Ben. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
