<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/ata/libata-core.c, branch v4.14.286</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.286</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.286'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-06-25T09:46:42+00:00</updated>
<entry>
<title>ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()</title>
<updated>2022-06-25T09:46:42+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omp.ru</email>
</author>
<published>2022-05-21T20:34:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ac5efee33f29e704226506d429b84575a5d66f8'/>
<id>urn:sha1:1ac5efee33f29e704226506d429b84575a5d66f8</id>
<content type='text'>
[ Upstream commit bf476fe22aa1851bab4728e0c49025a6a0bea307 ]

In an unlikely (and probably wrong?) case that the 'ppi' parameter of
ata_host_alloc_pinfo() points to an array starting with a NULL pointer,
there's going to be a kernel oops as the 'pi' local variable won't get
reassigned from the initial value of NULL. Initialize 'pi' instead to
'&amp;ata_dummy_port_info' to fix the possible kernel oops for good...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.

Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omp.ru&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs</title>
<updated>2022-04-20T07:08:32+00:00</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@gmail.com</email>
</author>
<published>2022-03-19T20:11:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9599f3668d2e479388daf5b9a57ab31abcb7e2fe'/>
<id>urn:sha1:9599f3668d2e479388daf5b9a57ab31abcb7e2fe</id>
<content type='text'>
[ Upstream commit 5399752299396a3c9df6617f4b3c907d7aa4ded8 ]

Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
the a message: "READ LOG DMA EXT failed, trying PIO" during boot.

Initially this was discovered because it caused a crash
with the sata_dwc_460ex controller on a WD MyBook Live DUO.

The reporter "Tice Rex" which has the unique opportunity that he
has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q"
which booted fine and didn't expose "READ LOG DMA EXT". But the
newer/latest firmware "EXT0DB6Q" caused the headaches.

BugLink: https://github.com/openwrt/openwrt/issues/9505
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: libata-core: Disable TRIM on M88V29</title>
<updated>2022-02-23T10:57:36+00:00</updated>
<author>
<name>Zoltán Böszörményi</name>
<email>zboszor@gmail.com</email>
</author>
<published>2022-02-04T12:57:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ccfd0ab5290a1ccd448bf7c492c3e1c4eac2ce36'/>
<id>urn:sha1:ccfd0ab5290a1ccd448bf7c492c3e1c4eac2ce36</id>
<content type='text'>
[ Upstream commit c8ea23d5fa59f28302d4e3370c75d9c308e64410 ]

This device is a CF card, or possibly an SSD in CF form factor.
It supports NCQ and high speed DMA.

While it also advertises TRIM support, I/O errors are reported
when the discard mount option fstrim is used. TRIM also fails
when disabling NCQ and not just as an NCQ command.

TRIM must be disabled for this device.

Signed-off-by: Zoltán Böszörményi &lt;zboszor@gmail.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: add horkage for ASMedia 1092</title>
<updated>2021-12-14T09:16:55+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2021-12-08T06:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=09297c39f40ace29b5ebec832d1f0ed1c6772725'/>
<id>urn:sha1:09297c39f40ace29b5ebec832d1f0ed1c6772725</id>
<content type='text'>
commit a66307d473077b7aeba74e9b09c841ab3d399c2d upstream.

The ASMedia 1092 has a configuration mode which will present a
dummy device; sadly the implementation falsely claims to provide
a device with 100M which doesn't actually exist.
So disable this device to avoid errors during boot.

Cc: stable@vger.kernel.org
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libata: fix checking of DMA state</title>
<updated>2021-11-26T10:40:24+00:00</updated>
<author>
<name>Reimar Döffinger</name>
<email>Reimar.Doeffinger@gmx.de</email>
</author>
<published>2021-10-12T06:27:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2404b4ae1f539817576c92c941b7d10c6b412c7c'/>
<id>urn:sha1:2404b4ae1f539817576c92c941b7d10c6b412c7c</id>
<content type='text'>
commit f971a85439bd25dc7b4d597cf5e4e8dc7ffc884b upstream.

Checking if DMA is enabled should be done via the
ata_dma_enabled helper function, since the init state
0xff indicates disabled.
This meant that ATA_CMD_READ_LOG_DMA_EXT was used and probed
for before DMA was enabled, which caused hangs for some combinations
of controllers and devices.
It might also have caused it to be incorrectly disabled as broken,
but there have been no reports of that.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195895
Signed-off-by: Reimar Döffinger &lt;Reimar.Doeffinger@gmx.de&gt;
Tested-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@wdc.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libata: Add ATA_HORKAGE_NO_NCQ_ON_ATI for Samsung 860 and 870 SSD.</title>
<updated>2021-10-09T12:09:46+00:00</updated>
<author>
<name>Kate Hsuan</name>
<email>hpa@redhat.com</email>
</author>
<published>2021-09-03T09:44:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b1aa3a135c7be2b41134f938fc9769273246ad25'/>
<id>urn:sha1:b1aa3a135c7be2b41134f938fc9769273246ad25</id>
<content type='text'>
commit 7a8526a5cd51cf5f070310c6c37dd7293334ac49 upstream.

Many users are reporting that the Samsung 860 and 870 SSD are having
various issues when combined with AMD/ATI (vendor ID 0x1002)  SATA
controllers and only completely disabling NCQ helps to avoid these
issues.

Always disabling NCQ for Samsung 860/870 SSDs regardless of the host
SATA adapter vendor will cause I/O performance degradation with well
behaved adapters. To limit the performance impact to ATI adapters,
introduce the ATA_HORKAGE_NO_NCQ_ON_ATI flag to force disable NCQ
only for these adapters.

Also, two libata.force parameters (noncqati and ncqati) are introduced
to disable and enable the NCQ for the system which equipped with ATI
SATA adapter and Samsung 860 and 870 SSDs. The user can determine NCQ
function to be enabled or disabled according to the demand.

After verifying the chipset from the user reports, the issue appears
on AMD/ATI SB7x0/SB8x0/SB9x0 SATA Controllers and does not appear on
recent AMD SATA adapters. The vendor ID of ATI should be 0x1002.
Therefore, ATA_HORKAGE_NO_NCQ_ON_AMD was modified to
ATA_HORKAGE_NO_NCQ_ON_ATI.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201693
Signed-off-by: Kate Hsuan &lt;hpa@redhat.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Link: https://lore.kernel.org/r/20210903094411.58749-1-hpa@redhat.com
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Krzysztof Olędzki &lt;ole@ans.pl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libata: add ATA_HORKAGE_NO_NCQ_TRIM for Samsung 860 and 870 SSDs</title>
<updated>2021-09-22T09:45:25+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2021-08-23T09:52:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8752572a023e6203cfef915da018dfccdb319a0f'/>
<id>urn:sha1:8752572a023e6203cfef915da018dfccdb319a0f</id>
<content type='text'>
commit 8a6430ab9c9c87cb64c512e505e8690bbaee190b upstream.

Commit ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860")
limited the existing ATA_HORKAGE_NO_NCQ_TRIM quirk from "Samsung SSD 8*",
covering all Samsung 800 series SSDs, to only apply to "Samsung SSD 840*"
and "Samsung SSD 850*" series based on information from Samsung.

But there is a large number of users which is still reporting issues
with the Samsung 860 and 870 SSDs combined with Intel, ASmedia or
Marvell SATA controllers and all reporters also report these problems
going away when disabling queued trims.

Note that with AMD SATA controllers users are reporting even worse
issues and only completely disabling NCQ helps there, this will be
addressed in a separate patch.

Fixes: ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203475
Cc: stable@vger.kernel.org
Cc: Kate Hsuan &lt;hpa@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Damien Le Moal &lt;damien.lemoal@wdc.com&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Link: https://lore.kernel.org/r/20210823095220.30157-1-hdegoede@redhat.com
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: fix ata_host_start()</title>
<updated>2021-09-22T09:45:18+00:00</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@wdc.com</email>
</author>
<published>2021-08-16T01:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eabc00ee992dd6b5e9a404eed516e12a03e85095'/>
<id>urn:sha1:eabc00ee992dd6b5e9a404eed516e12a03e85095</id>
<content type='text'>
[ Upstream commit 355a8031dc174450ccad2a61c513ad7222d87a97 ]

The loop on entry of ata_host_start() may not initialize host-&gt;ops to a
non NULL value. The test on the host_stop field of host-&gt;ops must then
be preceded by a check that host-&gt;ops is not NULL.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@wdc.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Link: https://lore.kernel.org/r/20210816014456.2191776-3-damien.lemoal@wdc.com
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: make qc_prep return ata_completion_errors</title>
<updated>2020-10-01T11:12:52+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2019-10-31T09:59:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=306a1c5b5683c1d37565e575386139a64bdbec6f'/>
<id>urn:sha1:306a1c5b5683c1d37565e575386139a64bdbec6f</id>
<content type='text'>
commit 95364f36701e62dd50eee91e1303187fd1a9f567 upstream.

In case a driver wants to return an error from qc_prep, return enum
ata_completion_errors. sata_mv is one of those drivers -- see the next
patch. Other drivers return the newly defined AC_ERR_OK.

[v2] use enum ata_completion_errors and AC_ERR_OK.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: linux-ide@vger.kernel.org
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: implement ATA_HORKAGE_MAX_TRIM_128M and apply to Sandisks</title>
<updated>2020-09-09T17:03:12+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2020-09-02T16:32:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7819f78f87e0f0ec3347a7a98f8b671931c2f11b'/>
<id>urn:sha1:7819f78f87e0f0ec3347a7a98f8b671931c2f11b</id>
<content type='text'>
commit 3b5455636fe26ea21b4189d135a424a6da016418 upstream.

All three generations of Sandisk SSDs lock up hard intermittently.
Experiments showed that disabling NCQ lowered the failure rate significantly
and the kernel has been disabling NCQ for some models of SD7's and 8's,
which is obviously undesirable.

Karthik worked with Sandisk to root cause the hard lockups to trim commands
larger than 128M. This patch implements ATA_HORKAGE_MAX_TRIM_128M which
limits max trim size to 128M and applies it to all three generations of
Sandisk SSDs.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Karthik Shivaram &lt;karthikgs@fb.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
