<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/ata, branch v4.4.235</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.235</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.235'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-06-30T00:07:55+00:00</updated>
<entry>
<title>libata: Use per port sync for detach</title>
<updated>2020-06-30T00:07:55+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2020-06-03T07:48:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d8a71a53366a7be14e73bf5dde57846a23d9fa0d'/>
<id>urn:sha1:d8a71a53366a7be14e73bf5dde57846a23d9fa0d</id>
<content type='text'>
[ Upstream commit b5292111de9bb70cba3489075970889765302136 ]

Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before
detach") may cause system freeze during suspend.

Using async_synchronize_full() in PM callbacks is wrong, since async
callbacks that are already scheduled may wait for not-yet-scheduled
callbacks, causes a circular dependency.

Instead of using big hammer like async_synchronize_full(), use async
cookie to make sure port probe are synced, without affecting other
scheduled PM callbacks.

Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before detach")
Suggested-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Tested-by: John Garry &lt;john.garry@huawei.com&gt;
BugLink: https://bugs.launchpad.net/bugs/1867983
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: sata_dwc_460ex: remove incorrect locking</title>
<updated>2020-05-10T08:26:34+00:00</updated>
<author>
<name>Mans Rullgard</name>
<email>mans@mansr.com</email>
</author>
<published>2016-04-26T09:03:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c5a1b47dd54898417a1aa104bf1e775f0957a0b'/>
<id>urn:sha1:3c5a1b47dd54898417a1aa104bf1e775f0957a0b</id>
<content type='text'>
commit 55e610cdd28c0ad3dce0652030c0296d549673f3 upstream.

This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error.  Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.

Enabling lock debugging gives the following output:

=============================================
[ INFO: possible recursive locking detected ]
4.4.0-rc5+ #189 Not tainted
---------------------------------------------
kworker/u2:3/37 is trying to acquire lock:
 (&amp;(&amp;host-&gt;lock)-&gt;rlock){-.-...}, at: [&lt;90283294&gt;] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c

but task is already holding lock:
 (&amp;(&amp;host-&gt;lock)-&gt;rlock){-.-...}, at: [&lt;902761ac&gt;] ata_scsi_queuecmd+0x2c/0x330

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;(&amp;host-&gt;lock)-&gt;rlock);
  lock(&amp;(&amp;host-&gt;lock)-&gt;rlock);

 *** DEADLOCK ***
 May be due to missing lock nesting notation

4 locks held by kworker/u2:3/37:
 #0:  ("events_unbound"){.+.+.+}, at: [&lt;9003a0a4&gt;] process_one_work+0x12c/0x430
 #1:  ((&amp;entry-&gt;work)){+.+.+.}, at: [&lt;9003a0a4&gt;] process_one_work+0x12c/0x430
 #2:  (&amp;bdev-&gt;bd_mutex){+.+.+.}, at: [&lt;9011fd54&gt;] __blkdev_get+0x50/0x380
 #3:  (&amp;(&amp;host-&gt;lock)-&gt;rlock){-.-...}, at: [&lt;902761ac&gt;] ata_scsi_queuecmd+0x2c/0x330

stack backtrace:
CPU: 0 PID: 37 Comm: kworker/u2:3 Not tainted 4.4.0-rc5+ #189
Workqueue: events_unbound async_run_entry_fn
Stack : 90b38e30 00000021 00000003 9b2a6040 00000000 9005f3f0 904fc8dc 00000025
        906b96e4 00000000 90528648 9b3336c4 904fc8dc 9009bf18 00000002 00000004
        00000000 00000000 9b3336c4 9b3336e4 904fc8dc 9003d074 00000000 90500000
        9005e738 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        6e657665 755f7374 756f626e 0000646e 00000000 00000000 9b00ca00 9b025000
          ...
Call Trace:
[&lt;90009d6c&gt;] show_stack+0x88/0xa4
[&lt;90057744&gt;] __lock_acquire+0x1ce8/0x2154
[&lt;900583e4&gt;] lock_acquire+0x64/0x8c
[&lt;9045ff10&gt;] _raw_spin_lock_irqsave+0x54/0x78
[&lt;90283294&gt;] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
[&lt;90283484&gt;] sata_dwc_qc_issue+0x1a8/0x24c
[&lt;9026b39c&gt;] ata_qc_issue+0x1f0/0x410
[&lt;90273c6c&gt;] ata_scsi_translate+0xb4/0x200
[&lt;90276234&gt;] ata_scsi_queuecmd+0xb4/0x330
[&lt;9025800c&gt;] scsi_dispatch_cmd+0xd0/0x128
[&lt;90259934&gt;] scsi_request_fn+0x58c/0x638
[&lt;901a3e50&gt;] __blk_run_queue+0x40/0x5c
[&lt;901a83d4&gt;] blk_queue_bio+0x27c/0x28c
[&lt;901a5914&gt;] generic_make_request+0xf0/0x188
[&lt;901a5a54&gt;] submit_bio+0xa8/0x194
[&lt;9011adcc&gt;] submit_bh_wbc.isra.23+0x15c/0x17c
[&lt;9011c908&gt;] block_read_full_page+0x3e4/0x428
[&lt;9009e2e0&gt;] do_read_cache_page+0xac/0x210
[&lt;9009fd90&gt;] read_cache_page+0x18/0x24
[&lt;901bbd18&gt;] read_dev_sector+0x38/0xb0
[&lt;901bd174&gt;] msdos_partition+0xb4/0x5c0
[&lt;901bcb8c&gt;] check_partition+0x140/0x274
[&lt;901bba60&gt;] rescan_partitions+0xa0/0x2b0
[&lt;9011ff68&gt;] __blkdev_get+0x264/0x380
[&lt;901201ac&gt;] blkdev_get+0x128/0x36c
[&lt;901b9378&gt;] add_disk+0x3c0/0x4bc
[&lt;90268268&gt;] sd_probe_async+0x100/0x224
[&lt;90043a44&gt;] async_run_entry_fn+0x50/0x124
[&lt;9003a11c&gt;] process_one_work+0x1a4/0x430
[&lt;9003a4f4&gt;] worker_thread+0x14c/0x4fc
[&lt;900408f4&gt;] kthread+0xd0/0xe8
[&lt;90004338&gt;] ret_from_kernel_thread+0x14/0x1c

Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Tested-by: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: Mans Rullgard &lt;mans@mansr.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: Return correct status in sata_pmp_eh_recover_pm() when ATA_DFLAG_DETACH is set</title>
<updated>2020-04-24T05:57:16+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2019-03-27T09:02:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b95523968c6e10d8eadb0f031774d5891eb82f7b'/>
<id>urn:sha1:b95523968c6e10d8eadb0f031774d5891eb82f7b</id>
<content type='text'>
commit 8305f72f952cff21ce8109dc1ea4b321c8efc5af upstream.

During system resume from suspend, this can be observed on ASM1062 PMP
controller:

ata10.01: SATA link down (SStatus 0 SControl 330)
ata10.02: hard resetting link
ata10.02: SATA link down (SStatus 0 SControl 330)
ata10.00: configured for UDMA/133
Kernel panic - not syncing: stack-protector: Kernel
 in: sata_pmp_eh_recover+0xa2b/0xa40

CPU: 2 PID: 230 Comm: scsi_eh_9 Tainted: P OE
#49-Ubuntu
Hardware name: System manufacturer System Product
 1001 12/10/2017
Call Trace:
dump_stack+0x63/0x8b
panic+0xe4/0x244
? sata_pmp_eh_recover+0xa2b/0xa40
__stack_chk_fail+0x19/0x20
sata_pmp_eh_recover+0xa2b/0xa40
? ahci_do_softreset+0x260/0x260 [libahci]
? ahci_do_hardreset+0x140/0x140 [libahci]
? ata_phys_link_offline+0x60/0x60
? ahci_stop_engine+0xc0/0xc0 [libahci]
sata_pmp_error_handler+0x22/0x30
ahci_error_handler+0x45/0x80 [libahci]
ata_scsi_port_error_handler+0x29b/0x770
? ata_scsi_cmd_error_handler+0x101/0x140
ata_scsi_error+0x95/0xd0
? scsi_try_target_reset+0x90/0x90
scsi_error_handler+0xd0/0x5b0
kthread+0x121/0x140
? scsi_eh_get_sense+0x200/0x200
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x22/0x40
Kernel Offset: 0xcc00000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Since sata_pmp_eh_recover_pmp() doens't set rc when ATA_DFLAG_DETACH is
set, sata_pmp_eh_recover() continues to run. During retry it triggers
the stack protector.

Set correct rc in sata_pmp_eh_recover_pmp() to let sata_pmp_eh_recover()
jump to pmp_fail directly.

BugLink: https://bugs.launchpad.net/bugs/1821434
Cc: stable@vger.kernel.org
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: Remove extra scsi_host_put() in ata_scsi_add_hosts()</title>
<updated>2020-04-24T05:57:07+00:00</updated>
<author>
<name>John Garry</name>
<email>john.garry@huawei.com</email>
</author>
<published>2020-02-28T11:33:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=38e61773c9c69d14d7095ba500aeeab9a7720c26'/>
<id>urn:sha1:38e61773c9c69d14d7095ba500aeeab9a7720c26</id>
<content type='text'>
[ Upstream commit 1d72f7aec3595249dbb83291ccac041a2d676c57 ]

If the call to scsi_add_host_with_dma() in ata_scsi_add_hosts() fails,
then we may get use-after-free KASAN warns:

==================================================================
BUG: KASAN: use-after-free in kobject_put+0x24/0x180
Read of size 1 at addr ffff0026b8c80364 by task swapper/0/1
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W         5.6.0-rc3-00004-g5a71b206ea82-dirty #1765
Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B160.01 02/24/2020
Call trace:
dump_backtrace+0x0/0x298
show_stack+0x14/0x20
dump_stack+0x118/0x190
print_address_description.isra.9+0x6c/0x3b8
__kasan_report+0x134/0x23c
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
kobject_put+0x24/0x180
put_device+0x10/0x20
scsi_host_put+0x10/0x18
ata_devres_release+0x74/0xb0
release_nodes+0x2d0/0x470
devres_release_all+0x50/0x78
really_probe+0x2d4/0x560
driver_probe_device+0x7c/0x148
device_driver_attach+0x94/0xa0
__driver_attach+0xa8/0x110
bus_for_each_dev+0xe8/0x158
driver_attach+0x30/0x40
bus_add_driver+0x220/0x2e0
driver_register+0xbc/0x1d0
__pci_register_driver+0xbc/0xd0
ahci_pci_driver_init+0x20/0x28
do_one_initcall+0xf0/0x608
kernel_init_freeable+0x31c/0x384
kernel_init+0x10/0x118
ret_from_fork+0x10/0x18

Allocated by task 5:
save_stack+0x28/0xc8
__kasan_kmalloc.isra.8+0xbc/0xd8
kasan_kmalloc+0xc/0x18
__kmalloc+0x1a8/0x280
scsi_host_alloc+0x44/0x678
ata_scsi_add_hosts+0x74/0x268
ata_host_register+0x228/0x488
ahci_host_activate+0x1c4/0x2a8
ahci_init_one+0xd18/0x1298
local_pci_probe+0x74/0xf0
work_for_cpu_fn+0x2c/0x48
process_one_work+0x488/0xc08
worker_thread+0x330/0x5d0
kthread+0x1c8/0x1d0
ret_from_fork+0x10/0x18

Freed by task 5:
save_stack+0x28/0xc8
__kasan_slab_free+0x118/0x180
kasan_slab_free+0x10/0x18
slab_free_freelist_hook+0xa4/0x1a0
kfree+0xd4/0x3a0
scsi_host_dev_release+0x100/0x148
device_release+0x7c/0xe0
kobject_put+0xb0/0x180
put_device+0x10/0x20
scsi_host_put+0x10/0x18
ata_scsi_add_hosts+0x210/0x268
ata_host_register+0x228/0x488
ahci_host_activate+0x1c4/0x2a8
ahci_init_one+0xd18/0x1298
local_pci_probe+0x74/0xf0
work_for_cpu_fn+0x2c/0x48
process_one_work+0x488/0xc08
worker_thread+0x330/0x5d0
kthread+0x1c8/0x1d0
ret_from_fork+0x10/0x18

There is also refcount issue, as well:
WARNING: CPU: 1 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x170

The issue is that we make an erroneous extra call to scsi_host_put()
for that host:

So in ahci_init_one()-&gt;ata_host_alloc_pinfo()-&gt;ata_host_alloc(), we setup
a device release method - ata_devres_release() - which intends to release
the SCSI hosts:

static void ata_devres_release(struct device *gendev, void *res)
{
	...
	for (i = 0; i &lt; host-&gt;n_ports; i++) {
		struct ata_port *ap = host-&gt;ports[i];

		if (!ap)
			continue;

		if (ap-&gt;scsi_host)
			scsi_host_put(ap-&gt;scsi_host);

	}
	...
}

However in the ata_scsi_add_hosts() error path, we also call
scsi_host_put() for the SCSI hosts.

Fix by removing the the scsi_host_put() calls in ata_scsi_add_hosts() and
leave this to ata_devres_release().

Fixes: f31871951b38 ("libata: separate out ata_host_alloc() and ata_host_register()")
Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ahci: Do not export local variable ahci_em_messages</title>
<updated>2020-01-29T09:21:47+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2019-08-30T19:42:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=667acf9a72279e04fdd011fd7f5e7670e066e0d4'/>
<id>urn:sha1:667acf9a72279e04fdd011fd7f5e7670e066e0d4</id>
<content type='text'>
[ Upstream commit 60fc35f327e0a9e60b955c0f3c3ed623608d1baa ]

The commit ed08d40cdec4
  ("ahci: Changing two module params with static and __read_mostly")
moved ahci_em_messages to be static while missing the fact of exporting it.

WARNING: "ahci_em_messages" [vmlinux] is a static EXPORT_SYMBOL_GPL

Drop export for the local variable ahci_em_messages.

Fixes: ed08d40cdec4 ("ahci: Changing two module params with static and __read_mostly")
Cc: Chuansheng Liu &lt;chuansheng.liu@intel.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: Ensure ata_port probe has completed before detach</title>
<updated>2020-01-04T12:34:14+00:00</updated>
<author>
<name>John Garry</name>
<email>john.garry@huawei.com</email>
</author>
<published>2019-10-16T10:19:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20ba9b9569f39c75f9031efb26ee1b8b9fe0eb6f'/>
<id>urn:sha1:20ba9b9569f39c75f9031efb26ee1b8b9fe0eb6f</id>
<content type='text'>
[ Upstream commit 130f4caf145c3562108b245a576db30b916199d2 ]

With CONFIG_DEBUG_TEST_DRIVER_REMOVE set, we may find the following WARN:

[   23.452574] ------------[ cut here ]------------
[   23.457190] WARNING: CPU: 59 PID: 1 at drivers/ata/libata-core.c:6676 ata_host_detach+0x15c/0x168
[   23.466047] Modules linked in:
[   23.469092] CPU: 59 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00010-g5b83fd27752b-dirty #296
[   23.477776] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
[   23.486286] pstate: a0c00009 (NzCv daif +PAN +UAO)
[   23.491065] pc : ata_host_detach+0x15c/0x168
[   23.495322] lr : ata_host_detach+0x88/0x168
[   23.499491] sp : ffff800011cabb50
[   23.502792] x29: ffff800011cabb50 x28: 0000000000000007
[   23.508091] x27: ffff80001137f068 x26: ffff8000112c0c28
[   23.513390] x25: 0000000000003848 x24: ffff0023ea185300
[   23.518689] x23: 0000000000000001 x22: 00000000000014c0
[   23.523987] x21: 0000000000013740 x20: ffff0023bdc20000
[   23.529286] x19: 0000000000000000 x18: 0000000000000004
[   23.534584] x17: 0000000000000001 x16: 00000000000000f0
[   23.539883] x15: ffff0023eac13790 x14: ffff0023eb76c408
[   23.545181] x13: 0000000000000000 x12: ffff0023eac13790
[   23.550480] x11: ffff0023eb76c228 x10: 0000000000000000
[   23.555779] x9 : ffff0023eac13798 x8 : 0000000040000000
[   23.561077] x7 : 0000000000000002 x6 : 0000000000000001
[   23.566376] x5 : 0000000000000002 x4 : 0000000000000000
[   23.571674] x3 : ffff0023bf08a0bc x2 : 0000000000000000
[   23.576972] x1 : 3099674201f72700 x0 : 0000000000400284
[   23.582272] Call trace:
[   23.584706]  ata_host_detach+0x15c/0x168
[   23.588616]  ata_pci_remove_one+0x10/0x18
[   23.592615]  ahci_remove_one+0x20/0x40
[   23.596356]  pci_device_remove+0x3c/0xe0
[   23.600267]  really_probe+0xdc/0x3e0
[   23.603830]  driver_probe_device+0x58/0x100
[   23.608000]  device_driver_attach+0x6c/0x90
[   23.612169]  __driver_attach+0x84/0xc8
[   23.615908]  bus_for_each_dev+0x74/0xc8
[   23.619730]  driver_attach+0x20/0x28
[   23.623292]  bus_add_driver+0x148/0x1f0
[   23.627115]  driver_register+0x60/0x110
[   23.630938]  __pci_register_driver+0x40/0x48
[   23.635199]  ahci_pci_driver_init+0x20/0x28
[   23.639372]  do_one_initcall+0x5c/0x1b0
[   23.643199]  kernel_init_freeable+0x1a4/0x24c
[   23.647546]  kernel_init+0x10/0x108
[   23.651023]  ret_from_fork+0x10/0x18
[   23.654590] ---[ end trace 634a14b675b71c13 ]---

With KASAN also enabled, we may also get many use-after-free reports.

The issue is that when CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, we may
attempt to detach the ata_port before it has been probed.

This is because the ata_ports are async probed, meaning that there is no
guarantee that the ata_port has probed prior to detach. When the ata_port
does probe in this scenario, we get all sorts of issues as the detach may
have already happened.

Fix by ensuring synchronisation with async_synchronize_full(). We could
alternatively use the cookie returned from the ata_port probe
async_schedule() call, but that means managing the cookie, so more
complicated.

Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: ep93xx: Use proper enums for directions</title>
<updated>2019-11-25T14:54:36+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>natechancellor@gmail.com</email>
</author>
<published>2018-10-04T02:37:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c4503c8ec56d38c17052e2129668f3b454559c58'/>
<id>urn:sha1:c4503c8ec56d38c17052e2129668f3b454559c58</id>
<content type='text'>
[ Upstream commit 6adde4a36f1b6a562a1057fbb1065007851050e7 ]

Clang warns when one enumerated type is implicitly converted to another.

drivers/ata/pata_ep93xx.c:662:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
        drv_data-&gt;dma_rx_data.direction = DMA_FROM_DEVICE;
                                        ~ ^~~~~~~~~~~~~~~
drivers/ata/pata_ep93xx.c:670:36: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
        drv_data-&gt;dma_tx_data.direction = DMA_TO_DEVICE;
                                        ~ ^~~~~~~~~~~~~
drivers/ata/pata_ep93xx.c:681:19: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
        conf.direction = DMA_FROM_DEVICE;
                       ~ ^~~~~~~~~~~~~~~
drivers/ata/pata_ep93xx.c:692:19: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
        conf.direction = DMA_TO_DEVICE;
                       ~ ^~~~~~~~~~~~~

Use the equivalent valued enums from the expected type so that Clang no
longer warns about a conversion.

DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1
DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2

Acked-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: have ata_scsi_rw_xlat() fail invalid passthrough requests</title>
<updated>2019-11-25T14:54:26+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@kernel.dk</email>
</author>
<published>2019-08-07T18:20:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d784a2d4a0e302f51f6d96f44f5c21de47d6f19'/>
<id>urn:sha1:5d784a2d4a0e302f51f6d96f44f5c21de47d6f19</id>
<content type='text'>
commit 2d7271501720038381d45fb3dcbe4831228fc8cc upstream.

For passthrough requests, libata-scsi takes what the user passes in
as gospel. This can be problematic if the user fills in the CDB
incorrectly. One example of that is in request sizes. For read/write
commands, the CDB contains fields describing the transfer length of
the request. These should match with the SG_IO header fields, but
libata-scsi currently does no validation of that.

Check that the number of blocks in the CDB for passthrough requests
matches what was mapped into the request. If the CDB asks for more
data then the validated SG_IO header fields, error it.

Reported-by: Krishna Ram Prakash R &lt;krp@gtux.in&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: add SG safety checks in SFF pio transfers</title>
<updated>2019-09-06T08:18:08+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@kernel.dk</email>
</author>
<published>2019-08-07T18:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d2b2a7dd72c6c6cb5bac6b96d8b6bb31ca227825'/>
<id>urn:sha1:d2b2a7dd72c6c6cb5bac6b96d8b6bb31ca227825</id>
<content type='text'>
[ Upstream commit 752ead44491e8c91e14d7079625c5916b30921c5 ]

Abort processing of a command if we run out of mapped data in the
SG list. This should never happen, but a previous bug caused it to
be possible. Play it safe and attempt to abort nicely if we don't
have more SG segments left.

Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: libahci: do not complain in case of deferred probe</title>
<updated>2019-08-25T08:53:00+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2019-07-31T12:26:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b31030dacc653d21b4ebd0a8d04495b5af7804e'/>
<id>urn:sha1:7b31030dacc653d21b4ebd0a8d04495b5af7804e</id>
<content type='text'>
[ Upstream commit 090bb803708198e5ab6b0046398c7ed9f4d12d6b ]

Retrieving PHYs can defer the probe, do not spawn an error when
-EPROBE_DEFER is returned, it is normal behavior.

Fixes: b1a9edbda040 ("ata: libahci: allow to use multiple PHYs")
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
