<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/ata, branch v3.10.44</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.44</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.44'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-06-16T20:42:54Z</updated>
<entry>
<title>ahci: add PCI ID for Marvell 88SE91A0 SATA Controller</title>
<updated>2014-06-16T20:42:54Z</updated>
<author>
<name>Andreas Schrägle</name>
<email>ajs124.ajs124@gmail.com</email>
</author>
<published>2014-05-24T14:35:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7d872bd011c20e1efbcb95461bffabd140cf4e81'/>
<id>urn:sha1:7d872bd011c20e1efbcb95461bffabd140cf4e81</id>
<content type='text'>
commit 754a292fe6b08196cb135c03b404444e17de520a upstream.

Add support for Marvell Technology Group Ltd. 88SE91A0 SATA 6Gb/s
Controller by adding its PCI ID.

Signed-off-by: Andreas Schrägle &lt;ajs124.ajs124@gmail.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>ahci: Add Device ID for HighPoint RocketRaid 642L</title>
<updated>2014-06-16T20:42:54Z</updated>
<author>
<name>Jérôme Carretero</name>
<email>cJ-ko@zougloub.eu</email>
</author>
<published>2014-06-03T18:56:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=18958498381a47eafd7f2850513e0fdc91e15e01'/>
<id>urn:sha1:18958498381a47eafd7f2850513e0fdc91e15e01</id>
<content type='text'>
commit d251836508fb26cd1a22b41381739835ee23728d upstream.

This device normally comes with a proprietary driver, using a web GUI
to configure RAID:
 http://www.highpoint-tech.com/USA_new/series_rr600-download.htm
But thankfully it also works out of the box with the AHCI driver,
being just a Marvell 88SE9235.

Devices 640L, 644L, 644LS should also be supported but not tested here.

Signed-off-by: Jérôme Carretero &lt;cJ-ko@zougloub.eu&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: clean up ZPODD when a port is detached</title>
<updated>2014-06-07T20:25:39Z</updated>
<author>
<name>Levente Kurusa</name>
<email>levex@linux.com</email>
</author>
<published>2014-05-06T13:57:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a40aac07285bdf77ed67af1423676ff5548ef51b'/>
<id>urn:sha1:a40aac07285bdf77ed67af1423676ff5548ef51b</id>
<content type='text'>
commit a6f9bf4d2f965b862b95213303d154e02957eed8 upstream.

When a ZPODD device is unbound via sysfs, the ACPI notify handler
is not removed. This causes panics as observed in Bug #74601. The
panic only happens when the wake happens from outside the kernel
(i.e. inserting a media or pressing a button). Add a loop to
ata_port_detach which loops through the port's devices and checks
if zpodd is enabled, if so call zpodd_exit.

Reviewed-by: Aaron Lu &lt;aaron.lu@intel.com&gt;
Signed-off-by: Levente Kurusa &lt;levex@linux.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>pata_at91: fix ata_host_activate() failure handling</title>
<updated>2014-06-07T20:25:29Z</updated>
<author>
<name>Bartlomiej Zolnierkiewicz</name>
<email>b.zolnierkie@samsung.com</email>
</author>
<published>2014-03-31T17:51:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2ec453bfa65175f1dcf34b6f0ea0539b0e949b5b'/>
<id>urn:sha1:2ec453bfa65175f1dcf34b6f0ea0539b0e949b5b</id>
<content type='text'>
commit 27aa64b9d1bd0d23fd692c91763a48309b694311 upstream.

Add missing clk_put() call to ata_host_activate() failure path.

Sergei says,

  "Hm, I have once fixed that (see that *if* (!ret)) but looks like a
   later commit 477c87e90853d136b188c50c0e4a93d01cad872e (ARM:
   at91/pata: use gpio_is_valid to check the gpio) broke it again. :-(
   Would be good if the changelog did mention that..."

Cc: Andrew Victor &lt;linux@maxim.org.za&gt;
Cc: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Cc: Jean-Christophe Plagniol-Villard &lt;plagnioj@jcrosoft.com&gt;
Cc: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.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/ahci: accommodate tag ordered controllers</title>
<updated>2014-05-13T11:59:43Z</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2014-04-17T18:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cfd192c9983ea4e993cabf4f899ef587f31ab51e'/>
<id>urn:sha1:cfd192c9983ea4e993cabf4f899ef587f31ab51e</id>
<content type='text'>
commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.

The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:

	5.3.2.12 P:SelectCmd
	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
	or HBA selects the command to issue that has had the
	PxCI bit set to '1' longer than any other command
	pending to be issued.

The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.

This behavior has likely been hidden by drives that arrange for commands
to complete in issue order.  However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course.  So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.

This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.

Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio.  Also, word is that recent versions of an unnamed
OS also does it this way now.  So, drives in the field are already
experienced with this tag ordering scheme.

Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ed Ciechanowski &lt;ed.ciechanowski@intel.com&gt;
Reviewed-by: Matthew Wilcox &lt;matthew.r.wilcox@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.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: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001)</title>
<updated>2014-03-24T04:38:16Z</updated>
<author>
<name>Michele Baldessari</name>
<email>michele@acksyn.org</email>
</author>
<published>2014-03-07T16:34:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2e44c866bfcea9dcd77dda2c77f03f6d042aade7'/>
<id>urn:sha1:2e44c866bfcea9dcd77dda2c77f03f6d042aade7</id>
<content type='text'>
commit b28a613e9138e4b3a64649bd60b13436f4b4b49b upstream.

Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
for Seagate Momentus SpinPoint M8" we added a quirk for disks named
"ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".

As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901,
we need to also add firmware revision 2BA30001 as it is broken as well.

Reported-by: Nicholas &lt;arealityfarbetween@googlemail.com&gt;
Signed-off-by: Michele Baldessari &lt;michele@acksyn.org&gt;
Tested-by: Guilherme Amadio &lt;guilherme.amadio@gmail.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>sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN</title>
<updated>2014-03-07T05:30:09Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-02-03T15:42:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=599b45bd7f7f8e467d521f4d709bd7af7e8bc132'/>
<id>urn:sha1:599b45bd7f7f8e467d521f4d709bd7af7e8bc132</id>
<content type='text'>
commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.

It's a bit odd to see a newer device showing mod15write; however, the
reported behavior is highly consistent and other factors which could
contribute seem to have been verified well enough.  Also, both
sata_sil itself and the drive are fairly outdated at this point making
the risk of this change fairly low.  It is possible, probably likely,
that other drive models in the same family have the same problem;
however, for now, let's just add the specific model which was tested.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: matson &lt;lists-matsonpa@luxsci.me&gt;
References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ata: enable quirk from jmicron JMB350 for JMB394</title>
<updated>2014-03-07T05:30:08Z</updated>
<author>
<name>Denis V. Lunev</name>
<email>den@openvz.org</email>
</author>
<published>2014-01-30T11:20:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=69f554c94a4e0dce7d933358dec416b74b6424a6'/>
<id>urn:sha1:69f554c94a4e0dce7d933358dec416b74b6424a6</id>
<content type='text'>
commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.

Without the patch the kernel generates the following error.

 ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
 ata11.15: PMP revalidation failed (errno=-19)
 ata11.15: failed to recover PMP after 5 tries, giving up

This patch helps to bypass this error and the device becomes
functional.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: &lt;linux-ide@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ahci: disable NCQ on Samsung pci-e SSDs on macbooks</title>
<updated>2014-03-07T05:30:08Z</updated>
<author>
<name>Levente Kurusa</name>
<email>levex@linux.com</email>
</author>
<published>2014-02-18T15:22:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=aa5b8c451354afccde1a54326b79e59aa648edf4'/>
<id>urn:sha1:aa5b8c451354afccde1a54326b79e59aa648edf4</id>
<content type='text'>
commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.

Samsung's pci-e SSDs with device ID 0x1600 which are found on some
macbooks time out on NCQ commands.  Blacklist NCQ on the device so
that the affected machines can at least boot.

Original-patch-by: Levente Kurusa &lt;levex@linux.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: disable LPM for some WD SATA-I devices</title>
<updated>2014-02-06T19:08:16Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-01-16T14:47:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f07b772da47ad954573b1ffe6ebd4df1b59bf656'/>
<id>urn:sha1:f07b772da47ad954573b1ffe6ebd4df1b59bf656</id>
<content type='text'>
commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.

For some reason, some early WD drives spin up and down drives
erratically when the link is put into slumber mode which can reduce
the life expectancy of the device significantly.  Unfortunately, we
don't have full list of devices and given the nature of the issue it'd
be better to err on the side of false positives than the other way
around.  Let's disable LPM on all WD devices which match one of the
known problematic model prefixes and are SATA-I.

As horkage list doesn't support matching SATA capabilities, this is
implemented as two horkages - WD_BROKEN_LPM and NOLPM.  The former is
set for the known prefixes and sets the latter if the matched device
is SATA-I.

Note that this isn't optimal as this disables all LPM operations and
partial link power state reportedly works fine on these; however, the
way LPM is implemented in libata makes it difficult to precisely map
libata LPM setting to specific link power state.  Well, these devices
are already fairly outdated.  Let's just disable whole LPM for now.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-and-tested-by: Nikos Barkas &lt;levelwol@gmail.com&gt;
Reported-and-tested-by: Ioannis Barkas &lt;risc4all@yahoo.com&gt;
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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