Re: [PATCH v5 0/4] [SCSI] sg: fix race condition in sg_open
On 13-07-22 01:03 PM, Jörn Engel wrote: On Mon, 22 July 2013 12:40:29 +0800, Vaughan Cao wrote: There is a race when open sg with O_EXCL flag. Also a race may happen between sg_open and sg_remove. Changes from v4: * [3/4] use ERR_PTR series instead of adding another parameter in sg_add_sfp * [4/4] fix conflict for cherry-pick from v3. Changes from v3: * release o_sem in sg_release(), not in sg_remove_sfp(). * not set exclude with sfd_lock held. Vaughan Cao (4): [SCSI] sg: use rwsem to solve race during exclusive open [SCSI] sg: no need sg_open_exclusive_lock [SCSI] sg: checking sdp->detached isn't protected when open [SCSI] sg: push file descriptor list locking down to per-device locking drivers/scsi/sg.c | 178 +- 1 file changed, 83 insertions(+), 95 deletions(-) Patchset looks good to me, although I didn't test it on hardware yet. Signed-off-by: Joern Engel James, care to pick this up? Acked-by: Douglas Gilbert Tested O_EXCL with multiple processes and threads; passed. sg driver prior to this patch had "leaky" O_EXCL logic according to the same test. Block device passed. James, could you clean this up: drivers/scsi/sg.c:242:6: warning: unused variable ‘res’ [-Wunused-variable] Doug Gilbert -- 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] virtio-scsi: Fix virtqueue affinity setup
Asias He writes:
> vscsi->num_queues counts the number of request virtqueue which does not
> include the control and event virtqueue. It is wrong to subtract
> VIRTIO_SCSI_VQ_BASE from vscsi->num_queues.
>
> This patch fixes the following panic.
Applied.
Thanks,
Rusty.
>
> (qemu) device_del scsi0
>
> BUG: unable to handle kernel NULL pointer dereference at 0020
> IP: [] __virtscsi_set_affinity+0x6f/0x120
> PGD 0
> Oops: [#1] SMP
> Modules linked in:
> CPU: 0 PID: 659 Comm: kworker/0:1 Not tainted 3.11.0-rc2+ #1172
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> Workqueue: kacpi_hotplug _handle_hotplug_event_func
> task: 88007bee1cc0 ti: 88007bfe4000 task.ti: 88007bfe4000
> RIP: 0010:[] []
> __virtscsi_set_affinity+0x6f/0x120
> RSP: 0018:88007bfe5a38 EFLAGS: 00010202
> RAX: 0010 RBX: 880077fd0d28 RCX: 0050
> RDX: RSI: 0246 RDI:
> RBP: 88007bfe5a58 R08: 880077f6ff00 R09: 0001
> R10: 8143e673 R11: 0001 R12: 0001
> R13: 880077fd0800 R14: R15: 88007bf489b0
> FS: () GS:88007ea0() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 0020 CR3: 79f8b000 CR4: 06f0
> Stack:
> 880077fd0d28 880077fd0800 0008
> 88007bfe5a78 8179b37d 88007bccc800 88007bccc800
> 88007bfe5a98 8179b3b6 88007bccc800 880077fd0d28
> Call Trace:
> [] virtscsi_set_affinity+0x2d/0x40
> [] virtscsi_remove_vqs+0x26/0x50
> [] virtscsi_remove+0x82/0xa0
> [] virtio_dev_remove+0x22/0x70
> [] __device_release_driver+0x69/0xd0
> [] device_release_driver+0x2d/0x40
> [] bus_remove_device+0x116/0x150
> [] device_del+0x126/0x1e0
> [] device_unregister+0x16/0x30
> [] unregister_virtio_device+0x19/0x30
> [] virtio_pci_remove+0x36/0x80
> [] pci_device_remove+0x37/0x70
> [] __device_release_driver+0x69/0xd0
> [] device_release_driver+0x2d/0x40
> [] bus_remove_device+0x116/0x150
> [] device_del+0x126/0x1e0
> [] pci_stop_bus_device+0x9c/0xb0
> [] pci_stop_and_remove_bus_device+0x16/0x30
> [] acpiphp_disable_slot+0x8e/0x150
> [] hotplug_event_func+0xba/0x1a0
> [] ? acpi_os_release_object+0xe/0x12
> [] _handle_hotplug_event_func+0x31/0x70
> [] process_one_work+0x183/0x500
> [] worker_thread+0x122/0x400
> [] ? manage_workers+0x2d0/0x2d0
> [] kthread+0xce/0xe0
> [] ? kthread_freezable_should_stop+0x70/0x70
> [] ret_from_fork+0x7c/0xb0
> [] ? kthread_freezable_should_stop+0x70/0x70
> Code: 01 00 00 00 74 59 45 31 e4 83 bb c8 01 00 00 02 74 46 66 2e 0f 1f 84
> 00 00 00 00 00 49 63 c4 48 c1 e0 04 48 8b bc 0
> 3 10 02 00 00 <48> 8b 47 20 48 8b 80 d0 01 00 00 48 8b 40 50 48 85 c0 74 07 be
> RIP [] __virtscsi_set_affinity+0x6f/0x120
> RSP
> CR2: 0020
> ---[ end trace 99679331a3775f48 ]---
>
> CC: sta...@vger.kernel.org
> Signed-off-by: Asias He
> ---
> drivers/scsi/virtio_scsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 2168258..74b88ef 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -751,7 +751,7 @@ static void __virtscsi_set_affinity(struct virtio_scsi
> *vscsi, bool affinity)
>
> vscsi->affinity_hint_set = true;
> } else {
> - for (i = 0; i < vscsi->num_queues - VIRTIO_SCSI_VQ_BASE; i++)
> + for (i = 0; i < vscsi->num_queues; i++)
> virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
>
> vscsi->affinity_hint_set = false;
> --
> 1.8.3.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] virtio-scsi: Fix virtqueue affinity setup
On 07/31/2013 10:17 PM, Asias He wrote:
> vscsi->num_queues counts the number of request virtqueue which does not
> include the control and event virtqueue. It is wrong to subtract
> VIRTIO_SCSI_VQ_BASE from vscsi->num_queues.
>
> This patch fixes the following panic.
>
> (qemu) device_del scsi0
>
> BUG: unable to handle kernel NULL pointer dereference at 0020
> IP: [] __virtscsi_set_affinity+0x6f/0x120
> PGD 0
> Oops: [#1] SMP
> Modules linked in:
> CPU: 0 PID: 659 Comm: kworker/0:1 Not tainted 3.11.0-rc2+ #1172
> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> Workqueue: kacpi_hotplug _handle_hotplug_event_func
> task: 88007bee1cc0 ti: 88007bfe4000 task.ti: 88007bfe4000
> RIP: 0010:[] []
> __virtscsi_set_affinity+0x6f/0x120
> RSP: 0018:88007bfe5a38 EFLAGS: 00010202
> RAX: 0010 RBX: 880077fd0d28 RCX: 0050
> RDX: RSI: 0246 RDI:
> RBP: 88007bfe5a58 R08: 880077f6ff00 R09: 0001
> R10: 8143e673 R11: 0001 R12: 0001
> R13: 880077fd0800 R14: R15: 88007bf489b0
> FS: () GS:88007ea0() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 0020 CR3: 79f8b000 CR4: 06f0
> Stack:
> 880077fd0d28 880077fd0800 0008
> 88007bfe5a78 8179b37d 88007bccc800 88007bccc800
> 88007bfe5a98 8179b3b6 88007bccc800 880077fd0d28
> Call Trace:
> [] virtscsi_set_affinity+0x2d/0x40
> [] virtscsi_remove_vqs+0x26/0x50
> [] virtscsi_remove+0x82/0xa0
> [] virtio_dev_remove+0x22/0x70
> [] __device_release_driver+0x69/0xd0
> [] device_release_driver+0x2d/0x40
> [] bus_remove_device+0x116/0x150
> [] device_del+0x126/0x1e0
> [] device_unregister+0x16/0x30
> [] unregister_virtio_device+0x19/0x30
> [] virtio_pci_remove+0x36/0x80
> [] pci_device_remove+0x37/0x70
> [] __device_release_driver+0x69/0xd0
> [] device_release_driver+0x2d/0x40
> [] bus_remove_device+0x116/0x150
> [] device_del+0x126/0x1e0
> [] pci_stop_bus_device+0x9c/0xb0
> [] pci_stop_and_remove_bus_device+0x16/0x30
> [] acpiphp_disable_slot+0x8e/0x150
> [] hotplug_event_func+0xba/0x1a0
> [] ? acpi_os_release_object+0xe/0x12
> [] _handle_hotplug_event_func+0x31/0x70
> [] process_one_work+0x183/0x500
> [] worker_thread+0x122/0x400
> [] ? manage_workers+0x2d0/0x2d0
> [] kthread+0xce/0xe0
> [] ? kthread_freezable_should_stop+0x70/0x70
> [] ret_from_fork+0x7c/0xb0
> [] ? kthread_freezable_should_stop+0x70/0x70
> Code: 01 00 00 00 74 59 45 31 e4 83 bb c8 01 00 00 02 74 46 66 2e 0f 1f 84
> 00 00 00 00 00 49 63 c4 48 c1 e0 04 48 8b bc 0
> 3 10 02 00 00 <48> 8b 47 20 48 8b 80 d0 01 00 00 48 8b 40 50 48 85 c0 74 07 be
> RIP [] __virtscsi_set_affinity+0x6f/0x120
> RSP
> CR2: 0020
> ---[ end trace 99679331a3775f48 ]---
>
> CC: sta...@vger.kernel.org
> Signed-off-by: Asias He
Reviewed-by: Wanlong Gao
> ---
> drivers/scsi/virtio_scsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 2168258..74b88ef 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -751,7 +751,7 @@ static void __virtscsi_set_affinity(struct virtio_scsi
> *vscsi, bool affinity)
>
> vscsi->affinity_hint_set = true;
> } else {
> - for (i = 0; i < vscsi->num_queues - VIRTIO_SCSI_VQ_BASE; i++)
> + for (i = 0; i < vscsi->num_queues; i++)
> virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
>
> vscsi->affinity_hint_set = false;
>
--
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: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition
On 07/31/2013 05:15 AM, Martin K. Petersen wrote: >> "Bernd" == Bernd Schubert writes: > > Bernd, > >>> Product revision level: R001 > > It's clearly not verbatim passthrough... > > Bernd> Besides the firmware, the difference might be that I'm exporting > Bernd> single disks without any areca-raidset in between. I can try to > Bernd> confirm that tomorrow, I just need the system as it is till > Bernd> tomorrow noon. > > That would be a great data point. I don't have any Areca boards. > Just tested it, areca-raidset does not make a difference, but the firmware version does. After downgrading to 1.46 I have the same issue. It is getting a bit late for me, but as this a pure development system, which is also booted over nfs, I can investigate it tomorrow. Cheers, Bernd -- 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 RESEND 0/1] AHCI: Optimize interrupt processing
On Thu, Jul 25, 2013 at 12:16:41PM +0200, Alexander Gordeev wrote:
> On Mon, Jul 22, 2013 at 02:10:36PM -0700, Nicholas A. Bellinger wrote:
> > Np. FYI, you'll want to use the latest commit e7827b351 HEAD from
> > target-pending/scsi-mq, which now has functioning scsi-generic support.
>
> Survives a boot, a kernel build and the build's result :)
Not that rosy. Turned out the old code is called. Hangs with this hunk..
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index ac05cd6..a75fd41 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1103,6 +1103,8 @@ static struct device_attribute *piix_sidpr_shost_attrs[]
= {
static struct scsi_host_template piix_sidpr_sht = {
ATA_BMDMA_SHT(DRV_NAME),
.shost_attrs= piix_sidpr_shost_attrs,
+ .scsi_mq= true,
+ .queuecommand_mq= ata_scsi_queuecmd,
};
static struct ata_port_operations piix_sidpr_sata_ops = {
--
Regards,
Alexander Gordeev
agord...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] pm80xx: fix Adaptec 71605H hang
On 07/26/2013 06:43 PM, Hans Verkuil wrote: > The IO command size is 128 bytes for these new controllers as opposed to 64 > for the old 8001 controller. > > The Adaptec out-of-tree driver did this correctly. After comparing the two > this turned out to be the crucial difference. > > So don't hardcode the IO command size, instead use pm8001_ha->iomb_size as > that is the correct value for both old and new controllers. > > Signed-off-by: Hans Verkuil > Cc: sta...@vger.kernel.org # for v3.10 and up snip Thanks Hans. Looks good now. Acked-by: Jack Wang James, Could you consider to include this fix into your fixes tree, without this fix new Adaptec controller support is broken, sorry for that. Jack -- 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: Ejected Nook (usb mass storage) prevents suspend
On Wed, 31 Jul 2013, Oliver Neukum wrote: > These errors should be handled cleanly. How about this patch? > From 76a377d9894dc8945e9afecc7f9864e6dc3156b1 Mon Sep 17 00:00:00 2001 > From: Oliver Neukum > Date: Wed, 31 Jul 2013 13:32:51 +0200 > Subject: [PATCH] sd: handle errors during suspend > > Errors during suspend must be handled according to reasons You forgot to complete this sentence. > Errors due to missing media or unplugged devices must be ignored. > The error returns must be modified so that the generic layer > understands them. The patch contains a couple of trivial whitespace errors (space added to the end of a line, or spaces used instead of a tab). More importantly, if we already know that the medium is not present or has been changed since it was last used, then there's no reason to call sd_sync_cache() at all. 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: Kernel 3.10.3 "reset SuperSpeed USB device number 2 using xhci_hcd"
On Tue, 30 Jul 2013, Martin K. Petersen wrote:
> James?
>
> [PATCH] SCSI: Don't attempt to send extended INQUIRY command if
> skip_vpd_pages is set
>
> If a device has the skip_vpd_pages flag set we should simply fail the
> scsi_get_vpd_page() call.
>
> Signed-off-by: Martin K. Petersen
> Acked-by: Alan Stern
> Tested-by: Stuart Foster
> Cc: sta...@vger.kernel.org
>
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 3b1ea34..eaa808e 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -1031,6 +1031,9 @@ int scsi_get_vpd_page(struct scsi_device *sdev, u8
> page, unsigned char *buf,
> {
> int i, result;
>
> + if (sdev->skip_vpd_pages)
> + goto fail;
> +
> /* Ask for all the pages supported by this device */
> result = scsi_vpd_inquiry(sdev, buf, 0, buf_len);
> if (result)
Thanks, Martin.
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
[PATCH] virtio-scsi: Fix virtqueue affinity setup
vscsi->num_queues counts the number of request virtqueue which does not
include the control and event virtqueue. It is wrong to subtract
VIRTIO_SCSI_VQ_BASE from vscsi->num_queues.
This patch fixes the following panic.
(qemu) device_del scsi0
BUG: unable to handle kernel NULL pointer dereference at 0020
IP: [] __virtscsi_set_affinity+0x6f/0x120
PGD 0
Oops: [#1] SMP
Modules linked in:
CPU: 0 PID: 659 Comm: kworker/0:1 Not tainted 3.11.0-rc2+ #1172
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: kacpi_hotplug _handle_hotplug_event_func
task: 88007bee1cc0 ti: 88007bfe4000 task.ti: 88007bfe4000
RIP: 0010:[] []
__virtscsi_set_affinity+0x6f/0x120
RSP: 0018:88007bfe5a38 EFLAGS: 00010202
RAX: 0010 RBX: 880077fd0d28 RCX: 0050
RDX: RSI: 0246 RDI:
RBP: 88007bfe5a58 R08: 880077f6ff00 R09: 0001
R10: 8143e673 R11: 0001 R12: 0001
R13: 880077fd0800 R14: R15: 88007bf489b0
FS: () GS:88007ea0() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0020 CR3: 79f8b000 CR4: 06f0
Stack:
880077fd0d28 880077fd0800 0008
88007bfe5a78 8179b37d 88007bccc800 88007bccc800
88007bfe5a98 8179b3b6 88007bccc800 880077fd0d28
Call Trace:
[] virtscsi_set_affinity+0x2d/0x40
[] virtscsi_remove_vqs+0x26/0x50
[] virtscsi_remove+0x82/0xa0
[] virtio_dev_remove+0x22/0x70
[] __device_release_driver+0x69/0xd0
[] device_release_driver+0x2d/0x40
[] bus_remove_device+0x116/0x150
[] device_del+0x126/0x1e0
[] device_unregister+0x16/0x30
[] unregister_virtio_device+0x19/0x30
[] virtio_pci_remove+0x36/0x80
[] pci_device_remove+0x37/0x70
[] __device_release_driver+0x69/0xd0
[] device_release_driver+0x2d/0x40
[] bus_remove_device+0x116/0x150
[] device_del+0x126/0x1e0
[] pci_stop_bus_device+0x9c/0xb0
[] pci_stop_and_remove_bus_device+0x16/0x30
[] acpiphp_disable_slot+0x8e/0x150
[] hotplug_event_func+0xba/0x1a0
[] ? acpi_os_release_object+0xe/0x12
[] _handle_hotplug_event_func+0x31/0x70
[] process_one_work+0x183/0x500
[] worker_thread+0x122/0x400
[] ? manage_workers+0x2d0/0x2d0
[] kthread+0xce/0xe0
[] ? kthread_freezable_should_stop+0x70/0x70
[] ret_from_fork+0x7c/0xb0
[] ? kthread_freezable_should_stop+0x70/0x70
Code: 01 00 00 00 74 59 45 31 e4 83 bb c8 01 00 00 02 74 46 66 2e 0f 1f 84 00
00 00 00 00 49 63 c4 48 c1 e0 04 48 8b bc 0
3 10 02 00 00 <48> 8b 47 20 48 8b 80 d0 01 00 00 48 8b 40 50 48 85 c0 74 07 be
RIP [] __virtscsi_set_affinity+0x6f/0x120
RSP
CR2: 0020
---[ end trace 99679331a3775f48 ]---
CC: sta...@vger.kernel.org
Signed-off-by: Asias He
---
drivers/scsi/virtio_scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 2168258..74b88ef 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -751,7 +751,7 @@ static void __virtscsi_set_affinity(struct virtio_scsi
*vscsi, bool affinity)
vscsi->affinity_hint_set = true;
} else {
- for (i = 0; i < vscsi->num_queues - VIRTIO_SCSI_VQ_BASE; i++)
+ for (i = 0; i < vscsi->num_queues; i++)
virtqueue_set_affinity(vscsi->req_vqs[i].vq, -1);
vscsi->affinity_hint_set = false;
--
1.8.3.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 7/7] scsi: ufs: configure the attribute for power mode
Change looks good (except one minor question).
Reviewed-by: Subhash Jadavani
On 7/26/2013 7:19 PM, Seungwon Jeon wrote:
UIC attributes can be set with using DME_SET command for
power mode change. For configuration the link capability
attributes are used, which is updated after successful
link startup.
Signed-off-by: Seungwon Jeon
---
drivers/scsi/ufs/ufshcd.c | 74 +++-
drivers/scsi/ufs/unipro.h | 21 +
2 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ffda72d..ebdb9ff 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -975,6 +975,70 @@ out:
}
/**
+ * ufshcd_config_max_pwr_mode - Set & Change power mode with
+ * maximum capability attribute information.
+ * @hba: per adapter instance
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_config_max_pwr_mode(struct ufs_hba *hba)
+{
+ enum {RX = 0, TX = 1};
+ u32 lanes[] = {1, 1};
+ u32 gear[] = {1, 1};
+ u8 pwr[] = {FASTAUTO_MODE, FASTAUTO_MODE};
+ int i, ret;
+
+ /* Get the connected lane count */
+ ufshcd_dme_get(hba, UIC_ARG_MIB(PA_CONNECTEDRXDATALANES), &lanes[RX]);
+ ufshcd_dme_get(hba, UIC_ARG_MIB(PA_CONNECTEDTXDATALANES), &lanes[TX]);
+
+ /*
+* First, get the maximum gears of HS speed.
+* If a zero value, it means there is no HSGEAR capability.
+* Then, get the maximum gears of PWM speed.
+*/
+ ufshcd_dme_get(hba, UIC_ARG_MIB(PA_MAXRXHSGEAR), &gear[RX]);
+ if (!gear[RX]) {
+ ufshcd_dme_get(hba, UIC_ARG_MIB(PA_MAXRXPWMGEAR), &gear[RX]);
+ pwr[RX] = SLOWAUTO_MODE;
+ }
+
+ ufshcd_dme_peer_get(hba, UIC_ARG_MIB(PA_MAXRXHSGEAR), &gear[TX]);
+ if (!gear[TX]) {
+ ufshcd_dme_peer_get(hba, UIC_ARG_MIB(PA_MAXRXPWMGEAR),
+ &gear[TX]);
+ pwr[TX] = SLOWAUTO_MODE;
+ }
+
+ /*
+* Configure attributes for power mode change with below.
+* - PA_RXGEAR, PA_ACTIVERXDATALANES, PA_RXTERMINATION,
+* - PA_TXGEAR, PA_ACTIVETXDATALANES, PA_TXTERMINATION,
+* - PA_HSSERIES
+*/
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_RXGEAR), gear[RX]);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_ACTIVERXDATALANES), lanes[RX]);
+ if (pwr[RX] == FASTAUTO_MODE)
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_RXTERMINATION), TRUE);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TXGEAR), gear[TX]);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_ACTIVETXDATALANES), lanes[TX]);
+ if (pwr[TX] == FASTAUTO_MODE)
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TXTERMINATION), TRUE);
Does this mean TX-RX Termination can be enabled only in HS gear mode?
Somehow i couldn't find this
+
+ if (pwr[RX] == FASTAUTO_MODE || pwr[TX] == FASTAUTO_MODE)
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_HSSERIES), PA_HS_MODE_B);
+
+ ret = ufshcd_uic_change_pwr_mode(hba, pwr[RX] << 4 | pwr[TX]);
+ if (ret)
+ dev_err(hba->dev,
+ "pwr_mode: power mode change failed %d\n", ret);
+
+ return ret;
+}
+
+/**
* ufshcd_make_hba_operational - Make UFS controller operational
* @hba: per adapter instance
*
@@ -1754,8 +1818,14 @@ static void ufshcd_async_scan(void *data, async_cookie_t
cookie)
int ret;
ret = ufshcd_link_startup(hba);
- if (!ret)
- scsi_scan_host(hba->host);
+ if (ret)
+ goto out;
+
+ ufshcd_config_max_pwr_mode(hba);
+
+ scsi_scan_host(hba->host);
+out:
+ return;
}
static struct scsi_host_template ufshcd_driver_template = {
diff --git a/drivers/scsi/ufs/unipro.h b/drivers/scsi/ufs/unipro.h
index 3a710eb..0bb8041 100644
--- a/drivers/scsi/ufs/unipro.h
+++ b/drivers/scsi/ufs/unipro.h
@@ -72,6 +72,21 @@
#define PA_STALLNOCONFIGTIME 0x15A3
#define PA_SAVECONFIGTIME 0x15A4
+/* PA power modes */
+enum {
+ FAST_MODE = 1,
+ SLOW_MODE = 2,
+ FASTAUTO_MODE = 4,
+ SLOWAUTO_MODE = 5,
+ UNCHANGED = 7,
+};
+
+/* PA TX/RX Frequency Series */
+enum {
+ PA_HS_MODE_A= 1,
+ PA_HS_MODE_B= 2,
+};
+
/*
* Data Link Layer Attributes
*/
@@ -127,4 +142,10 @@
#define T_TC0TXMAXSDUSIZE 0x4060
#define T_TC1TXMAXSDUSIZE 0x4061
+/* Boolean attribute values */
+enum {
+ FALSE = 0,
+ TRUE,
+};
+
#endif /* _UNIPRO_H_ */
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Ejected Nook (usb mass storage) prevents suspend
On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
> On Mon, 29 Jul 2013, Oliver Neukum wrote:
>
> > On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
> >
> > > In addition to my earlier comment, the patch below should be applied.
> > > It will fix your immediate problem, although not in the best way.
> >
> > Alan,
> >
> > I think your diagnosis is correct, but not the fix.
> > This is run even in the runtime case. We might lose
> > data if the flush is not done.
>
> Actually no, the scsi_bus_suspend_common() routine does not run during
> runtime PM. It gets called only from scsi_bus_suspend(),
> scsi_bus_freeze(), and scsi_bus_poweroff(), which are all part of
> system sleep.
These errors should be handled cleanly. How about this patch?
Regards
Oliver
>From 76a377d9894dc8945e9afecc7f9864e6dc3156b1 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 31 Jul 2013 13:32:51 +0200
Subject: [PATCH] sd: handle errors during suspend
Errors during suspend must be handled according to reasons
Errors due to missing media or unplugged devices must be ignored.
The error returns must be modified so that the generic layer
understands them.
Signed-off-by: Oliver Neukum
---
drivers/scsi/scsi_pm.c | 3 ++-
drivers/scsi/sd.c | 61 +-
2 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 4c5aabe..af4c050 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -54,7 +54,8 @@ scsi_bus_suspend_common(struct device *dev, int (*cb)(struct device *))
/*
* All the high-level SCSI drivers that implement runtime
* PM treat runtime suspend, system suspend, and system
- * hibernate identically.
+ * hibernate nearly identically. In all cases the requirements
+ * for runtime suspension are stricter.
*/
if (pm_runtime_suspended(dev))
return 0;
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 86fcf2c..76273f4 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -105,7 +105,8 @@ static void sd_unlock_native_capacity(struct gendisk *disk);
static int sd_probe(struct device *);
static int sd_remove(struct device *);
static void sd_shutdown(struct device *);
-static int sd_suspend(struct device *);
+static int sd_suspend_system(struct device *);
+static int sd_suspend_runtime(struct device *);
static int sd_resume(struct device *);
static void sd_rescan(struct device *);
static int sd_done(struct scsi_cmnd *);
@@ -483,11 +484,11 @@ static struct class sd_disk_class = {
};
static const struct dev_pm_ops sd_pm_ops = {
- .suspend = sd_suspend,
+ .suspend = sd_suspend_system,
.resume = sd_resume,
- .poweroff = sd_suspend,
+ .poweroff = sd_suspend_system,
.restore = sd_resume,
- .runtime_suspend = sd_suspend,
+ .runtime_suspend = sd_suspend_runtime,
.runtime_resume = sd_resume,
};
@@ -1455,12 +1456,31 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
if (res) {
sd_print_result(sdkp, res);
- if (driver_byte(res) & DRIVER_SENSE)
+
+ if (driver_byte(res) & DRIVER_SENSE)
sd_print_sense_hdr(sdkp, &sshdr);
+ /* we need to evaluate the error return */
+ if ((scsi_sense_valid(&sshdr) &&
+ /* 0x3a is medium not present */
+ sshdr.asc == 0x3a))
+/* this is no error here */
+return 0;
+
+ switch (host_byte(res)) {
+ /* ignore errors due to racing a disconnection */
+ case DID_BAD_TARGET:
+ case DID_NO_CONNECT:
+ return 0;
+ /* signal the upper layer it might try again */
+ case DID_BUS_BUSY:
+ case DID_IMM_RETRY:
+ case DID_REQUEUE:
+ case DID_SOFT_ERROR:
+ return -EBUSY;
+ default:
+ return -EIO;
+ }
}
-
- if (res)
- return -EIO;
return 0;
}
@@ -3062,9 +3082,17 @@ static int sd_start_stop_device(struct scsi_disk *sdkp, int start)
sd_print_result(sdkp, res);
if (driver_byte(res) & DRIVER_SENSE)
sd_print_sense_hdr(sdkp, &sshdr);
+ if ((scsi_sense_valid(&sshdr) &&
+ /* 0x3a is medium not present */
+ sshdr.asc == 0x3a))
+ res = 0;
}
- return res;
+ /* SCSI error codes must not go to the generic layer */
+ if (res)
+ return -EIO;
+
+ return 0;
}
/*
@@ -3096,7 +3124,7 @@ exit:
scsi_disk_put(sdkp);
}
-static int sd_suspend(struct device *dev)
+static int sd_suspend_common(struct device *dev, bool ignore_stop_errors)
{
struct scsi_disk *sdkp = scsi_disk_get_from_dev(dev);
int ret = 0;
@@ -3113,7 +3141,10 @@ static int sd_suspend(struct device *dev)
if (sdkp->device->manage_start_stop) {
sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
+ /* an error is not worth aborting a system sleep */
ret = sd_start_stop_device(sdkp, 0);
+ if (ignore_stop_errors)
+ ret = 0;
}
done:
@@ -3121,6 +3152,16 @@ done:
return ret;
}
+static int sd_suspend_system(struct device *dev)
+{
+ return sd_suspend_common(dev, true);
+}
+
+static int sd_suspend_runtime(struct device *dev)
+{
+return sd_suspend_common(dev, fals
Re: [PATCH RESEND 0/1] AHCI: Optimize interrupt processing
Hello, On Tue, Jul 30, 2013 at 09:16:02PM -0700, Marc C wrote: > >> One thing which would probably be worthwhile tho is getting rid of the > >> bitmap based qc tag allocator in libata. That one is just borderline > >> stupid to keep around on any setup which is supposed to be scalable. > > Your border might be wider than mine :-). Yes, the bitmap should > > definitely go. > > A naive implementation is obviously less-than-efficient. However, what > other problems exist with the libata QC tag allocator? I highly doubt > SATA will change to beyond 32 queue tags, primarily because it would > be a pain to change SDB FIS (it's likely to break the dozens of AHCI > controller implementations out there). Further, it seems like the > industry stopped caring about SATA and is pushing NVMe for future > offerings. > > In any event, most modern systems should have instructions to count > leading zeroes and modify bits atomically. It's inefficient not because scanning is expensive but because it makes all CPUs in the system to hit on the exact same cacheline over and over and over again. Thanks. -- tejun -- 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/isci/port_config: Fix a infinite loop.
On Wednesday, July 17, 2013 4:54 AM Xinghai Yu wrote: > > It seems the "phy_index++;" have been placed in wrong place, without it > the while circle up will do a infinite loop. > > Signed-off-by: Xinghai Yu Acked-by: Lukasz Dorau > --- > drivers/scsi/isci/port_config.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/scsi/isci/port_config.c b/drivers/scsi/isci/port_config.c > index cd962da..85c77f6 100644 > --- a/drivers/scsi/isci/port_config.c > +++ b/drivers/scsi/isci/port_config.c > @@ -311,9 +311,9 @@ sci_mpc_agent_validate_phy_configuration(struct > isci_host *ihost, > &ihost->phys[phy_index]); > > assigned_phy_mask |= (1 << phy_index); > + phy_index++; > } > > - phy_index++; > } > > return sci_port_configuration_agent_validate_ports(ihost, port_agent); > -- > 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
