Re: [PATCH] scsi/ibmvscsi: /sys/class/scsi_host/hostX/config doesn't show any information
On Fri, 2012-07-27 at 15:19 +1000, Benjamin Herrenschmidt wrote: > On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: > > From: Linda Xie > > James, can I assume you're picking up those two ? If they get acked by the maintiners ... James -- 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: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
Il 27/07/2012 05:12, Wang Sen ha scritto: >> > No this code is correct, though you will need to make sure to properly >> > terminate the destination sg_list. > Yes, the terminate marker in the destination list is set when initialization. > sg_set_page would not break this marker because it saved both the two > maker bits at sg_asign_page. > > Also, the allocation of destination sg list considered the total number of > the source sg_list. So, sg_set_page can work correctly. > > The value assignment method also can also work correctly, because the > termination marker in source sg_list has been set in blk_rq_map_sg(), as > the last entry of source sg_list is just copied to the the last entry > in destination > list. > > Uh, Paolo, Boaz, have you reached agreement on which method to use? Let's use the value assignment, and document it in the commit message as follows: 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. 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] scsi/ibmvscsi: /sys/class/scsi_host/hostX/config doesn't show any information
On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote: > From: Linda Xie James, can I assume you're picking up those two ? Cheers, Ben. > Expected result: > It should show something like this: > x1521p4:~ # cat /sys/class/scsi_host/host1/config > PARTITIONNAME='x1521p4' > NWSDNAME='X1521P4' > HOSTNAME='X1521P4' > DOMAINNAME='RCHLAND.IBM.COM' > NAMESERVERS='9.10.244.100 9.10.244.200' > > Actual result: > x1521p4:~ # cat /sys/class/scsi_host/host0/config > x1521p4:~ # > > This patch changes the size of the buffer used for transfering config > data to 4K. It was tested against 2.6.19-rc2 tree. > > Reported by IBM during SLES11 beta testing: > > https://bugzilla.novell.com/show_bug.cgi?id=439970 > LTC49349 > > Signed-off-by: Olaf Hering > > diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c > b/drivers/scsi/ibmvscsi/ibmvscsi.c > index e580aa4..1513ca8 100644 > --- a/drivers/scsi/ibmvscsi/ibmvscsi.c > +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c > @@ -93,6 +93,8 @@ static int max_requests = IBMVSCSI_MAX_REQUESTS_DEFAULT; > static int max_events = IBMVSCSI_MAX_REQUESTS_DEFAULT + 2; > static int fast_fail = 1; > static int client_reserve = 1; > +/* host data buffer size */ > +#define HOST_BUFFER_SIZE 4096 > > static struct scsi_transport_template *ibmvscsi_transport_template; > > @@ -1666,7 +1668,7 @@ static ssize_t show_host_srp_version(struct device *dev, > struct ibmvscsi_host_data *hostdata = shost_priv(shost); > int len; > > - len = snprintf(buf, PAGE_SIZE, "%s\n", > + len = snprintf(buf, HOST_BUFFER_SIZE, "%s\n", > hostdata->madapter_info.srp_version); > return len; > } > @@ -1687,7 +1689,7 @@ static ssize_t show_host_partition_name(struct device > *dev, > struct ibmvscsi_host_data *hostdata = shost_priv(shost); > int len; > > - len = snprintf(buf, PAGE_SIZE, "%s\n", > + len = snprintf(buf, HOST_BUFFER_SIZE, "%s\n", > hostdata->madapter_info.partition_name); > return len; > } > @@ -1708,7 +1710,7 @@ static ssize_t show_host_partition_number(struct device > *dev, > struct ibmvscsi_host_data *hostdata = shost_priv(shost); > int len; > > - len = snprintf(buf, PAGE_SIZE, "%d\n", > + len = snprintf(buf, HOST_BUFFER_SIZE, "%d\n", > hostdata->madapter_info.partition_number); > return len; > } > @@ -1728,7 +1730,7 @@ static ssize_t show_host_mad_version(struct device *dev, > struct ibmvscsi_host_data *hostdata = shost_priv(shost); > int len; > > - len = snprintf(buf, PAGE_SIZE, "%d\n", > + len = snprintf(buf, HOST_BUFFER_SIZE, "%d\n", > hostdata->madapter_info.mad_version); > return len; > } > @@ -1748,7 +1750,7 @@ static ssize_t show_host_os_type(struct device *dev, > struct ibmvscsi_host_data *hostdata = shost_priv(shost); > int len; > > - len = snprintf(buf, PAGE_SIZE, "%d\n", hostdata->madapter_info.os_type); > + len = snprintf(buf, HOST_BUFFER_SIZE, "%d\n", > hostdata->madapter_info.os_type); > return len; > } > > @@ -1767,7 +1769,7 @@ static ssize_t show_host_config(struct device *dev, > struct ibmvscsi_host_data *hostdata = shost_priv(shost); > > /* returns null-terminated host config data */ > - if (ibmvscsi_do_host_config(hostdata, buf, PAGE_SIZE) == 0) > + if (ibmvscsi_do_host_config(hostdata, buf, HOST_BUFFER_SIZE) == 0) > return strlen(buf); > else > return 0; -- 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: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
2012/7/25 Boaz Harrosh : > On 07/25/2012 02:44 PM, Sen Wang wrote: > >> 2012/7/25 Paolo Bonzini : >>> Il 25/07/2012 10:29, 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 there are some HighMem pages in table->sgl 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. >>> >>> Heh, I was compiling (almost) the same patch as we speak. :) >> >> Uh, what a coincidence! :) >> >>> >>> I've never seen QEMU crash; the VM would more likely just fail to boot >>> with a panic. But it's the same bug anyway. >> >> I never met this before. How this situation happens? >> >>> My solution is using sg_set_page instead of sg_set_buf. I have tested the patch on my workstation. QEMU would not crash any more. Signed-off-by: Wang Sen --- drivers/scsi/virtio_scsi.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index 1b38431..fc5c88a 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -198,7 +198,8 @@ 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_set_page(&sg[idx++], sg_page(sg_elem), sg_elem->length, + sg_elem->offset); >>> >>> This can simply be >>> >>>sg[idx++] = *sg_elem; >>> >> >> Yes, I saw your another E-mail. I think you're right. Simply calling >> sg_set_page can not handle >> the flag bits correctly. So, I'll repost the patch soon. Thank you! >> > > > No this code is correct, though you will need to make sure to properly > terminate the destination sg_list. Yes, the terminate marker in the destination list is set when initialization. sg_set_page would not break this marker because it saved both the two maker bits at sg_asign_page. Also, the allocation of destination sg list considered the total number of the source sg_list. So, sg_set_page can work correctly. The value assignment method also can also work correctly, because the termination marker in source sg_list has been set in blk_rq_map_sg(), as the last entry of source sg_list is just copied to the the last entry in destination list. Uh, Paolo, Boaz, have you reached agreement on which method to use? > > But since old code was using sg_set_buf(), than it means it was properly > terminated before, and there for this code is good as is please don't > touch it. > > Thanks > Boaz > >>> Can you repost it with this change, and also add sta...@vger.kernel.org >>> to the Cc? Thanks very much! >>> >>> 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 >> >> >> > -- -- Wang Sen Addr: XUPT,Xi'an,Shaanxi,China Email: kelvin.x...@gmail.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
[RFC-v5] tcm_vhost: Initial merge for vhost level target fabric driver
From: Nicholas Bellinger Hello KVM + QEMU folks, This is -v5 of the in-flight tcm_vhost fabric driver for KVM host virtualized target support using the in-kernel storage stack with for-3.6 code. The changes since -v4 have been pretty minimal. A new GET_ABI_VERSION ioctl has been added as requested by Anthony & Co, and after some back <-> forth on the lists we've decided upon a starting point of VHOST_SCSI_ABI_VERSION=0, and vhost-scsi RFC userspace has been updated accordingly. Along with that, a few handfuls of vq related error messages where converted to use vq_err as requested by MST, along with some minor checkpatch fixes. So this point everything required to run tcm_vhost from drivers/target + drivers/vhost, and virtio-scsi LLD bugfix has been merged into v3.6-rc0 code. Please have a look and let us know if there are any last-minute pre-merge comments ahead of MST returning from holiday this weekend. Thank you! --nab Changelog v4 -> v5: Expose ABI version via VHOST_SCSI_GET_ABI_VERSION + use Rev 0 as starting point for v3.6-rc code (Stefan + ALiguori + nab) Convert vhost_scsi_handle_vq() to vq_err() (nab + MST) Minor style fixes from checkpatch (nab) Changelog v3 -> v4: Rename vhost_vring_target -> vhost_scsi_target (mst + nab) Use TRANSPORT_IQN_LEN in vhost_scsi_target->vhost_wwpn[] def (nab) Move back to drivers/vhost/, and just use drivers/vhost/Kconfig.tcm (mst) Move TCM_VHOST related ioctl defines from include/linux/vhost.h -> drivers/vhost/tcm_vhost.h as requested by MST (nab) Move Kbuild.tcm include from drivers/staging -> drivers/vhost/, and just use 'if STAGING' around 'source drivers/vhost/Kbuild.tcm' Changelog v2 -> v3: Unlock on error in tcm_vhost_drop_nexus() (DanC) Fix strlen() doesn't count the terminator (DanC) Call kfree() on an error path (DanC) Convert tcm_vhost_write_pending to use target_execute_cmd (hch + nab) Fix another strlen() off by one in tcm_vhost_make_tport (DanC) Add option under drivers/staging/Kconfig, and move to drivers/vhost/tcm/ as requested by MST (nab) Changelog v1 -> v2: Fix tv_cmd completion -> release SGL memory leak (nab) Fix sparse warnings for static variable usage ((Fengguang Wu) Fix sparse warnings for min() typing + printk format specs (Fengguang Wu) Convert to cmwq submission for I/O dispatch (nab + hch) Changelog v0 -> v1: Merge into single source + header file, and move to drivers/vhost/ Cc: Michael S. Tsirkin Cc: Stefan Hajnoczi Cc: Anthony Liguori Cc: Zhi Yong Wu Cc: Paolo Bonzini Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Jens Axboe Signed-off-by: Nicholas Bellinger --- 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 diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig index e4e2fd1..202bba6 100644 --- a/drivers/vhost/Kconfig +++ b/drivers/vhost/Kconfig @@ -9,3 +9,6 @@ config VHOST_NET To compile this driver as a module, choose M here: the module will be called vhost_net. +if STAGING +source "drivers/vhost/Kconfig.tcm" +endif diff --git a/drivers/vhost/Kconfig.tcm b/drivers/vhost/Kconfig.tcm new file mode 100644 index 000..a9c6f76 --- /dev/null +++ b/drivers/vhost/Kconfig.tcm @@ -0,0 +1,6 @@ +config TCM_VHOST + tristate "TCM_VHOST fabric module (EXPERIMENTAL)" + depends on TARGET_CORE && EVENTFD && EXPERIMENTAL && m + default n + ---help--- + Say M here to enable the TCM_VHOST fabric module for use with virtio-scsi guests diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile index 72dd020..a27b053 100644 --- a/drivers/vhost/Makefile +++ b/drivers/vhost/Makefile @@ -1,2 +1,4 @@ obj-$(CONFIG_VHOST_NET) += vhost_net.o vhost_net-y := vhost.o net.o + +obj-$(CONFIG_TCM_VHOST) += tcm_vhost.o diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c new file mode 100644 index 000..fb36654 --- /dev/null +++ b/drivers/vhost/tcm_vhost.c @@ -0,0 +1,1628 @@ +/*** + * Vhost kernel TCM fabric driver for virtio SCSI initiators + * + * (C) Copyright 2010-2012 RisingTide Systems LLC. + * (C) Copyright 2010-2012 IBM Corp. + * + * Licensed to the Linux Foundation under the General Public License (GPL) version 2. + * + * Authors: Nicholas A. Bellinger + * Stefan Hajnoczi + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distribut
Re: [PATCH] tcm_vhost: Expose ABI version via VHOST_SCSI_GET_ABI_VERSION
On Thu, 2012-07-26 at 11:58 +0300, Avi Kivity wrote: > On 07/26/2012 05:34 AM, Nicholas A. Bellinger wrote: > > > > In that case, respinning a -v5 for tcm_vhost to start from ABI=0 and > > will post an updated patch shortly. > > > >> The main thing I would like to confirm is that this only versions the > >> tcm_vhost ioctls? In that case a single version number works. > >> > > > > Correct, the GET_ABI_VERSION call is only intended to identify the > > changing of tcm_vhost ioctls. > > Why use version numbers at all? > This was a request by QEMU folks.. > Feature maps are better, because you can get very fine granularity. > > Example..? If there is a better way to handle ioctl compat I'd certainly like to hear about it. -- 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: 'Device not ready' issue on mpt2sas since 3.1.10
On 07/25/2012 06:35 PM, tomm wrote: > > If this is a driver or firmware bug, then why would commit > 85ef06d1d252f6a2e73b678591ab71caad4667bb > cause this to happen? What is the interaction between this issue > and this commit which just flushes events? That's confusing to me as well. Tejun's patch seems very unrelated to anything related to power-state on non-removable disks. > Also this issue does not happen with mvsas, only with mpt2sas. Now _that_ is a useful data point. Is that with SATA disks attached? Why is it limited (so far) to just the mpt2sas controller? -- Robert -- 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: 'Device not ready' issue on mpt2sas since 3.1.10
On 07/25/2012 07:56 PM, Matthias Prager wrote: > > I don't yet understand all the code but I'm following your discussion > with Tejun: I've set up a minimal vm running gentoo with a mpt2sas > driven controller in passthrough mode. I've applied your proposed patch > against the vanilla 3.5.0 kernel (which includes Tejun's commit), and > I'm happy to report the problem does seem to get fixed by it. I can confirm this on my hardware as well with both 3.4.4 and 3.5.0. Without James' patch the kernels will immediately drop the I/O and with the patch both kernels will wake the SATA disks and then complete the I/O successfully. -- Robert -- 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: [dm-devel] [RESEND PATCH 3/3] dm mpath: add ability to disable partition creation
On Wed, Jul 25, 2012 at 02:02:15PM +0200, Hannes Reinecke wrote: > On 07/11/2012 05:18 PM, Alasdair G Kergon wrote: > > On Tue, Jun 26, 2012 at 02:32:05PM -0400, Mike Snitzer wrote: > >> The new 'no_partitions' feature serves as a notifier to kpartx to _not_ > >> create partitions on these multipath devices. > > > > This isn't really multipath-specific so doesn't belong in the target. > > It could go into dm core, but we already have flags attached to > > udev cookies that can turn udev rules on and off and thereby could > > allow userspace multipath to control whether or not kpartx creates > > partitions on any particular device. > > > > But first I'd like us to explore creating a config file for kpartx and > > controlling the behaviour from there. Activation could then be > > triggered by target type, device name, scsi WWID, dm UUID etc. according > > to rules in that file. > > > But that would mean one would have to maintain _two_ configuration > files, one for multipath and one for kpartx. > > Also kpartx initially doesn't have any clue about device names, SCSI > WWIDs etc. It just takes a device-mapper device and acts upon it. > The only information it's got is the device-mapper name (which could > be anything) and the device-mapper UUID if present. > > Same goes for udev rules; one would have to traverse the device > stack backwards to retrieve any information about the hardware. > > So when moving the configuration into kpartx we would lose quite > some flexibility. And reliability, methinks. > > Flexilibity is a valid goal, but not when it can achieved only by > adding complexity to other pieces. Kpartx does already grab the dm device name, uuid and target type (although it doesn't currently use the target type for anything). So, aside from adding code to read a config file, we don't really have to add any complexity to be able to have kpartx configure a device based on dm name (which admittedly probably isn't that useful), dm UUID, or target type. We could also have it configure based on the blkid results, which should be present when it's called by udev. When called manually, kpartx could use libblkid. We do lose the ability to have kpartx easily configure a device based on hardware type. However, that's not really essential. Multipath needs it because it can't even finish setting up a device until it knows the hardware type. For kpartx, it could make configuration simpler in cases where all of the LUNs from a particular hardware type needed to be configured the same way. This may be handy, but its not necessary, and you could achieve the same results using UUIDs. What we gain is the ability to set this property for non-multipath devices, which currently isn't possible. Also, blkid based (fs type, fs uuid, and fs label) configuration seems to me like it would be the most useful. Now I'm not arguing that adding configuration file handling isn't adding complexity, and adding libblkid calls would add more. But since multipath always sets the UUID, I don't see this losing any reliability, and I does gain the fexibility to work with any dm target type. I don't feel strongly about this one way or the other, but do see the benefits of having kpartx own this configuration setting. -Ben > > 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
Re: [PATCH v3 0/7] ZPODD patches for scsi tree
On 07/26/2012 10:41 AM, Aaron Lu wrote: On Thu, Jul 26, 2012 at 09:43:37AM -0400, Jeff Garzik wrote: On 07/26/2012 06:05 AM, Aaron Lu wrote: 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. What does this mean? Would you be more specific? The patch "libata-acpi: add ata port runtime D3Cold support" by Lin Ming introduced a function ata_acpi_wake_dev in libata-acpi.c, and only lives in libata-next tree but not scsi-misc tree. [...] Another minor issue is, I need to use the can_power_off and wakeup_by_user flag of the scsi_device structure in sr patches, but they are all introduced in patches in libata-next tree, so I have to re-define them in this patch set. Will cause conflict if James send these sr patches to Linus. Any way to avoid this? Linus said he just merged the libata patches, so they should appear in the torvalds/linux.git as soon as he pushes out (in the next 12 hours, I'm guessing). Up to James how he wants to coordinate after that... he might pull in Linus's tree into scsi-misc or another solution. Jeff -- 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: [git patches] libata updates
On Wed, Jul 25, 2012 at 7:10 PM, Jeff Garzik wrote: > > Thanks, so noted. I guess if the merge gets more complex than something > easily described in an email, that implies that maintainers should do more > cross-coordination and maybe a merge tree. It's fairly rare. It happens mostly with the arch trees for some reason - the ARM tree used to be an unholy mess. And then we have the small "oops, we didn't even notice" things when some driver (or FS) interface changes, and we have a new driver/fs or just extended an old one, and there's a subtle conflict. And people miss those, and quite frankly, it's not a huge deal. We can fix it up later. It's the "oh, I knew about this" cases where it's fixed up as a separate commit I dislike. And quite frankly, I really do a lot of merges, and over the history of git we have not had all that many really complicated ones. I commonly send people email saying "ok, this clashed, you need to double-check my merge", but it's not common that they are really problems. So to a first approximation, I'd actually prefer that submaintainers not care *at*all* about whether something clashes upstream or not. If there are consistent and problematic clashes, that implies some deeper problem, and the solution to that is not "let's pre-merge", but rather more along the lines of "we're doing something wrong, maybe our interfaces are crap, or our modularity is wrong, let's think about it". And for subsystems where we have had problems, it's actually really nice if the maintainer sends me the unmerged "this is the work I've done" tree, and then perhaps has a separate "xyzzy-merged" branch that has a pre-merged version. For cases like that, I will do the merge myself, but I'll actually double-check my merge against the maintainer merge. And it's happened more than once that my merge has differed, and _my_ merge is the correct one. The maintainer may know his code better, but I know my merging. I do a ton of them. For example, this week I've done 66 merges, and 15 of them had conflicts. Of the 15, only two were interesting iirc, but even those weren't really "problematic", they were just enough to trigger me to send out emails to the maintainers about them. And I don't think your libata merge would really have merited even that, apart from the small semantic thing (which would also have been trivial with a oneliner "heads up, check out the semantic change in xyz.c:abcdef()". > What's the best way for libata to move forward, now that this hideous merge > has been pushed out to the Well Known libata branches? The > pre-jgarzik-merge commit you would have pulled is > dc7f71f486f4f5fa96f6dcf86833da020cde8a11 had my pull request been proper. I'll take your merge, it's not like it's a huge problem. What I care most about is the "flow", and I am making a stink just so that this doesn't become a common issue. We have tons of ugly history, and I'm not black-and-white - problems happen. Big deal. I just want to make sure that they don't become systemic. Linus -- 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 3/3] hpsa: use ioremap_nocache instead of ioremap
From: Stephen M. Cameron
I think ioremap() ends up being equivalent to ioremap_nocache
by default, but we should signal our intent that these mappings
should be non-cacheable.
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 415db96..5ed5859 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3337,7 +3337,8 @@ static void __iomem *remap_pci_mem(ulong base, ulong size)
{
ulong page_base = ((ulong) base) & PAGE_MASK;
ulong page_offs = ((ulong) base) - page_base;
- void __iomem *page_remapped = ioremap(page_base, page_offs + size);
+ void __iomem *page_remapped = ioremap_nocache(page_base,
+ page_offs + size);
return page_remapped ? (page_remapped + page_offs) : NULL;
}
--
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/3] hpsa: fix incorrect abort diagnostic message
From: Stephen M. Cameron
In the abort handler, when asked to abort a command which
is not known to the driver, SUCCESS is returned, but the
diagnostic message incorrectly indicates the abort failed.
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 015a6c8..415db96 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -2609,7 +2609,7 @@ static int hpsa_eh_abort_handler(struct scsi_cmnd *sc)
/* not in reqQ, if also not in cmpQ, must have already completed */
found = hpsa_find_cmd_in_queue(h, sc, &h->cmpQ);
if (!found) {
- dev_dbg(&h->pdev->dev, "%s Request FAILED (not known to
driver).\n",
+ dev_dbg(&h->pdev->dev, "%s Request SUCCEEDED (not known to
driver).\n",
msg);
return SUCCESS;
}
--
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 0/3] hpsa patches for July 2012
Only one important bug fix, we should use LUN reset rather than target reset in the reset error handler as Smart Array logical drives don't actually support target reset and end up getting offlined, which is pretty bad. I had done my reset testing with tape drives only, which turns out to have been a stupid thing to do. The other two patches are very minor. --- Stephen M. Cameron (3): hpsa: Use LUN reset instead of target reset hpsa: fix incorrect abort diagnostic message hpsa: use ioremap_nocache instead of ioremap drivers/scsi/hpsa.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) -- -- steve -- 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/3] hpsa: Use LUN reset instead of target reset
From: Stephen M. Cameron It turns out Smart Array logical drives do not support target reset and when the target reset fails, the logical drive will be taken off line. Symptoms look like this: hpsa :03:00.0: Abort request on C1:B0:T0:L0 hpsa :03:00.0: resetting device 1:0:0:0 hpsa :03:00.0: cp 880037c56000 is reported invalid (probably means target device no longer present) hpsa :03:00.0: resetting device failed. sd 1:0:0:0: Device offlined - not ready after error recovery sd 1:0:0:0: rejecting I/O to offline device EXT3-fs error (device sdb1): read_block_bitmap: LUN reset is supported though, and is what we should be using. Target reset is also disruptive in shared SAS situations, for example, an external MSA1210m which does support target reset attached to Smart Arrays in multiple hosts -- a target reset from one host is disruptive to other hosts as all LUNs on the target will be reset and will abort all outstanding i/os back to all the attached hosts. So we should use LUN reset, not target reset. Tested this with Smart Array logical drives and with tape drives. Not sure how this bug survived since 2009, except it must be very rare for a Smart Array to require more than 30s to complete a request. Signed-off-by: Stephen M. Cameron Cc: sta...@vger.kernel.org --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 796482b..015a6c8 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -3265,7 +3265,7 @@ static void fill_cmd(struct CommandList *c, u8 cmd, struct ctlr_info *h, c->Request.Timeout = 0; /* Don't time out */ memset(&c->Request.CDB[0], 0, sizeof(c->Request.CDB)); c->Request.CDB[0] = cmd; - c->Request.CDB[1] = 0x03; /* Reset target above */ + c->Request.CDB[1] = HPSA_RESET_TYPE_LUN; /* If bytes 4-7 are zero, it means reset the */ /* LunID device */ c->Request.CDB[4] = 0x00; -- 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: [git patches] libata updates
On Thu, 26 Jul 2012, Aaron Lu wrote: > On 07/26/2012 01:05 PM, James Bottomley wrote: > > On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote: > >> On 07/26/2012 05:38 AM, Jeff Garzik wrote: > >>> On 07/25/2012 04:35 PM, Jeff Garzik wrote: > * Updating libata to directly bind with ACPI / runtime power mgmt. > This is a pre-req for SATA ZPODD (CD-ROM power management). > > Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next > for weeks. > > The rest of [ZPODD] will probably come via SCSI tree, as it involves > a lot of updates to the 'sr' driver etc. > >>> > >>> BTW Lin and Aaron, note that this did not include these changes: > >>> > >>> sr: check support for device busy class events > >>> sr: support zero power ODD > >>> sr: make sure ODD is in resumed state in block ioctl > >>> > >>> as in the end I wanted to put the brakes on SCSI-touching patches. These > >>> should be able to go into James' scsi-misc tree with the other SCSI-area > >>> ZPODD changes. > >>> > >>> For those three 'sr' changes listed above, you may add > >>> > >>> Acked-by: Jeff Garzik > >>> > >>> when moving them over. > >> > >> Thanks Jeff. > >> > >> Hi James, > >> I'll prepare these dropped patches plus some other fixes for ZPODD which > >> I've sent v2 recently and merge them into v3 for you to review. > > > > They weren't exactly dropped ... I've been waiting for you to address > > Alan Stern's comments, since he's our resident expert on suspend/resume. > > Oh, I forgot to mention, that I agree with Alan's comments and have > addressed them in my v2 patches here: > http://marc.info/?l=linux-scsi&m=134312317325650&w=2 > > The 2 patches Alan has comments are: > http://marc.info/?l=linux-scsi&m=134312311025619&w=2 > http://marc.info/?l=linux-scsi&m=134312308225610&w=2 > > Hi Alan, > Are the v2 patches look OK to you? Yes, they are better now. Acked-by: Alan Stern -- 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 0/7] ZPODD patches for scsi tree
On Thu, Jul 26, 2012 at 09:43:37AM -0400, Jeff Garzik wrote:
> On 07/26/2012 06:05 AM, Aaron Lu wrote:
> >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.
>
> What does this mean? Would you be more specific?
The patch "libata-acpi: add ata port runtime D3Cold support" by Lin Ming
introduced a function ata_acpi_wake_dev in libata-acpi.c, and only lives
in libata-next tree but not scsi-misc tree.
In patch "scsi: sr: support zero power ODD(ZPODD)" I need to set the
wakeup_by_user flag of the scsi device in ata_acpi_wake_dev like this:
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -985,8 +985,10 @@ static void ata_acpi_wake_dev(acpi_handle handle, u32
event, void *context)
struct ata_device *ata_dev = context;
if (event == ACPI_NOTIFY_DEVICE_WAKE && ata_dev &&
- pm_runtime_suspended(&ata_dev->sdev->sdev_gendev))
+ pm_runtime_suspended(&ata_dev->sdev->sdev_gendev)) {
+ ata_dev->sdev->wakeup_by_user = 1;
scsi_autopm_get_device(ata_dev->sdev);
+ }
}
But since there is no such function in scsi-misc tree, I can't set the
flag. Any suggestions?
Another minor issue is, I need to use the can_power_off and
wakeup_by_user flag of the scsi_device structure in sr patches, but
they are all introduced in patches in libata-next tree, so I have to
re-define them in this patch set. Will cause conflict if James send
these sr patches to Linus. Any way to avoid this?
Thanks,
Aaron
--
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 0/7] ZPODD patches for scsi tree
On 07/26/2012 06:05 AM, Aaron Lu wrote: 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. What does this mean? Would you be more specific? Jeff -- 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] virtio-scsi: fix LUNs greater than 255
virtio-scsi needs to report LUNs greater than 256 using the "flat" format. Because the Linux SCSI layer just maps the SCSI LUN to an u32, without any parsing, these end up in the range from 16640 to 32767. Fix max_lun to account for the possibility that logical unit numbers are encoded with the "flat" format. Cc: Signed-off-by: Paolo Bonzini --- drivers/scsi/virtio_scsi.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index c7030fb..8b6b927 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -677,7 +677,11 @@ static int __devinit virtscsi_probe(struct virtio_device *vdev) cmd_per_lun = virtscsi_config_get(vdev, cmd_per_lun) ?: 1; shost->cmd_per_lun = min_t(u32, cmd_per_lun, shost->can_queue); shost->max_sectors = virtscsi_config_get(vdev, max_sectors) ?: 0x; - shost->max_lun = virtscsi_config_get(vdev, max_lun) + 1; + + /* LUNs > 256 are reported with format 1, so they go in the range +* 16640-32767. +*/ + shost->max_lun = virtscsi_config_get(vdev, max_lun) + 1 + 0x4000; shost->max_id = num_targets; shost->max_channel = 0; shost->max_cmd_len = VIRTIO_SCSI_CDB_SIZE; -- 1.7.1 -- 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] virtio-scsi: support online resizing of disks
Support the LUN parameter change event. Currently, the host fires this event
when the capacity of a disk is changed from the virtual machine monitor.
The resize then appears in the kernel log like this:
sd 0:0:0:0: [sda] 46137344 512-byte logical blocks: (23.6 GB/22.0 GIb)
sda: detected capacity change from 22548578304 to 23622320128
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 31 ++-
include/linux/virtio_scsi.h |2 ++
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 8b6b927..c1a5e60 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -279,6 +279,31 @@ static void virtscsi_handle_transport_reset(struct
virtio_scsi *vscsi,
}
}
+static void virtscsi_handle_param_change(struct virtio_scsi *vscsi,
+struct virtio_scsi_event *event)
+{
+ struct scsi_device *sdev;
+ struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
+ unsigned int target = event->lun[1];
+ unsigned int lun = (event->lun[2] << 8) | event->lun[3];
+ u8 asc = event->reason & 255;
+ u8 ascq = event->reason >> 8;
+
+ sdev = scsi_device_lookup(shost, 0, target, lun);
+ if (!sdev) {
+ pr_err("SCSI device %d 0 %d %d not found\n",
+ shost->host_no, target, lun);
+ return;
+ }
+
+ /* Handle "Parameters changed", "Mode parameters changed", and
+ "Capacity data has changed". */
+ if (asc == 0x2a && (ascq == 0x00 || ascq == 0x01 || ascq == 0x09))
+ scsi_rescan_device(&sdev->sdev_gendev);
+
+ scsi_device_put(sdev);
+}
+
static void virtscsi_handle_event(struct work_struct *work)
{
struct virtio_scsi_event_node *event_node =
@@ -297,6 +322,9 @@ static void virtscsi_handle_event(struct work_struct *work)
case VIRTIO_SCSI_T_TRANSPORT_RESET:
virtscsi_handle_transport_reset(vscsi, event);
break;
+ case VIRTIO_SCSI_T_PARAM_CHANGE:
+ virtscsi_handle_param_change(vscsi, event);
+ break;
default:
pr_err("Unsupport virtio scsi event %x\n", event->event);
}
@@ -737,7 +765,8 @@ static struct virtio_device_id id_table[] = {
};
static unsigned int features[] = {
- VIRTIO_SCSI_F_HOTPLUG
+ VIRTIO_SCSI_F_HOTPLUG,
+ VIRTIO_SCSI_F_CHANGE,
};
static struct virtio_driver virtio_scsi_driver = {
diff --git a/include/linux/virtio_scsi.h b/include/linux/virtio_scsi.h
index dc8d305..d6b4440 100644
--- a/include/linux/virtio_scsi.h
+++ b/include/linux/virtio_scsi.h
@@ -72,6 +72,7 @@ struct virtio_scsi_config {
/* Feature Bits */
#define VIRTIO_SCSI_F_INOUT0
#define VIRTIO_SCSI_F_HOTPLUG 1
+#define VIRTIO_SCSI_F_CHANGE 2
/* Response codes */
#define VIRTIO_SCSI_S_OK 0
@@ -108,6 +109,7 @@ struct virtio_scsi_config {
#define VIRTIO_SCSI_T_NO_EVENT 0
#define VIRTIO_SCSI_T_TRANSPORT_RESET 1
#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2
+#define VIRTIO_SCSI_T_PARAM_CHANGE 3
/* Reasons of transport reset event */
#define VIRTIO_SCSI_EVT_RESET_HARD 0
--
1.7.1
--
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 0/2] virtio-scsi fixes for 3.6
James, patch 1 fixes scanning of LUNs whose number is greater than 255. QEMU passes a max_lun of 16383 (because it uses SAM numbering) but in Linux it must become 32768 (because LUNs above 255 are "relocated" to 16640). Patch 2 is a resubmission of the patch for online resizing of virtio-scsi LUNs, which needs to be rebased. LUNs above 255 now work for all of scanning, hotplug, hotunplug and resize. Thanks, Paolo Paolo Bonzini (2): virtio-scsi: fix LUNs greater than 255 virtio-scsi: support online resizing of disks drivers/scsi/virtio_scsi.c | 37 +++-- include/linux/virtio_scsi.h |2 ++ 2 files changed, 37 insertions(+), 2 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: virtio(-scsi) vs. chained sg_lists (was Re: [PATCH] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list)
Il 26/07/2012 09:58, Paolo Bonzini ha scritto:
>
>> > Please CC me on the "convert to sg copy-less" patches, It looks interesting
> Sure.
Well, here is the gist of it (note it won't apply on any public tree,
hence no SoB yet). It should be split in multiple changesets and you
can make more simplifications on top of it, because
virtio_scsi_target_state is not anymore variable-sized, but that's
secondary.
The patch includes the conversion of virtio_ring.c to use sg_next.
It is a bit ugly because of backwards-compatibility, it can be fixed
by going through all drivers; not that there are many.
I'm still a bit worried of the future of this feature though. I would
be the first and (because of the non-portability) presumably sole user
for some time. Someone axing chained sg-lists in the future does not
seem too unlikely. So in practice I would rather just add to virtio a
function that takes two struct scatterlist ** (or an array of struct
scatterlist * + size pairs). Converting to sg_chain once it takes off
would be trivial.
Paolo
>From 57f8d4a20cbe9b3b25e10cd0595d7ac102fc8f73 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
Date: Thu, 26 Jul 2012 09:58:14 +0200
Subject: [PATCH] virtio-scsi: use chained sg_lists
Using chained sg_lists simplifies everything a lot.
The scatterlists we pass to virtio are always of bounded size,
and can be allocated on the stack. This means we do not need to
take tgt_lock and struct virtio_scsi_target_state does not have
anymore a flexible array at the end, so we can avoid a pointer
access.
---
drivers/block/virtio_blk.c |3 +
drivers/scsi/virtio_scsi.c | 93 ---
drivers/virtio/virtio_ring.c | 93 +++
include/linux/virtio.h |8 +++
4 files changed, 114 insertions(+), 83 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 13f7ccb..ef65ea1 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -66,9 +66,6 @@ struct virtio_scsi_target_state {
struct virtio_scsi_vq *req_vq;
atomic_t reqs;
-
- /* For sglist construction when adding commands to the virtqueue. */
- struct scatterlist sg[];
};
/* Driver instance state */
@@ -362,20 +359,6 @@ static void virtscsi_event_done(struct virtqueue *vq)
spin_unlock_irqrestore(&vscsi->event_vq.vq_lock, flags);
};
-static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx,
- struct scsi_data_buffer *sdb)
-{
- struct sg_table *table = &sdb->table;
- struct scatterlist *sg_elem;
- unsigned int idx = *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);
-
- *p_idx = idx;
-}
-
/**
* virtscsi_map_cmd - map a scsi_cmd to a virtqueue scatterlist
* @vscsi : virtio_scsi state
@@ -384,52 +367,57 @@ static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx,
* @in_num : number of write-only elements
* @req_size : size of the request buffer
* @resp_size : size of the response buffer
- *
- * Called with tgt_lock held.
*/
-static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt,
- struct virtio_scsi_cmd *cmd,
- unsigned *out_num, unsigned *in_num,
+static void virtscsi_map_cmd(struct virtio_scsi_cmd *cmd,
+ struct scatterlist *sg_out,
+ unsigned *out_num,
+ struct scatterlist *sg_in,
+ unsigned *in_num,
size_t req_size, size_t resp_size)
{
struct scsi_cmnd *sc = cmd->sc;
- struct scatterlist *sg = tgt->sg;
- unsigned int idx = 0;
+
+ sg_init_table(sg_out, 2);
+ sg_init_table(sg_in, 2);
/* Request header. */
- sg_set_buf(&sg[idx++], &cmd->req, req_size);
+ sg_set_buf(&sg_out[0], &cmd->req, req_size);
+ *out_num = 1;
/* Data-out buffer. */
- if (sc && sc->sc_data_direction != DMA_FROM_DEVICE)
- virtscsi_map_sgl(sg, &idx, scsi_out(sc));
-
- *out_num = idx;
+ if (sc && sc->sc_data_direction != DMA_FROM_DEVICE) {
+ struct sg_table *table = &scsi_out(sc)->table;
+ sg_chain(sg_out, 2, table->sgl);
+ *out_num += table->nents;
+ }
/* Response header. */
- sg_set_buf(&sg[idx++], &cmd->resp, resp_size);
+ sg_set_buf(&sg_in[0], &cmd->resp, resp_size);
+ *in_num = 1;
/* Data-in buffer */
- if (sc && sc->sc_data_direction != DMA_TO_DEVICE)
- virtscsi_map_sgl(sg, &idx, scsi_in(sc));
-
- *in_num = idx - *out_num;
+ if (sc && sc->sc_data_direction != DMA_TO_DEVICE) {
+ struct sg_table *table = &scsi_in(sc)->table;
+ sg_chain(sg_in, 2, table->sgl);
+ *in_num += table->nents;
+ }
}
-static int virtscsi_kick_cmd(struct virtio_scsi_target_state *tgt,
- struct virtio_scsi_vq *vq,
+static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
struct virtio_scsi_cmd *cmd,
size_t req_size, size_t resp_size, gfp_t gfp)
{
+ struct scatterlist sg_out[2], sg_in[2];
unsigned int out_num, in_num;
unsigned long flags;
int ret;
- spin_lock_irqsave(&tgt->tgt_lock, flags)
Re: [PATCH v3 2/7] scsi: pm: use autosuspend if device supports it
On Thursday 26 July 2012 20:43:32 Aaron Lu wrote:
> > What is the purpose of this approach?
>
> The purpose is to let scsi layer driver(sd, sr, etc.) use the same pm
> api(scsi_autopm_put_device) to put the device to runtime suspended
> state.
> When the device is ready to be suspended, if it does not make use of
> autosuspend, call pm_runtime_put_sync for it; if it makes use of
> autosuspend, call the autosuspend runtime pm apis for it.
>
> > You need a very good reason to have an API do two different things
> > based on this.
>
> If you see the above reason not good, I'll prepare an updated version
> to create a new api to cover the autosuspend case, something like:
> void scsi_autopm_put_device_autosuspend(struct scsi_device *sdev)
> {
> pm_runtime_mark_last_busy(&sdev->sdev_gendev);
> pm_runtime_put_autosuspend(&sdev->sdev_gendev);
> }
> Does this look right?
Much better :-)
Regards
Oliver
--
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 6/7] scsi: sr: balance sr disk events block depth
On Thu, Jul 26, 2012 at 02:54:01PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 26-07-2012 14:05, Aaron Lu wrote:
>
> >When the ODD is resumed, disk_unblock_events should be called when:
> >1 The ODD is runtime resumed;
> >2 System is resuming from S3 and the ODD is runtime suspended before S3;
> >But not when the system is resuming from S3 and the ODD is runtime
> >active before S3.
>
> >So seperate the resume calls, one for system resume and one for runtime
> >resume to do different things accordingly.
>
> >Signed-off-by: Aaron Lu
> >---
> > drivers/scsi/sr.c | 21 +
> > 1 file changed, 21 insertions(+)
>
> >diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> >index fd1c2f6..b8c2f9d 100644
> >--- a/drivers/scsi/sr.c
> >+++ b/drivers/scsi/sr.c
> [...]
> >@@ -211,6 +217,21 @@ static int sr_suspend(struct device *dev, pm_message_t
> >msg)
> >
> > static int sr_resume(struct device *dev)
> > {
> >+struct scsi_cd *cd = dev_get_drvdata(dev);
> >+
> >+/*
> >+ * If ODD is runtime suspended before system pm, unblock disk
> >+ * events now since on system resume, we will fully resume it
>
>Comma not needed.
Thanks.
>
> >+ * and set its rumtime status to active.
>
>s/rumtime/runtime/. Nice typo. %-)
Thanks, and I'll use a spell checker next time to avoid such mistakes.
-Aaron
--
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 2/7] scsi: pm: use autosuspend if device supports it
On Thu, Jul 26, 2012 at 12:44:24PM +0200, Oliver Neukum wrote:
> On Thursday 26 July 2012 18:05:24 Aaron Lu wrote:
> > If the device is using autosuspend, when scsi_autopm_put_device is
> > called for it, use autosuspend runtime pm calls instead of the sync
> > call.
>
> What is the purpose of this approach?
The purpose is to let scsi layer driver(sd, sr, etc.) use the same pm
api(scsi_autopm_put_device) to put the device to runtime suspended
state.
When the device is ready to be suspended, if it does not make use of
autosuspend, call pm_runtime_put_sync for it; if it makes use of
autosuspend, call the autosuspend runtime pm apis for it.
> You need a very good reason to have an API do two different things
> based on this.
If you see the above reason not good, I'll prepare an updated version
to create a new api to cover the autosuspend case, something like:
void scsi_autopm_put_device_autosuspend(struct scsi_device *sdev)
{
pm_runtime_mark_last_busy(&sdev->sdev_gendev);
pm_runtime_put_autosuspend(&sdev->sdev_gendev);
}
Does this look right?
Thanks,
Aaron
--
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: qla2xxx: print MAC via %pMR
On Thu, 12 Jul 2012, Andy Shevchenko wrote: Signed-off-by: Andy Shevchenko --- drivers/scsi/qla2xxx/qla_attr.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c index 5ab9530..095ba85 100644 --- a/drivers/scsi/qla2xxx/qla_attr.c +++ b/drivers/scsi/qla2xxx/qla_attr.c @@ -1193,10 +1193,7 @@ qla2x00_vn_port_mac_address_show(struct device *dev, if (!IS_CNA_CAPABLE(vha->hw)) return snprintf(buf, PAGE_SIZE, "\n"); - return snprintf(buf, PAGE_SIZE, "%02x:%02x:%02x:%02x:%02x:%02x\n", - vha->fcoe_vn_port_mac[5], vha->fcoe_vn_port_mac[4], - vha->fcoe_vn_port_mac[3], vha->fcoe_vn_port_mac[2], - vha->fcoe_vn_port_mac[1], vha->fcoe_vn_port_mac[0]); + return snprintf(buf, PAGE_SIZE, "%pMR\n", vha->fcoe_vn_port_mac); } static ssize_t Acked-by: Chad Dupuis This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. -- 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] scsi_megaraid: addition spin_lock in megaraid_abort()
In function megaraid_abort() there are calls to megaraid_abort_and_reset() and mega_rundoneq() which access shared data (like pending_list) without synchronization.In function megaraid_reset() the same calls were done with spin_lock held. So, the patch adds spin_lock_irq and spin_unlock_irq to megaraid_abort(). Found by Linux Driver Verification project (linuxtesting.org) Signed-off-by: Pavel Andrianov --- drivers/scsi/megaraid.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c index 4d39a9f..7572d86 100644 --- a/drivers/scsi/megaraid.c +++ b/drivers/scsi/megaraid.c @@ -1898,6 +1898,8 @@ megaraid_abort(Scsi_Cmnd *cmd) adapter = (adapter_t *)cmd->device->host->hostdata; + spin_lock_irq(&adapter->lock); + rval = megaraid_abort_and_reset(adapter, cmd, SCB_ABORT); /* @@ -1905,6 +1907,7 @@ megaraid_abort(Scsi_Cmnd *cmd) * to be communicated over to the mid layer. */ mega_rundoneq(adapter); + spin_unlock_irq(&adapter->lock); return rval; } -- 1.7.4.1 -- 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 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
On Thu, Jul 26, 2012 at 5:05 PM, S, Venkatraman wrote: > On Thu, Jul 26, 2012 at 4:42 PM, vinayak holikatti > wrote: >> On Thu, Jul 26, 2012 at 4:02 PM, S, Venkatraman wrote: >>> On Thu, Jul 26, 2012 at 2:12 PM, Vinayak Holikatti >>> wrote: This patch set adds following features - Seggregate PCI specific code in ufshcd.c - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module - Adds Platform glue driver ufshcd-pltfrm.c - Update correct transfer size in Command UPIU Vinayak Holikatti (4): [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver [SCSI] ufs: Add Platform glue driver for ufshcd [SCSI] ufs: Correct the expected data transfer size drivers/scsi/ufs/Kconfig | 37 +++- drivers/scsi/ufs/Makefile|2 + drivers/scsi/ufs/ufshcd-pci.c| 228 drivers/scsi/ufs/ufshcd-pltfrm.c | 222 drivers/scsi/ufs/ufshcd.c| 422 ++ drivers/scsi/ufs/ufshcd.h| 206 +++ drivers/scsi/ufs/ufshcd_common.h | 53 + 7 files changed, 813 insertions(+), 357 deletions(-) >>> >>> Two minor observations.. >>> 1) If both pci and platform have to do the exact same thing in their >>> _suspend() and _resume() routines, perhaps there is scope for making >>> them as common (the steps outlined in them should be done in core >>> ufshcd) ? >> Both will not have to do the exact same thing. We have plan to implement >> ufshcd_suspend and ufshcd_resume which will be generic and will be part >> of ufshcd core, as you said. > > Thanks. The comments in the driver files don't reflect this; it'd be > wise to create > the placeholder for core_suspend()/resume() in ufshcd.c, instead of > the platform drivers. Ok, I will make a place holder in ufshcd.c in next version of patch. > >>> >>> 2) Need to include ufshcd_common.h in ufshcd.c so that the prototypes >>> are supplied for the exported functions. >> Thank you, I will make necessary changes in next version of patches. >> -- 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 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
On Thu, Jul 26, 2012 at 4:42 PM, vinayak holikatti wrote: > On Thu, Jul 26, 2012 at 4:02 PM, S, Venkatraman wrote: >> On Thu, Jul 26, 2012 at 2:12 PM, Vinayak Holikatti >> wrote: >>> This patch set adds following features >>> - Seggregate PCI specific code in ufshcd.c >>> - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module >>> - Adds Platform glue driver ufshcd-pltfrm.c >>> - Update correct transfer size in Command UPIU >>> >>> Vinayak Holikatti (4): >>> [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code >>> [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver >>> [SCSI] ufs: Add Platform glue driver for ufshcd >>> [SCSI] ufs: Correct the expected data transfer size >>> >>> drivers/scsi/ufs/Kconfig | 37 +++- >>> drivers/scsi/ufs/Makefile|2 + >>> drivers/scsi/ufs/ufshcd-pci.c| 228 >>> drivers/scsi/ufs/ufshcd-pltfrm.c | 222 >>> drivers/scsi/ufs/ufshcd.c| 422 >>> ++ >>> drivers/scsi/ufs/ufshcd.h| 206 +++ >>> drivers/scsi/ufs/ufshcd_common.h | 53 + >>> 7 files changed, 813 insertions(+), 357 deletions(-) >> >> Two minor observations.. >> 1) If both pci and platform have to do the exact same thing in their >> _suspend() and _resume() routines, perhaps there is scope for making >> them as common (the steps outlined in them should be done in core >> ufshcd) ? > Both will not have to do the exact same thing. We have plan to implement > ufshcd_suspend and ufshcd_resume which will be generic and will be part > of ufshcd core, as you said. Thanks. The comments in the driver files don't reflect this; it'd be wise to create the placeholder for core_suspend()/resume() in ufshcd.c, instead of the platform drivers. >> >> 2) Need to include ufshcd_common.h in ufshcd.c so that the prototypes >> are supplied for the exported functions. > Thank you, I will make necessary changes in next version of patches. > -- 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] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
On Thu, 2012-07-26 at 12:43 +0200, Paolo Bonzini wrote: > Il 26/07/2012 12:33, James Bottomley ha scritto: > >> > Has it already been considered to modify scsilun_to_int() such that LUN > >> > numbers start at zero even for addressing method 1 ? This is what e.g. > >> > the function scst_unpack_lun() already does. See also > >> > http://scst.svn.sourceforge.net/viewvc/scst/trunk/scst/src/scst_lib.c?revision=HEAD&view=markup. > > Yes, as I said before, the problem is that the actual numbers are > > > > 1. not 1:1: there are several possible encodings of luns 0-255 > > 2. hierarchical, so once you go beyond a single level you can't properly > > use a numeric representation either. > > > > the mid layer just uses the lun number as an encoding of the actual SAM > > lun. The key for us is that int_to_scsilun has to go back the other > > way. > > I still disagree, but I will modify QEMU so that this patch is not > necessary. Later I can switch to int_to_scsilun. Thanks, on the principle of least surprise, you definitely don't want the lun numbering to change depending on whether you directly attach to the array or pass it through virtio-scsi. James -- 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 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
On Thu, Jul 26, 2012 at 4:02 PM, S, Venkatraman wrote: > On Thu, Jul 26, 2012 at 2:12 PM, Vinayak Holikatti > wrote: >> This patch set adds following features >> - Seggregate PCI specific code in ufshcd.c >> - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module >> - Adds Platform glue driver ufshcd-pltfrm.c >> - Update correct transfer size in Command UPIU >> >> Vinayak Holikatti (4): >> [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code >> [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver >> [SCSI] ufs: Add Platform glue driver for ufshcd >> [SCSI] ufs: Correct the expected data transfer size >> >> drivers/scsi/ufs/Kconfig | 37 +++- >> drivers/scsi/ufs/Makefile|2 + >> drivers/scsi/ufs/ufshcd-pci.c| 228 >> drivers/scsi/ufs/ufshcd-pltfrm.c | 222 >> drivers/scsi/ufs/ufshcd.c| 422 >> ++ >> drivers/scsi/ufs/ufshcd.h| 206 +++ >> drivers/scsi/ufs/ufshcd_common.h | 53 + >> 7 files changed, 813 insertions(+), 357 deletions(-) > > Two minor observations.. > 1) If both pci and platform have to do the exact same thing in their > _suspend() and _resume() routines, perhaps there is scope for making > them as common (the steps outlined in them should be done in core > ufshcd) ? Both will not have to do the exact same thing. We have plan to implement ufshcd_suspend and ufshcd_resume which will be generic and will be part of ufshcd core, as you said. > > 2) Need to include ufshcd_common.h in ufshcd.c so that the prototypes > are supplied for the exported functions. Thank you, I will make necessary changes in next version of patches. -- Regards, Vinayak Holikatti -- 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 6/7] scsi: sr: balance sr disk events block depth
Hello.
On 26-07-2012 14:05, Aaron Lu wrote:
When the ODD is resumed, disk_unblock_events should be called when:
1 The ODD is runtime resumed;
2 System is resuming from S3 and the ODD is runtime suspended before S3;
But not when the system is resuming from S3 and the ODD is runtime
active before S3.
So seperate the resume calls, one for system resume and one for runtime
resume to do different things accordingly.
Signed-off-by: Aaron Lu
---
drivers/scsi/sr.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index fd1c2f6..b8c2f9d 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
[...]
@@ -211,6 +217,21 @@ static int sr_suspend(struct device *dev, pm_message_t msg)
static int sr_resume(struct device *dev)
{
+ struct scsi_cd *cd = dev_get_drvdata(dev);
+
+ /*
+* If ODD is runtime suspended before system pm, unblock disk
+* events now since on system resume, we will fully resume it
Comma not needed.
+* and set its rumtime status to active.
s/rumtime/runtime/. Nice typo. %-)
WBR, Sergei
--
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 2/7] scsi: pm: use autosuspend if device supports it
On Thursday 26 July 2012 18:05:24 Aaron Lu wrote: > If the device is using autosuspend, when scsi_autopm_put_device is > called for it, use autosuspend runtime pm calls instead of the sync > call. What is the purpose of this approach? You need a very good reason to have an API do two different things based on this. Regards Oliver -- 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] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
Il 26/07/2012 12:33, James Bottomley ha scritto: >> > Has it already been considered to modify scsilun_to_int() such that LUN >> > numbers start at zero even for addressing method 1 ? This is what e.g. >> > the function scst_unpack_lun() already does. See also >> > http://scst.svn.sourceforge.net/viewvc/scst/trunk/scst/src/scst_lib.c?revision=HEAD&view=markup. > Yes, as I said before, the problem is that the actual numbers are > > 1. not 1:1: there are several possible encodings of luns 0-255 > 2. hierarchical, so once you go beyond a single level you can't properly > use a numeric representation either. > > the mid layer just uses the lun number as an encoding of the actual SAM > lun. The key for us is that int_to_scsilun has to go back the other > way. I still disagree, but I will modify QEMU so that this patch is not necessary. Later I can switch to int_to_scsilun. 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 1/2] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
On Thu, 2012-07-26 at 10:17 +, Bart Van Assche wrote:
> On 07/26/12 09:21, James Bottomley wrote:
> > On Thu, 2012-07-26 at 11:04 +0200, Paolo Bonzini wrote:
> >> Il 26/07/2012 10:52, James Bottomley ha scritto:
> > +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
> > +{
> > + unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
> > + return lun & 16383;
> > +}
> > +
> >>> Why are you rolling your own incomplete version of scsilun_to_int here?
> >>
> >> Because scsilun_to_int does not do the AND, so it would have exactly the
> >> same bug I'm fixing.
> >
> > It's not a bug ... it's the encoding. All the other devices use this
> > too. Ideally we should have switched to 64 bit lun numbers for the
> > encoding to be exact, but nothing so far has gone over 32 bits. If we
> > don't encode the Address method as part of the lun number, we don't get
> > the reverse transform right and the addressing often fails.
> >
> > That does mean that arrays that use address method=1 in REPORT LUNS have
> > their lun numbers start at 16384.
>
> Has it already been considered to modify scsilun_to_int() such that LUN
> numbers start at zero even for addressing method 1 ? This is what e.g.
> the function scst_unpack_lun() already does. See also
> http://scst.svn.sourceforge.net/viewvc/scst/trunk/scst/src/scst_lib.c?revision=HEAD&view=markup.
Yes, as I said before, the problem is that the actual numbers are
1. not 1:1: there are several possible encodings of luns 0-255
2. hierarchical, so once you go beyond a single level you can't properly
use a numeric representation either.
the mid layer just uses the lun number as an encoding of the actual SAM
lun. The key for us is that int_to_scsilun has to go back the other
way.
James
--
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 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
On Thu, Jul 26, 2012 at 2:12 PM, Vinayak Holikatti wrote: > This patch set adds following features > - Seggregate PCI specific code in ufshcd.c > - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module > - Adds Platform glue driver ufshcd-pltfrm.c > - Update correct transfer size in Command UPIU > > Vinayak Holikatti (4): > [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code > [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver > [SCSI] ufs: Add Platform glue driver for ufshcd > [SCSI] ufs: Correct the expected data transfer size > > drivers/scsi/ufs/Kconfig | 37 +++- > drivers/scsi/ufs/Makefile|2 + > drivers/scsi/ufs/ufshcd-pci.c| 228 > drivers/scsi/ufs/ufshcd-pltfrm.c | 222 > drivers/scsi/ufs/ufshcd.c| 422 > ++ > drivers/scsi/ufs/ufshcd.h| 206 +++ > drivers/scsi/ufs/ufshcd_common.h | 53 + > 7 files changed, 813 insertions(+), 357 deletions(-) Two minor observations.. 1) If both pci and platform have to do the exact same thing in their _suspend() and _resume() routines, perhaps there is scope for making them as common (the steps outlined in them should be done in core ufshcd) ? 2) Need to include ufshcd_common.h in ufshcd.c so that the prototypes are supplied for the exported functions. -- 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] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
On 07/26/12 09:21, James Bottomley wrote:
> On Thu, 2012-07-26 at 11:04 +0200, Paolo Bonzini wrote:
>> Il 26/07/2012 10:52, James Bottomley ha scritto:
> +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
> +{
> + unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
> + return lun & 16383;
> +}
> +
>>> Why are you rolling your own incomplete version of scsilun_to_int here?
>>
>> Because scsilun_to_int does not do the AND, so it would have exactly the
>> same bug I'm fixing.
>
> It's not a bug ... it's the encoding. All the other devices use this
> too. Ideally we should have switched to 64 bit lun numbers for the
> encoding to be exact, but nothing so far has gone over 32 bits. If we
> don't encode the Address method as part of the lun number, we don't get
> the reverse transform right and the addressing often fails.
>
> That does mean that arrays that use address method=1 in REPORT LUNS have
> their lun numbers start at 16384.
Has it already been considered to modify scsilun_to_int() such that LUN
numbers start at zero even for addressing method 1 ? This is what e.g.
the function scst_unpack_lun() already does. See also
http://scst.svn.sourceforge.net/viewvc/scst/trunk/scst/src/scst_lib.c?revision=HEAD&view=markup.
Bart.
--
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 1/7] scsi: sr: check support for device busy class events
Signed-off-by: Aaron Lu
---
drivers/scsi/sr.c | 23 +++
drivers/scsi/sr.h | 1 +
include/linux/cdrom.h | 43 +++
3 files changed, 67 insertions(+)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 5fc97d2..abfefab 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -101,6 +101,7 @@ static DEFINE_MUTEX(sr_ref_mutex);
static int sr_open(struct cdrom_device_info *, int);
static void sr_release(struct cdrom_device_info *);
+static void check_dbml(struct scsi_cd *);
static void get_sectorsize(struct scsi_cd *);
static void get_capabilities(struct scsi_cd *);
@@ -728,6 +729,28 @@ fail:
return error;
}
+static void check_dbml(struct scsi_cd *cd)
+{
+ struct packet_command cgc;
+ unsigned char buffer[16];
+ struct rm_feature_desc *rfd;
+
+ init_cdrom_command(&cgc, buffer, sizeof(buffer), CGC_DATA_READ);
+ cgc.cmd[0] = GPCMD_GET_CONFIGURATION;
+ cgc.cmd[3] = CDF_RM;
+ cgc.cmd[8] = sizeof(buffer);
+ cgc.quiet = 1;
+
+ if (cd->cdi.ops->generic_packet(&cd->cdi, &cgc))
+ return;
+
+ rfd = (struct rm_feature_desc *)&buffer[sizeof(struct feature_header)];
+ if (be16_to_cpu(rfd->feature_code) != CDF_RM)
+ return;
+
+ if (rfd->dbml)
+ cd->dbml = 1;
+}
static void get_sectorsize(struct scsi_cd *cd)
{
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index 37c8f6b..7cc40ad 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -41,6 +41,7 @@ typedef struct scsi_cd {
unsigned readcd_known:1;/* drive supports READ_CD (0xbe) */
unsigned readcd_cdda:1; /* reading audio data using READ_CD */
unsigned media_present:1; /* media is present */
+ unsigned dbml:1;/* generates device busy class events */
/* GET_EVENT spurious event handling, blk layer guarantees exclusion */
int tur_mismatch; /* nr of get_event TUR mismatches */
diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
index dfd7f18..962be39 100644
--- a/include/linux/cdrom.h
+++ b/include/linux/cdrom.h
@@ -727,6 +727,7 @@ struct request_sense {
/*
* feature profile
*/
+#define CDF_RM 0x0003 /* "Removable Medium" */
#define CDF_RWRT 0x0020 /* "Random Writable" */
#define CDF_HWDM 0x0024 /* "Hardware Defect Management" */
#define CDF_MRW0x0028
@@ -739,6 +740,48 @@ struct request_sense {
#define CDM_MRW_BGFORMAT_ACTIVE2
#define CDM_MRW_BGFORMAT_COMPLETE 3
+/* Removable medium feature descriptor */
+struct rm_feature_desc {
+ __be16 feature_code;
+#if defined(__BIG_ENDIAN_BITFIELD)
+ __u8 reserved1 : 2;
+ __u8 feature_version: 4;
+ __u8 persistent : 1;
+ __u8 curr : 1;
+#elif defined(__LITTLE_ENDIAN_BITFIELD)
+ __u8 curr : 1;
+ __u8 persistent : 1;
+ __u8 feature_version: 4;
+ __u8 reserved1 : 2;
+#endif
+ __u8 add_len;
+#if defined(__BIG_ENDIAN_BITFIELD)
+ __u8 mech_type : 3;
+ __u8 load : 1;
+ __u8 eject : 1;
+ __u8 pvnt_jmpr : 1;
+ __u8 dbml : 1;
+ __u8 lock : 1;
+#elif defined(__LITTLE_ENDIAN_BITFIELD)
+ __u8 lock : 1;
+ __u8 dbml : 1;
+ __u8 pvnt_jmpr : 1;
+ __u8 eject : 1;
+ __u8 load : 1;
+ __u8 mech_type : 3;
+#endif
+ __u8 reserved2;
+ __u8 reserved3;
+ __u8 reserved4;
+};
+
+struct device_busy_event_desc {
+ __u8 device_busy_event : 4;
+ __u8 reserved1 : 4;
+ __u8 device_busy_status;
+ __u8 time;
+};
+
/*
* mrw address spaces
*/
--
1.7.11.3
--
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 2/7] scsi: pm: use autosuspend if device supports it
If the device is using autosuspend, when scsi_autopm_put_device is
called for it, use autosuspend runtime pm calls instead of the sync
call.
Signed-off-by: Aaron Lu
---
drivers/scsi/scsi_pm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index dc0ad85..7c93723 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -197,7 +197,13 @@ EXPORT_SYMBOL_GPL(scsi_autopm_get_device);
void scsi_autopm_put_device(struct scsi_device *sdev)
{
- pm_runtime_put_sync(&sdev->sdev_gendev);
+ if (sdev->sdev_gendev.power.use_autosuspend) {
+ pm_runtime_mark_last_busy(&sdev->sdev_gendev);
+ pm_runtime_put_autosuspend(&sdev->sdev_gendev);
+ } else {
+ pm_runtime_put_sync(&sdev->sdev_gendev);
+ }
+
}
EXPORT_SYMBOL_GPL(scsi_autopm_put_device);
--
1.7.11.3
--
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 0/7] ZPODD patches for scsi tree
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: use autosuspend if device supports it 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/scsi/scsi_pm.c | 23 -- drivers/scsi/sr.c | 176 - drivers/scsi/sr.h | 3 + include/linux/cdrom.h | 43 +++ include/linux/genhd.h | 1 + include/scsi/scsi_device.h | 2 + 7 files changed, 260 insertions(+), 13 deletions(-) -- 1.7.11.3 -- 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 3/7] scsi: sr: support zero power ODD(ZPODD)
The ODD will be placed into suspend state when:
1 For tray type ODD, no media inside and door closed;
2 For slot type ODD, no media inside;
And together with ACPI, when we suspend the ODD, we will omit the power
altogether to reduce power consumption(done in libata-acpi.c).
The ODD can be resumed either by user or by software.
For user to resume the suspended ODD:
1 For tray type ODD, press the eject button;
2 For slot type ODD, insert a disc;
Once such events happened, an ACPI notification will be sent and in our
handler, we will power up the ODD and set its status back to
active(again in libata-acpi.c).
For software to resume the suspended ODD, we did this in ODD's
open/release function: we scsi_autopm_get/put_device in scsi_cd_get/put.
On old distros, the udisk daemon will poll the ODD and thus ODD will be
open/closed every 2 seconds. To make use of ZPODD, udisks' poll has to
be inhibited:
$ udisks --inhibit-polling /dev/sr0
Signed-off-by: Aaron Lu
---
drivers/scsi/sr.c | 130 -
drivers/scsi/sr.h | 2 +
include/scsi/scsi_device.h | 2 +
3 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index abfefab..2573a42 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -79,6 +80,8 @@ static DEFINE_MUTEX(sr_mutex);
static int sr_probe(struct device *);
static int sr_remove(struct device *);
static int sr_done(struct scsi_cmnd *);
+static int sr_suspend(struct device *dev, pm_message_t msg);
+static int sr_resume(struct device *dev);
static struct scsi_driver sr_template = {
.owner = THIS_MODULE,
@@ -86,6 +89,8 @@ static struct scsi_driver sr_template = {
.name = "sr",
.probe = sr_probe,
.remove = sr_remove,
+ .suspend= sr_suspend,
+ .resume = sr_resume,
},
.done = sr_done,
};
@@ -147,8 +152,12 @@ static inline struct scsi_cd *scsi_cd_get(struct gendisk
*disk)
kref_get(&cd->kref);
if (scsi_device_get(cd->device))
goto out_put;
+ if (scsi_autopm_get_device(cd->device))
+ goto out_pm;
goto out;
+ out_pm:
+ scsi_device_put(cd->device);
out_put:
kref_put(&cd->kref, sr_kref_release);
cd = NULL;
@@ -164,9 +173,61 @@ static void scsi_cd_put(struct scsi_cd *cd)
mutex_lock(&sr_ref_mutex);
kref_put(&cd->kref, sr_kref_release);
scsi_device_put(sdev);
+ scsi_autopm_put_device(sdev);
mutex_unlock(&sr_ref_mutex);
}
+static int sr_suspend(struct device *dev, pm_message_t msg)
+{
+ int poweroff;
+ struct scsi_sense_hdr sshdr;
+ struct scsi_cd *cd = dev_get_drvdata(dev);
+
+ /* no action for system pm */
+ if (!PMSG_IS_AUTO(msg))
+ return 0;
+
+ /* do another TUR to see if the ODD is still ready to be powered off */
+ scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr);
+
+ if (cd->cdi.mask & CDC_CLOSE_TRAY)
+ /* no media for caddy/slot type ODD */
+ poweroff = scsi_sense_valid(&sshdr) && sshdr.asc == 0x3a;
+ else
+ /* no media and door closed for tray type ODD */
+ poweroff = scsi_sense_valid(&sshdr) && sshdr.asc == 0x3a &&
+ sshdr.ascq == 0x01;
+
+ if (!poweroff) {
+ pm_runtime_get_noresume(dev);
+ atomic_set(&cd->suspend_count, 1);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static int sr_resume(struct device *dev)
+{
+ struct scsi_cd *cd;
+ struct scsi_sense_hdr sshdr;
+
+ cd = dev_get_drvdata(dev);
+
+ /* get the disk ready */
+ scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr);
+
+ /* if user wakes up the ODD, eject the tray */
+ if (cd->device->wakeup_by_user) {
+ cd->device->wakeup_by_user = 0;
+ if (!(cd->cdi.mask & CDC_CLOSE_TRAY))
+ sr_tray_move(&cd->cdi, 1);
+ atomic_set(&cd->suspend_count, 1);
+ }
+
+ return 0;
+}
+
static unsigned int sr_get_events(struct scsi_device *sdev)
{
u8 buf[8];
@@ -201,6 +262,38 @@ static unsigned int sr_get_events(struct scsi_device *sdev)
return 0;
}
+static int sr_unit_load_done(struct scsi_cd *cd)
+{
+ u8 buf[8];
+ u8 cmd[] = { GET_EVENT_STATUS_NOTIFICATION,
+ 1, /* polled */
+ 0, 0, /* reserved */
+ 1 << 6,/* notification class: Device Busy */
+ 0, 0, /* reserved */
+ 0, sizeof(buf),/* allocation length */
+ 0, /* control */
+ };
[PATCH v3 4/7] scsi: sr: block events when runtime suspended
When the ODD is runtime suspended, there is no need to poll it for
events, so block events poll for it and unblock when resumed.
Signed-off-by: Aaron Lu
---
block/genhd.c | 2 ++
drivers/scsi/sr.c | 7 ---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index 9cf5583..bdb3682 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1458,6 +1458,7 @@ void disk_block_events(struct gendisk *disk)
mutex_unlock(&ev->block_mutex);
}
+EXPORT_SYMBOL(disk_block_events);
static void __disk_unblock_events(struct gendisk *disk, bool check_now)
{
@@ -1502,6 +1503,7 @@ void disk_unblock_events(struct gendisk *disk)
if (disk->ev)
__disk_unblock_events(disk, false);
}
+EXPORT_SYMBOL(disk_unblock_events);
/**
* disk_flush_events - schedule immediate event checking and flushing
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 2573a42..fd1c2f6 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -204,6 +204,8 @@ static int sr_suspend(struct device *dev, pm_message_t msg)
return -EBUSY;
}
+ disk_block_events(cd->disk);
+
return 0;
}
@@ -225,6 +227,8 @@ static int sr_resume(struct device *dev)
atomic_set(&cd->suspend_count, 1);
}
+ disk_unblock_events(cd->disk);
+
return 0;
}
@@ -314,9 +318,6 @@ static unsigned int sr_check_events(struct
cdrom_device_info *cdi,
if (CDSL_CURRENT != slot)
return 0;
- if (pm_runtime_suspended(&cd->device->sdev_gendev))
- return 0;
-
/* if the logical unit just finished loading/unloading, do a TUR */
if (cd->device->can_power_off && cd->dbml && sr_unit_load_done(cd)) {
events = 0;
--
1.7.11.3
--
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 7/7] block: genhd: add an interface to set disk's poll interval
Set the ODD's in kernel poll interval to 2s for the user in case the
user is using an old distro on which udev will not set the system wide
block parameter events_dfl_poll_msecs.
Signed-off-by: Aaron Lu
---
block/genhd.c | 23 +--
drivers/scsi/sr.c | 1 +
include/linux/genhd.h | 1 +
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/block/genhd.c b/block/genhd.c
index bdb3682..de9b9d9 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1619,6 +1619,19 @@ static void disk_events_workfn(struct work_struct *work)
kobject_uevent_env(&disk_to_dev(disk)->kobj, KOBJ_CHANGE, envp);
}
+int disk_events_set_poll_msecs(struct gendisk *disk, long intv)
+{
+ if (intv < 0 && intv != -1)
+ return -EINVAL;
+
+ disk_block_events(disk);
+ disk->ev->poll_msecs = intv;
+ __disk_unblock_events(disk, true);
+
+ return 0;
+}
+EXPORT_SYMBOL(disk_events_set_poll_msecs);
+
/*
* A disk events enabled device has the following sysfs nodes under
* its /sys/block/X/ directory.
@@ -1675,16 +1688,14 @@ static ssize_t disk_events_poll_msecs_store(struct
device *dev,
{
struct gendisk *disk = dev_to_disk(dev);
long intv;
+ int ret;
if (!count || !sscanf(buf, "%ld", &intv))
return -EINVAL;
- if (intv < 0 && intv != -1)
- return -EINVAL;
-
- disk_block_events(disk);
- disk->ev->poll_msecs = intv;
- __disk_unblock_events(disk, true);
+ ret = disk_events_set_poll_msecs(disk, intv);
+ if (ret)
+ return ret;
return count;
}
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index b8c2f9d..d639bcc 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -862,6 +862,7 @@ static int sr_probe(struct device *dev)
dev_set_drvdata(dev, cd);
disk->flags |= GENHD_FL_REMOVABLE;
add_disk(disk);
+ disk_events_set_poll_msecs(disk, 2000);
sdev_printk(KERN_DEBUG, sdev,
"Attached scsi CD-ROM %s\n", cd->cdi.name);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 017a7fb..7414fb5 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -418,6 +418,7 @@ extern void disk_block_events(struct gendisk *disk);
extern void disk_unblock_events(struct gendisk *disk);
extern void disk_flush_events(struct gendisk *disk, unsigned int mask);
extern unsigned int disk_clear_events(struct gendisk *disk, unsigned int mask);
+extern int disk_events_set_poll_msecs(struct gendisk *disk, long intv);
/* drivers/char/random.c */
extern void add_disk_randomness(struct gendisk *disk);
--
1.7.11.3
--
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 6/7] scsi: sr: balance sr disk events block depth
When the ODD is resumed, disk_unblock_events should be called when:
1 The ODD is runtime resumed;
2 System is resuming from S3 and the ODD is runtime suspended before S3;
But not when the system is resuming from S3 and the ODD is runtime
active before S3.
So seperate the resume calls, one for system resume and one for runtime
resume to do different things accordingly.
Signed-off-by: Aaron Lu
---
drivers/scsi/sr.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index fd1c2f6..b8c2f9d 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -82,6 +82,11 @@ static int sr_remove(struct device *);
static int sr_done(struct scsi_cmnd *);
static int sr_suspend(struct device *dev, pm_message_t msg);
static int sr_resume(struct device *dev);
+static int sr_runtime_resume(struct device *dev);
+
+static struct dev_pm_ops sr_pm_ops = {
+ .runtime_resume = sr_runtime_resume,
+};
static struct scsi_driver sr_template = {
.owner = THIS_MODULE,
@@ -91,6 +96,7 @@ static struct scsi_driver sr_template = {
.remove = sr_remove,
.suspend= sr_suspend,
.resume = sr_resume,
+ .pm = &sr_pm_ops,
},
.done = sr_done,
};
@@ -211,6 +217,21 @@ static int sr_suspend(struct device *dev, pm_message_t msg)
static int sr_resume(struct device *dev)
{
+ struct scsi_cd *cd = dev_get_drvdata(dev);
+
+ /*
+* If ODD is runtime suspended before system pm, unblock disk
+* events now since on system resume, we will fully resume it
+* and set its rumtime status to active.
+*/
+ if (pm_runtime_suspended(dev))
+ disk_unblock_events(cd->disk);
+
+ return 0;
+}
+
+static int sr_runtime_resume(struct device *dev)
+{
struct scsi_cd *cd;
struct scsi_sense_hdr sshdr;
--
1.7.11.3
--
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 5/7] scsi: pm: use runtime resume callback if available
When runtime resume a scsi device, if the device's driver has
implemented runtime resume callback, use that.
sr driver needs this to do different things for system resume and
runtime resume.
Signed-off-by: Aaron Lu
---
drivers/scsi/scsi_pm.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 7c93723..65d723d 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -34,14 +34,19 @@ static int scsi_dev_type_suspend(struct device *dev,
pm_message_t msg)
return err;
}
-static int scsi_dev_type_resume(struct device *dev)
+static int scsi_dev_type_resume(struct device *dev, bool runtime)
{
struct device_driver *drv;
int err = 0;
+ int (*resume)(struct device *);
drv = dev->driver;
- if (drv && drv->resume)
- err = drv->resume(dev);
+ if (runtime && drv && drv->pm && drv->pm->runtime_resume)
+ resume = drv->pm->runtime_resume;
+ else
+ resume = drv ? drv->resume : NULL;
+ if (resume)
+ err = resume(dev);
scsi_device_resume(to_scsi_device(dev));
dev_dbg(dev, "scsi resume: %d\n", err);
return err;
@@ -85,7 +90,7 @@ static int scsi_bus_resume_common(struct device *dev)
pm_runtime_get_sync(dev->parent);
if (scsi_is_sdev_device(dev))
- err = scsi_dev_type_resume(dev);
+ err = scsi_dev_type_resume(dev, false);
if (err == 0) {
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
@@ -160,7 +165,7 @@ static int scsi_runtime_resume(struct device *dev)
dev_dbg(dev, "scsi_runtime_resume\n");
if (scsi_is_sdev_device(dev))
- err = scsi_dev_type_resume(dev);
+ err = scsi_dev_type_resume(dev, true);
/* Insert hooks here for targets, hosts, and transport classes */
--
1.7.11.3
--
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] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
Il 26/07/2012 11:41, James Bottomley ha scritto: > On Thu, 2012-07-26 at 11:27 +0200, Paolo Bonzini wrote: >> Il 26/07/2012 11:21, James Bottomley ha scritto: > Because scsilun_to_int does not do the AND, so it would have exactly the > same bug I'm fixing. >>> It's not a bug ... it's the encoding. All the other devices use this >>> too. Ideally we should have switched to 64 bit lun numbers for the >>> encoding to be exact, but nothing so far has gone over 32 bits. If we >>> don't encode the Address method as part of the lun number, we don't get >>> the reverse transform right and the addressing often fails. >> >> But virtio-scsi gets it right even if you use method=0 and method=1 >> interchangeably. > > I don't actually understand this statement. LUNS < 256 may be encoded > either way (they should be encoded with address method=0 but they don't > have to be) if you address the array with the wrong method, it doesn't > have to give you your lun. But virtio-scsi does, LUN "16384" and LUN 0 are the same. If somebody wanted to add support for >16383 LUNs, we would do it with the 4-byte encoding that is in SAM, but I don't see that happening. > It's nothing to do with buggy hardware ... Hardware that knows about format=1 LUNs, and yet treats LUN 0 differently depending on the encoding sounds buggy. Of course some hardware may not know anything about format=1, so it is wrong to pass format=1 unconditionally, but virtio-scsi does. 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 1/2] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
On Thu, 2012-07-26 at 11:27 +0200, Paolo Bonzini wrote: > Il 26/07/2012 11:21, James Bottomley ha scritto: > >> > Because scsilun_to_int does not do the AND, so it would have exactly the > >> > same bug I'm fixing. > > It's not a bug ... it's the encoding. All the other devices use this > > too. Ideally we should have switched to 64 bit lun numbers for the > > encoding to be exact, but nothing so far has gone over 32 bits. If we > > don't encode the Address method as part of the lun number, we don't get > > the reverse transform right and the addressing often fails. > > But virtio-scsi gets it right even if you use method=0 and method=1 > interchangeably. I don't actually understand this statement. LUNS < 256 may be encoded either way (they should be encoded with address method=0 but they don't have to be) if you address the array with the wrong method, it doesn't have to give you your lun. Therefore we have to map back to whatever the array gave us. Hence the 1:1 mapping. You're proposing an injective mapping, so you can't reliably reverse it; that's why we don't do it that way in SCSI. > ibmvscsi (see function lun_from_dev) does something similar to > virtio-scsi, except here I need both directions. > > > That does mean that arrays that use address method=1 in REPORT LUNS have > > their lun numbers start at 16384. > > That is ugly. I can see how it may be needed on buggy hardware, but > here we know it's not. It's nothing to do with buggy hardware ... it's to do with having an exact representation of the lun. James -- 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] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
Il 26/07/2012 11:21, James Bottomley ha scritto: >> > Because scsilun_to_int does not do the AND, so it would have exactly the >> > same bug I'm fixing. > It's not a bug ... it's the encoding. All the other devices use this > too. Ideally we should have switched to 64 bit lun numbers for the > encoding to be exact, but nothing so far has gone over 32 bits. If we > don't encode the Address method as part of the lun number, we don't get > the reverse transform right and the addressing often fails. But virtio-scsi gets it right even if you use method=0 and method=1 interchangeably. ibmvscsi (see function lun_from_dev) does something similar to virtio-scsi, except here I need both directions. > That does mean that arrays that use address method=1 in REPORT LUNS have > their lun numbers start at 16384. That is ugly. I can see how it may be needed on buggy hardware, but here we know it's not. 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 1/2] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
On Thu, 2012-07-26 at 11:04 +0200, Paolo Bonzini wrote:
> Il 26/07/2012 10:52, James Bottomley ha scritto:
> >> > +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
> >> > +{
> >> > +unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
> >> > +return lun & 16383;
> >> > +}
> >> > +
> > Why are you rolling your own incomplete version of scsilun_to_int here?
>
> Because scsilun_to_int does not do the AND, so it would have exactly the
> same bug I'm fixing.
It's not a bug ... it's the encoding. All the other devices use this
too. Ideally we should have switched to 64 bit lun numbers for the
encoding to be exact, but nothing so far has gone over 32 bits. If we
don't encode the Address method as part of the lun number, we don't get
the reverse transform right and the addressing often fails.
That does mean that arrays that use address method=1 in REPORT LUNS have
their lun numbers start at 16384.
James
--
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 v2] scsi: virtio-scsi: Fix address translation failure of HighMem pages used by sg list
2012/7/25 Ben Hutchings : > On Wed, 2012-07-25 at 20:13 +0800, Wang Sen wrote: >> 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. >> >> I take Paolo's solution mentioned in last thread to avoid failure on handling >> flag bits. >> >> I have tested the patch on my workstation. QEMU would not crash any more. >> >> Signed-off-by: Wang Sen > [...] > > This is not the correct way to submit a change for stable. See > Documentation/stable_kernel_rules.txt. OK, thanks. > > Ben. > > -- > Ben Hutchings > If more than one person is responsible for a bug, no one is at fault. -- -- Wang Sen Addr: XUPT,Xi'an,Shaanxi,China Email: kelvin.x...@gmail.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
Re: [PATCH 1/2] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
Il 26/07/2012 10:52, James Bottomley ha scritto:
>> > +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
>> > +{
>> > + unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
>> > + return lun & 16383;
>> > +}
>> > +
> Why are you rolling your own incomplete version of scsilun_to_int here?
Because scsilun_to_int does not do the AND, so it would have exactly the
same bug I'm fixing.
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] tcm_vhost: Expose ABI version via VHOST_SCSI_GET_ABI_VERSION
On 07/26/2012 05:34 AM, Nicholas A. Bellinger wrote: > > In that case, respinning a -v5 for tcm_vhost to start from ABI=0 and > will post an updated patch shortly. > >> The main thing I would like to confirm is that this only versions the >> tcm_vhost ioctls? In that case a single version number works. >> > > Correct, the GET_ABI_VERSION call is only intended to identify the > changing of tcm_vhost ioctls. Why use version numbers at all? Feature maps are better, because you can get very fine granularity. -- error compiling committee.c: too many arguments to function -- 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] virtio-scsi: fix parsing of hotplug/hot-unplug LUN number
On Mon, 2012-07-16 at 18:05 +0200, Paolo Bonzini wrote:
> Hotplug/hot-unplug of a LUN whose number is greater than 255
> uses the "flat" format for LUNs, which has bit 14 set. Clear
> the bit when parsing the event structs.
>
> Signed-off-by: Paolo Bonzini
> ---
> drivers/scsi/virtio_scsi.c |8 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index c7030fb..c937232 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -252,13 +252,19 @@ static void virtscsi_cancel_event_work(struct
> virtio_scsi *vscsi)
> cancel_work_sync(&vscsi->event_list[i].work);
> }
>
> +static unsigned int virtscsi_get_lun(u8 *lun_bytes)
> +{
> + unsigned int lun = (lun_bytes[2] << 8) | lun_bytes[3];
> + return lun & 16383;
> +}
> +
Why are you rolling your own incomplete version of scsilun_to_int here?
James
--
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 4/4] [SCSI] ufs: Correct the expected data transfer size
This patch corrects the expected data transfer size of the command UPIU. The current implementation of cmd->transfersize is wrong as it probably equal to sector size. With this implementation the transfer size is updated correctly Reported-by: KOBAYASHI Yoshitake Reviewed-by: Namjae Jeon Signed-off-by: Santosh Yaraganavi Signed-off-by: Vinayak Holikatti --- drivers/scsi/ufs/ufshcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index dfc3e85..5e732c3 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -488,7 +488,7 @@ static void ufshcd_compose_upiu(struct ufshcd_lrb *lrbp) ucd_cmd_ptr->header.dword_2 = 0; ucd_cmd_ptr->exp_data_transfer_len = - cpu_to_be32(lrbp->cmd->transfersize); + cpu_to_be32(lrbp->cmd->sdb.length); memcpy(ucd_cmd_ptr->cdb, lrbp->cmd->cmnd, -- 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
[PATCH V3 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
This patch adds Platform glue driver for ufshcd.
Reviewed-by: Namjae Jeon
Signed-off-by: Vinayak Holikatti
Signed-off-by: Santosh Yaraganavi
---
drivers/scsi/ufs/Kconfig | 11 ++
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufshcd-pltfrm.c | 222 ++
3 files changed, 234 insertions(+)
create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 265a8c8..8c06330 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -67,3 +67,14 @@ config SCSI_UFSHCD_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config SCSI_UFSHCD_PLATFORM
+ tristate "Platform based UFS Controller support"
+ depends on SCSI_UFSHCD
+ ---help---
+ This selects the UFS host controller support. If you have a
+ platform with UFS controller, say Y or M here.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9eda0df..1e5bd48 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,3 +1,4 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
+obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
new file mode 100644
index 000..68e1675
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -0,0 +1,222 @@
+/*
+ * Universal Flash Storage Host controller driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd-pltfm.c
+ * Copyright (C) 2011-2012 Samsung India Software Operations
+ *
+ * Santosh Yaraganavi
+ * Vinayak Holikatti
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NO WARRANTY
+ * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
+ * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
+ * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
+ * solely responsible for determining the appropriateness of using and
+ * distributing the Program and assumes all risks associated with its
+ * exercise of rights under this Agreement, including but not limited to
+ * the risks and costs of program errors, damage to or loss of data,
+ * programs or equipment, and unavailability or interruption of operations.
+
+ * DISCLAIMER OF LIABILITY
+ * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+ * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
+ * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
+ * USA.
+ */
+
+#include "ufshcd.h"
+#include "ufshcd_common.h"
+#include
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_pltfrm_suspend - suspend power management function
+ * @pdev: pointer to Platform device handle
+ * @mesg: power state
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pltfrm_suspend(struct platform_device *pdev,
+pm_message_t mesg)
+{
+ /*
+* TODO:
+* 1. Block SCSI requests from SCSI midlayer
+* 2. Change the internal driver state to non operational
+* 3. Set UTRLRSR and UTMRLRSR bits to zero
+* 4. Wait until outstanding commands are completed
+* 5. Set HCE to zero to send the UFS host controller to reset state
+*/
+
+ return -ENOSYS;
+}
+
+/**
+ * ufshcd_pltfrm_resume - resume power management function
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns -ENOSYS
+ */
+static int ufshcd_pltfrm_resume(struct platform_device *pdev)
+{
+ /*
+* TODO:
+* 1. Set HCE to 1, to start the UFS host controller
+* initialization process
+* 2. Set UTRLRSR and UTMRLRSR bits to 1
+* 3. Change the internal driver state to operational
+*
[PATCH V3 2/4] [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver
This patch separates PCI code from ufshcd.c and makes it as a core driver module and adds a new file ufshcd-pci.c as PCI glue driver. Reviewed-by: Namjae Jeon Signed-off-by: Vinayak Holikatti Signed-off-by: Santosh Yaraganavi --- drivers/scsi/ufs/Kconfig | 26 ++- drivers/scsi/ufs/Makefile|1 + drivers/scsi/ufs/ufshcd-pci.c| 228 ++ drivers/scsi/ufs/ufshcd.c| 329 ++ drivers/scsi/ufs/ufshcd.h| 206 drivers/scsi/ufs/ufshcd_common.h | 53 ++ 6 files changed, 521 insertions(+), 322 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pci.c create mode 100644 drivers/scsi/ufs/ufshcd.h create mode 100644 drivers/scsi/ufs/ufshcd_common.h diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index 8f27f9d..265a8c8 100644 --- a/drivers/scsi/ufs/Kconfig +++ b/drivers/scsi/ufs/Kconfig @@ -43,7 +43,27 @@ # USA. config SCSI_UFSHCD - tristate "Universal Flash Storage host controller driver" - depends on PCI && SCSI + tristate "Universal Flash Storage Controller Driver Core" + depends on SCSI ---help--- - This is a generic driver which supports PCIe UFS Host controllers. + This selects the support for UFS devices in Linux, say Y and make + sure that you know the name of your UFS host adapter (the card + inside your computer that "speaks" the UFS protocol, also + called UFS Host Controller), because you will be asked for it. + The module will be called ufshcd. + + To compile this driver as a module, choose M here and read + . + However, do not compile this as a module if your root file system + (the one containing the directory /) is located on a UFS device. + +config SCSI_UFSHCD_PCI + tristate "PCI bus based UFS Controller support" + depends on SCSI_UFSHCD && PCI + ---help--- + This selects the PCI UFS Host Controller Interface. + Most controllers found today are PCI devices. + + If you have a controller with this interface, say Y or M here. + + If unsure, say N. diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile index adf7895..9eda0df 100644 --- a/drivers/scsi/ufs/Makefile +++ b/drivers/scsi/ufs/Makefile @@ -1,2 +1,3 @@ # UFSHCD makefile obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o +obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c new file mode 100644 index 000..d078744 --- /dev/null +++ b/drivers/scsi/ufs/ufshcd-pci.c @@ -0,0 +1,228 @@ +/* + * Universal Flash Storage Host controller driver + * + * This code is based on drivers/scsi/ufs/ufshcd-pci.c + * Copyright (C) 2011-2012 Samsung India Software Operations + * + * Santosh Yaraganavi + * Vinayak Holikatti + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * NO WARRANTY + * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR + * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT + * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is + * solely responsible for determining the appropriateness of using and + * distributing the Program and assumes all risks associated with its + * exercise of rights under this Agreement, including but not limited to + * the risks and costs of program errors, damage to or loss of data, + * programs or equipment, and unavailability or interruption of operations. + + * DISCLAIMER OF LIABILITY + * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR + * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE + * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED + * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES + + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, + * USA. + */ + +#include "ufshcd.h" +#include "ufshcd_common.h" +#include + +#ifdef CONFIG_PM +/** + * ufshcd_pci_suspend - suspend power management
[PATCH V3 1/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
This patch seggregates the PCI specific code in ufshcd.c to make it
ready for splitting into core ufs driver and PCI glue driver.
Reviewed-by: Namjae Jeon
Signed-off-by: Vinayak Holikatti
Signed-off-by: Santosh Yaraganavi
---
drivers/scsi/ufs/ufshcd.c | 277 -
1 file changed, 150 insertions(+), 127 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6a4fd00..c7b8f4b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -129,7 +129,7 @@ struct uic_command {
* @utrdl_dma_addr: UTRDL DMA address
* @utmrdl_dma_addr: UTMRDL DMA address
* @host: Scsi_Host instance of the driver
- * @pdev: PCI device handle
+ * @dev: device handle
* @lrb: local reference block
* @outstanding_tasks: Bits representing outstanding task requests
* @outstanding_reqs: Bits representing outstanding transfer requests
@@ -159,7 +159,7 @@ struct ufs_hba {
dma_addr_t utmrdl_dma_addr;
struct Scsi_Host *host;
- struct pci_dev *pdev;
+ struct device *dev;
struct ufshcd_lrb *lrb;
@@ -335,21 +335,21 @@ static inline void ufshcd_free_hba_memory(struct ufs_hba
*hba)
if (hba->utmrdl_base_addr) {
utmrdl_size = sizeof(struct utp_task_req_desc) * hba->nutmrs;
- dma_free_coherent(&hba->pdev->dev, utmrdl_size,
+ dma_free_coherent(hba->dev, utmrdl_size,
hba->utmrdl_base_addr, hba->utmrdl_dma_addr);
}
if (hba->utrdl_base_addr) {
utrdl_size =
(sizeof(struct utp_transfer_req_desc) * hba->nutrs);
- dma_free_coherent(&hba->pdev->dev, utrdl_size,
+ dma_free_coherent(hba->dev, utrdl_size,
hba->utrdl_base_addr, hba->utrdl_dma_addr);
}
if (hba->ucdl_base_addr) {
ucdl_size =
(sizeof(struct utp_transfer_cmd_desc) * hba->nutrs);
- dma_free_coherent(&hba->pdev->dev, ucdl_size,
+ dma_free_coherent(hba->dev, ucdl_size,
hba->ucdl_base_addr, hba->ucdl_dma_addr);
}
}
@@ -724,7 +724,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
/* Allocate memory for UTP command descriptors */
ucdl_size = (sizeof(struct utp_transfer_cmd_desc) * hba->nutrs);
- hba->ucdl_base_addr = dma_alloc_coherent(&hba->pdev->dev,
+ hba->ucdl_base_addr = dma_alloc_coherent(hba->dev,
ucdl_size,
&hba->ucdl_dma_addr,
GFP_KERNEL);
@@ -737,7 +737,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
*/
if (!hba->ucdl_base_addr ||
WARN_ON(hba->ucdl_dma_addr & (PAGE_SIZE - 1))) {
- dev_err(&hba->pdev->dev,
+ dev_err(hba->dev,
"Command Descriptor Memory allocation failed\n");
goto out;
}
@@ -747,13 +747,13 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
* UFSHCI requires 1024 byte alignment of UTRD
*/
utrdl_size = (sizeof(struct utp_transfer_req_desc) * hba->nutrs);
- hba->utrdl_base_addr = dma_alloc_coherent(&hba->pdev->dev,
+ hba->utrdl_base_addr = dma_alloc_coherent(hba->dev,
utrdl_size,
&hba->utrdl_dma_addr,
GFP_KERNEL);
if (!hba->utrdl_base_addr ||
WARN_ON(hba->utrdl_dma_addr & (PAGE_SIZE - 1))) {
- dev_err(&hba->pdev->dev,
+ dev_err(hba->dev,
"Transfer Descriptor Memory allocation failed\n");
goto out;
}
@@ -763,13 +763,13 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
* UFSHCI requires 1024 byte alignment of UTMRD
*/
utmrdl_size = sizeof(struct utp_task_req_desc) * hba->nutmrs;
- hba->utmrdl_base_addr = dma_alloc_coherent(&hba->pdev->dev,
+ hba->utmrdl_base_addr = dma_alloc_coherent(hba->dev,
utmrdl_size,
&hba->utmrdl_dma_addr,
GFP_KERNEL);
if (!hba->utmrdl_base_addr ||
WARN_ON(hba->utmrdl_dma_addr & (PAGE_SIZE - 1))) {
- dev_err(&hba->pdev->dev,
+ dev_err(hba->dev,
"Task Management Descriptor Memory allocation failed\n");
goto out;
}
@@ -777,7 +777,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
/* Allocate memory for local reference block */
hba->lrb = kcalloc(hba->nutrs, sizeof(struct ufshcd_lrb), GFP_KERNEL);
if (!hba->lrb) {
-
[PATCH V3 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
This patch set adds following features - Seggregate PCI specific code in ufshcd.c - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module - Adds Platform glue driver ufshcd-pltfrm.c - Update correct transfer size in Command UPIU Vinayak Holikatti (4): [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver [SCSI] ufs: Add Platform glue driver for ufshcd [SCSI] ufs: Correct the expected data transfer size drivers/scsi/ufs/Kconfig | 37 +++- drivers/scsi/ufs/Makefile|2 + drivers/scsi/ufs/ufshcd-pci.c| 228 drivers/scsi/ufs/ufshcd-pltfrm.c | 222 drivers/scsi/ufs/ufshcd.c| 422 ++ drivers/scsi/ufs/ufshcd.h| 206 +++ drivers/scsi/ufs/ufshcd_common.h | 53 + 7 files changed, 813 insertions(+), 357 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pci.c create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c create mode 100644 drivers/scsi/ufs/ufshcd.h create mode 100644 drivers/scsi/ufs/ufshcd_common.h -- 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: [PATCH 4/5] megaraid_sas: Move poll_aen_lock initializer
On Tue, 2012-07-17 at 18:20 -0700, adam radford wrote: > Cc: stable That's not how to add a stable tag, please see Documentation/stable_kernel_rules.txt > James/linux-scsi, > > The following patch from Kashyap Desai for megaraid_sas moves the That's also not how you do someone else's patch ... this needs a From: Kashyap Desai At the top for git to get the authorship correct. James > poll_aen_lock initializer from megasas_probe_one() to megasas_init(). > This prevents a crash when a user loads the driver and tries to issue > a poll() system call on the ioctl interface with no adapters present. > > Signed-off-by: Kashyap Desai > Signed-off-by: Adam Radford > > diff -Naur scsi/drivers/scsi/megaraid/megaraid_sas_base.c > scsi.new/drivers/scsi/megaraid/megaraid_sas_base.c > --- scsi/drivers/scsi/megaraid/megaraid_sas_base.c2012-07-17 > 14:57:32.890231627 -0700 > +++ scsi.new/drivers/scsi/megaraid/megaraid_sas_base.c2012-07-17 > 14:59:37.285232167 -0700 > @@ -4095,7 +4095,6 @@ > spin_lock_init(&instance->cmd_pool_lock); > spin_lock_init(&instance->hba_lock); > spin_lock_init(&instance->completion_lock); > - spin_lock_init(&poll_aen_lock); > > mutex_init(&instance->aen_mutex); > mutex_init(&instance->reset_mutex); > @@ -5421,6 +5420,8 @@ > printk(KERN_INFO "megasas: %s %s\n", MEGASAS_VERSION, > MEGASAS_EXT_VERSION); > > + spin_lock_init(&poll_aen_lock); > + > support_poll_for_event = 2; > support_device_change = 1; -- 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 26/07/2012 09:56, Boaz Harrosh ha scritto: >> > In the meanwhile, we still have a bug to fix, and we need to choose >> > between Sen Wang's v1 (sg_set_page) or v2 (value assignment). I'm still >> > leaning more towards v2, if only because I already tested that one myself. > > It's your call, you know what I think ;-) > > I Agree none of them are bugs in current code, they will both work > just the same. Cool. Then, Sen, please fix the commit message in v2 and repost. > Please CC me on the "convert to sg copy-less" patches, It looks interesting Sure. 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: 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/26/2012 10:23 AM, Paolo Bonzini wrote: > > In the meanwhile, we still have a bug to fix, and we need to choose > between Sen Wang's v1 (sg_set_page) or v2 (value assignment). I'm still > leaning more towards v2, if only because I already tested that one myself. > It's your call, you know what I think ;-) I Agree none of them are bugs in current code, they will both work just the same. > Paolo Please CC me on the "convert to sg copy-less" patches, It looks interesting Thanks 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: [git patches] libata updates
* Linus Torvalds wrote: > I couldn't find an example of that in a quick look, it's > fairly uncommon to have non-conflicting merges that had > semantic - but not contextual - conflicts. [...] This: git log --grep='Semantic merge\|Semantic conflict' gives over a dozen examples of such semantic merges I've done in the past 4 years. I fully agree that they are best done in the merge commit - in hindsight perhaps with a tad more explanation than I did. Thanks, Ingo -- 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 25/07/2012 23:04, Boaz Harrosh ha scritto: >> That not all architectures have ARCH_HAS_SG_CHAIN (though all those I >> care about do). So I need to go through all architectures and make sure >> they use for_each_sg, or at least to change ARCH_HAS_SG_CHAIN to a >> Kconfig define so that dependencies can be expressed properly. > > What is actually preventing ARCH_HAS_SG_CHAIN from all these ARCHES? > is that the DMA drivers not using for_each_sg(). Sounds like easy > to fix. > > But yes a deep change would convert ARCH_HAS_SG_CHAIN to a Kconfig. > > If you want to be lazy, like me, You might just put a BUILD_BUG_ON > in code, requesting the user to disable the driver for this ARCH. > > I bet there is more things to do at ARCH to enable virtualization > then just support ARCH_HAS_SG_CHAIN. Be it just another requirement. Actually, many arches run just fine with QEMU's binary code translation (alpha, mips, coldfire). And since it's already pretty slow, using virtio to improve performance is nice even in that scenario (which does not require any kernel change). But it's just an icing on the cake indeed. I can live with a BUILD_BUG_ON or better a "depends on HAVE_SG_CHAIN" for the time being. >>> And BTW you won't need that new __sg_set_page API anymore. >> >> Kind of. >> >>sg_init_table(sg, 2); >>sg_set_buf(sg[0], req, sizeof(req)); >>sg_chain(sg[1], scsi_out(sc)); >> >> is still a little bit worse than >> >>__sg_set_buf(sg[0], req, sizeof(req)); >>__sg_chain(sg[1], scsi_out(sc)); > > > I believe they are the same, specially for the > on the stack 2 elements array. Actually I think > In both cases you need to at least call sg_init_table() > once after allocation, No? Because the scatterlist here would be allocated on the stack, I would need to call it every time if I used sg_set_buf/sg_chain. But sg_init_table is really just memset + set SG_MAGIC + sg_mark_end. If you use the "full-init" APIs as above, you don't need any of those (sg_chain undoes the flag changes in sg_mark_end and vice versa). > But please for my sake do not call it __sg_chain. Call it > something like sg_chain_not_end(). I hate those "__" which > for god sack means what? > (A good name is when I don't have to read the code, an "__" > means "fuck you go read the code") Right, better call them sg_init_buf/sg_init_page/sg_init_chain. In the meanwhile, we still have a bug to fix, and we need to choose between Sen Wang's v1 (sg_set_page) or v2 (value assignment). I'm still leaning more towards v2, if only because I already tested that one myself. 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
