user/sven/linux.git/drivers/scsi/libsas, branch v3.4.78

SCSI: libsas: fix usage of ata_tf_to_fis

2013-12-12T06:34:10Z

commit ae5fbae0ccd982dfca0ce363036ed92f5b13f150 upstream. Since commit 110dd8f19df5 "[SCSI] libsas: fix scr_read/write users and update the libata documentation" we have been passing pmp=1 and is_cmd=0 to ata_tf_to_fis(). Praveen reports that eSATA attached drives do not discover correctly. His investigation found that the BIOS was passing pmp=0 while Linux was passing pmp=1 and failing to discover the drives. Update libsas to follow the libata example of pulling the pmp setting from the ata_link and correct is_cmd to be 1 since all tf's submitted through ->qc_issue are commands. Presumably libsas lldds do not care about is_cmd as they have sideband mechanisms to perform link management. http://marc.info/?l=linux-scsi&m=138179681726990 [jejb: checkpatch fix] Signed-off-by: Dan Williams Reported-by: Praveen Murali Tested-by: Praveen Murali Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: libsas: fix handling vacant phy in sas_set_ex_phy()

2013-04-17T04:27:26Z

commit d4a2618fa77b5e58ec15342972bd3505a1c3f551 upstream. If a result of the SMP discover function is PHY VACANT, the content of discover response structure (dr) is not valid. It sometimes happens that dr->attached_sas_addr can contain even SAS address of other phy. In such case an invalid phy is created, what causes NULL pointer dereference during destruction of expander's phys. So if a result of SMP function is PHY VACANT, the content of discover response structure (dr) must not be copied to phy structure. This patch fixes the following bug: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 IP: [] sysfs_find_dirent+0x12/0x90 Call Trace: [] sysfs_get_dirent+0x35/0x80 [] sysfs_unmerge_group+0x1e/0xb0 [] dpm_sysfs_remove+0x24/0x90 [] device_del+0x44/0x1d0 [] sas_rphy_delete+0x9/0x20 [scsi_transport_sas] [] sas_destruct_devices+0xe6/0x110 [libsas] [] process_one_work+0x16c/0x350 [] worker_thread+0x17a/0x410 [] kthread+0x96/0xa0 [] kernel_thread_helper+0x4/0x10 Signed-off-by: Lukasz Dorau Signed-off-by: Pawel Baldysiak Reviewed-by: Maciej Patelczyk Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: libsas: fix sas_discover_devices return code handling

2012-08-09T15:31:27Z

commit b17caa174a7e1fd2e17b26e210d4ee91c4c28b37 upstream. commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_discover_dev() commit 19252de6 [SCSI] libsas: fix wide port hotplug issues The above commits seem to have confused the return value of sas_ex_discover_dev which is non-zero on failure and sas_ex_join_wide_port which just indicates short circuiting discovery on already established ports. The result is random discovery failures depending on configuration. Calls to sas_ex_join_wide_port are the source of the trouble as its return value is errantly assigned to 'res'. Convert it to bool and stop returning its result up the stack. Tested-by: Dan Melnic Reported-by: Dan Melnic Signed-off-by: Dan Williams Reviewed-by: Jack Wang Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: libsas: continue revalidation

2012-08-09T15:31:27Z

commit 26f2f199ff150d8876b2641c41e60d1c92d2fb81 upstream. Continue running revalidation until no more broadcast devices are discovered. Fixes cases where re-discovery completes too early in a domain with multiple expanders with pending re-discovery events. Servicing BCNs can get backed up behind error recovery. Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: libsas: fix taskfile corruption in sas_ata_qc_fill_rtf

2012-07-16T16:04:37Z

commit 6ef1b512f4e6f936d89aa20be3d97a7ec7c290ac upstream. fill_result_tf() grabs the taskfile flags from the originating qc which sas_ata_qc_fill_rtf() promptly overwrites. The presence of an ata_taskfile in the sata_device makes it tempting to just copy the full contents in sas_ata_qc_fill_rtf(). However, libata really only wants the fis contents and expects the other portions of the taskfile to not be touched by ->qc_fill_rtf. To that end store a fis buffer in the sata_device and use ata_tf_from_fis() like every other ->qc_fill_rtf() implementation. Reported-by: Praveen Murali Tested-by: Praveen Murali Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

[SCSI] Revert "[SCSI] libsas: fix sas port naming"

2012-04-23T11:15:53Z

This reverts commit a692b0eec5efae382dfa800e8b4b083f172921a7. Tom reports: [ 8.741033] ------------[ cut here ]------------ [ 8.741038] WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0xc1/0xf0() [ 8.741040] Hardware name: To Be Filled By O.E.M. [ 8.741041] sysfs: cannot create duplicate filename ...and missing 2 out of 4 drives connected to mvsas. Commit a692b0ee made the assumption that all the phy ids an lldd registers to libsas are unique. However, in the "multi-chip" case mvsas does a rather annoying duplication of phy ids in the array passed to libsas. So, for example, chip0 has phy0-3 at ha phy index 0-3 and chip1 has its phy0-3 at ha phy index 4-7. The more natural model would be to create a scsi_host (and sas_ha) per chip (controller), but for now revert the naming fix which unfortunately means dealing with unpredictable end-device names for a bit longer. Cc: Xiangliang Yu Cc: Patrick Thomson Reported-by: Tom Rini Tested-by: Tom Rini Signed-off-by: Dan Williams Signed-off-by: James Bottomley

[SCSI] libsas: fix false positive 'device attached' conditions

2012-04-23T11:14:09Z

Normalize phy->attached_sas_addr to return a zero-address in the case when device-type == NO_DEVICE or the linkrate is invalid to handle expanders that put non-zero sas addresses in the discovery response: sas: ex 5001b4da000f903f phy02:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy01:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy03:U:0 attached: 0100000000000000 (no device) sas: ex 5001b4da000f903f phy00:U:0 attached: 0100000000000000 (no device) Reported-by: Andrzej Jakowski Signed-off-by: Dan Williams Cc: stable@vger.kernel.org Signed-off-by: James Bottomley

[SCSI] libsas, libata: fix start of life for a sas ata_port

2012-04-23T11:11:47Z

This changes the ordering of initialization and probing events from: 1/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN 2/ allocate ata_port and schedule port probe in DISCE_PROBE ...to: 1/ allocate ata_port in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN 2/ allocate rphy in PORTE_BYTES_DMAED, DISCE_REVALIDATE_DOMAIN 3/ schedule port probe in DISCE_PROBE This ordering prevents PHYE_SIGNAL_LOSS_EVENTS from sneaking in to destrory ata devices before they have been fully initialized: BUG: unable to handle kernel paging request at 0000000000003b10 IP: [] sas_ata_end_eh+0x12/0x5e [libsas] ... [] sas_unregister_common_dev+0x78/0xc9 [libsas] [] sas_unregister_dev+0x4f/0xad [libsas] [] sas_unregister_domain_devices+0x7f/0xbf [libsas] [] sas_deform_port+0x61/0x1b8 [libsas] [] sas_phye_loss_of_signal+0x29/0x2b [libsas] ...and kills the awkward "sata domain_device briefly existing in the domain without an ata_port" state. Reported-by: Michal Kosciowski Signed-off-by: Dan Williams Acked-by: Jeff Garzik Signed-off-by: James Bottomley

[SCSI] libsas: fix ata_eh clobbering ex_phys via smp_ata_check_ready

2012-04-23T11:10:34Z

The check_ready implementation in the expander-attached ata device case polls on sas_ex_phy_discover(). The effect is that the ex_phy fields (critically ->attached_sas_addr) can change. When ata_eh ends and libsas comes along to revalidate the domain sas_unregister_devs_sas_addr() can fail to lookup devices to remove, or fail to re-add an ata device that ata_eh marked as disabled. So change the code to skip the sas_address and change count updates when ata_eh is active. Cc: Jack Wang Tested-by: Maciej Patelczyk Tested-by: Bartek Nowakowski Tested-by: Jacek Danecki Signed-off-by: Dan Williams Signed-off-by: James Bottomley

[SCSI] libsas: unify domain_device sas_rphy lifetimes

2012-04-23T11:08:56Z

Since the domain_device can out live the scsi_target we need the rphy to follow suit otherwise we run into issues like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [] sas_ata_printk+0x43/0x6f [libsas] PGD 0 Oops: 0000 [#1] SMP CPU 1 Modules linked in: ses enclosure isci libsas scsi_transport_sas fuse sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf microcode pcspkr igb joydev iTCO_wdt ioatdma iTCO_vendor_support i2c_i801 i2c_core dca wmi hed ipv6 pata_acpi ata_generic [last unloaded: scsi_wait_scan] Pid: 129, comm: kworker/u:3 Not tainted 3.3.0-rc5-isci+ #1 Intel Corporation SandyBridge Platform/To be filled by O.E.M. RIP: 0010:[] [] sas_ata_printk+0x43/0x6f [libsas] RSP: 0018:ffff88042232dd70 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8804283165b8 RCX: ffff88042232dda0 RDX: ffff88042232dd78 RSI: ffff8804283165b8 RDI: ffffffffa01188d7 RBP: ffff88042232ddd0 R08: ffff880388454000 R09: ffff8803edfde1f8 R10: ffff8803edfde1f8 R11: ffff8803edfde1f8 R12: ffff880428316750 R13: ffff880388454000 R14: ffff8803f88b31d0 R15: ffff8803f8b21d50 FS: 0000000000000000(0000) GS:ffff88042ee20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000050 CR3: 0000000001a05000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/u:3 (pid: 129, threadinfo ffff88042232c000, task ffff88042230c920) Stack: 0000000000000000 ffff880400000018 ffff88042232dde0 ffff88042232dda0 ffffffffa01188c4 ffff88042ee93af0 ffff88042232ddb0 ffffffff8100e047 ffff88042232de10 ffff880420e5a2c8 ffff8803f8b21d50 ffff8803edfde1f8 Call Trace: [] ? load_TLS+0xb/0xf [] async_sas_ata_eh+0x66/0x95 [libsas] [] async_run_entry_fn+0x9e/0x131 Reported-by: Tom Jackson Tested-by: Tom Jackson Signed-off-by: Dan Williams Signed-off-by: James Bottomley