<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/ata, branch v2.6.28.9</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>ata_piix: add workaround for Samsung DB-P70</title>
<updated>2009-03-23T21:55:26+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2009-03-03T04:52:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8a9b7134f8c43ff0a5ad6deebf94a37d13630ef9'/>
<id>8a9b7134f8c43ff0a5ad6deebf94a37d13630ef9</id>
<content type='text'>
commit e9c1670c2a14ef9cc20d86b24b829f3947aad34e upstream.

Samsung DB-P70 somehow botched the first ICH9 SATA port.  The board
doesn't expose the first port but somehow SStatus reports link online
while failing SRST protocol leading to repeated probe failures and
thus long boot delay.

Because the BIOS doesn't carry any identifying DMI information, the
port can't be blacklisted safely.  Fortunately, the controller does
have subsystem vendor and ID set.  It's unclear whether the subsystem
IDs are used only for the board but it can be safely worked around by
disabling SIDPR access and just using SRST works around the problem.
Even when the workaround is triggered on an unaffected board the only
side effect will be missing SCR access.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Joseph Jang &lt;josephjang@gmail.com&gt;
Reported-by: Jonghyon Sohn &lt;mrsohn@gmail.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e9c1670c2a14ef9cc20d86b24b829f3947aad34e upstream.

Samsung DB-P70 somehow botched the first ICH9 SATA port.  The board
doesn't expose the first port but somehow SStatus reports link online
while failing SRST protocol leading to repeated probe failures and
thus long boot delay.

Because the BIOS doesn't carry any identifying DMI information, the
port can't be blacklisted safely.  Fortunately, the controller does
have subsystem vendor and ID set.  It's unclear whether the subsystem
IDs are used only for the board but it can be safely worked around by
disabling SIDPR access and just using SRST works around the problem.
Even when the workaround is triggered on an unaffected board the only
side effect will be missing SCR access.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: Joseph Jang &lt;josephjang@gmail.com&gt;
Reported-by: Jonghyon Sohn &lt;mrsohn@gmail.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libata: make sure port is thawed when skipping resets</title>
<updated>2009-03-17T00:32:19+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2009-03-04T06:59:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=50d4eeb0d1d7eed0f13726be4dbb4c4b637e3a9b'/>
<id>50d4eeb0d1d7eed0f13726be4dbb4c4b637e3a9b</id>
<content type='text'>
commit d6515e6ff4ad3db4bd5ef2dd4e1026a7aca2482e upstream.

When SCR access is available and the link is offline, softreset is
skipped as it only wastes time and some controllers don't respond very
well.  However, the skip path forgot to thaw the port, which not only
blocks further event notification from the port but also causes
repeated EH invocations on the same event on drivers which rely on
-&gt;thaw() to clear events if the IRQ is shared with another device or
port.

This problem has always been there but is uncovered by recent sata_nv
nf2/3 change which dropped hardreset support while maintaining SCR
access.  nf2/3 doesn't clear hotplug event mask from the interrupt
handler but relies on -&gt;thaw() to clear them.  When the hardreset was
there, the reset action was never skipped and the port was always
thawed but, with the hardreset gone, -&gt;prereset() determines that
there's no need for softreset and both -&gt;softreset() and -&gt;thaw() are
skipped.  This leads to stuck hotplug event in the IRQ status register
triggering hotplug event whenever IRQ is delieverd on the same IRQ.
As the controller shares the same IRQ for both ports, this happens on
every IO if one port is occpupied and the other isn't.

This patch fixes the problem by making sure that the port is thawed on
reset-skip path.

bko#11615 reports this problem.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Robert Hancock &lt;hancockrwd@gmail.com&gt;
Reported-by: Dan Andresan &lt;danyer@gmail.com&gt;
Reported-by: Arne Woerner &lt;arne_woerner@yahoo.com&gt;
Reported-by: Stefan Lippers-Hollmann &lt;s.L-H@gmx.de&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d6515e6ff4ad3db4bd5ef2dd4e1026a7aca2482e upstream.

When SCR access is available and the link is offline, softreset is
skipped as it only wastes time and some controllers don't respond very
well.  However, the skip path forgot to thaw the port, which not only
blocks further event notification from the port but also causes
repeated EH invocations on the same event on drivers which rely on
-&gt;thaw() to clear events if the IRQ is shared with another device or
port.

This problem has always been there but is uncovered by recent sata_nv
nf2/3 change which dropped hardreset support while maintaining SCR
access.  nf2/3 doesn't clear hotplug event mask from the interrupt
handler but relies on -&gt;thaw() to clear them.  When the hardreset was
there, the reset action was never skipped and the port was always
thawed but, with the hardreset gone, -&gt;prereset() determines that
there's no need for softreset and both -&gt;softreset() and -&gt;thaw() are
skipped.  This leads to stuck hotplug event in the IRQ status register
triggering hotplug event whenever IRQ is delieverd on the same IRQ.
As the controller shares the same IRQ for both ports, this happens on
every IO if one port is occpupied and the other isn't.

This patch fixes the problem by making sure that the port is thawed on
reset-skip path.

bko#11615 reports this problem.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Robert Hancock &lt;hancockrwd@gmail.com&gt;
Reported-by: Dan Andresan &lt;danyer@gmail.com&gt;
Reported-by: Arne Woerner &lt;arne_woerner@yahoo.com&gt;
Reported-by: Stefan Lippers-Hollmann &lt;s.L-H@gmx.de&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libata: Don't trust current capacity values in identify words 57-58</title>
<updated>2009-03-17T00:32:19+00:00</updated>
<author>
<name>Robert Hancock</name>
<email>hancockrwd@gmail.com</email>
</author>
<published>2009-02-17T02:15:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=66cab028a8a4139cd513b9a35080bc249733d17b'/>
<id>66cab028a8a4139cd513b9a35080bc249733d17b</id>
<content type='text'>
commit 968e594afdbc40b4270f9d4032ae8350475749d6 upstream.

Hanno Böck reported a problem where an old Conner CP30254 240MB hard drive
was reported as 1.1TB in capacity by libata:

http://lkml.org/lkml/2009/2/13/134

This was caused by libata trusting the drive's reported current capacity in
sectors in identify words 57 and 58 if the drive does not support LBA and the
current CHS translation values appear valid. Unfortunately it seems older
ATA specs were vague about what this field should contain and a number of drives
used values with wrong byte order or that were totally bogus. There's no
unique information that it conveys and so we can just calculate the number
of sectors from the reported current CHS values.

While we're at it, clean up this function to use named constants for the
identify word values.

Signed-off-by: Robert Hancock &lt;hancockrwd@gmail.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 968e594afdbc40b4270f9d4032ae8350475749d6 upstream.

Hanno Böck reported a problem where an old Conner CP30254 240MB hard drive
was reported as 1.1TB in capacity by libata:

http://lkml.org/lkml/2009/2/13/134

This was caused by libata trusting the drive's reported current capacity in
sectors in identify words 57 and 58 if the drive does not support LBA and the
current CHS translation values appear valid. Unfortunately it seems older
ATA specs were vague about what this field should contain and a number of drives
used values with wrong byte order or that were totally bogus. There's no
unique information that it conveys and so we can just calculate the number
of sectors from the reported current CHS values.

While we're at it, clean up this function to use named constants for the
identify word values.

Signed-off-by: Robert Hancock &lt;hancockrwd@gmail.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Add support for VT6415 PCIE PATA IDE Host Controller</title>
<updated>2009-02-20T22:40:21+00:00</updated>
<author>
<name>Zlatko Calusic</name>
<email>zlatko.calusic@iskon.hr</email>
</author>
<published>2009-02-18T00:33:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=95cfc84fd09cb77669da9ae6e9ad5ced027ca483'/>
<id>95cfc84fd09cb77669da9ae6e9ad5ced027ca483</id>
<content type='text'>
commit 5955c7a2cfb6a35429adea5dc480002b15ca8cfc upstream.

Signed-off-by: Zlatko Calusic &lt;zlatko.calusic@iskon.hr&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5955c7a2cfb6a35429adea5dc480002b15ca8cfc upstream.

Signed-off-by: Zlatko Calusic &lt;zlatko.calusic@iskon.hr&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sata_nv: give up hardreset on nf2</title>
<updated>2009-02-20T22:40:18+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2009-02-12T01:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2d554b617ee692633b99c5e1c15cfb983443bd8c'/>
<id>2d554b617ee692633b99c5e1c15cfb983443bd8c</id>
<content type='text'>
commit 7dac745b8e367c99175b8f0d014d996f0e5ed9e5 upstream.

Kernel bz#12176 reports that nf2 hardreset simply doesn't work.  Give
up.  Argh...

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Robert Hancock &lt;hancockr@shaw.ca&gt;
Reported-by: Saro &lt;saro_v@hotmail.it&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7dac745b8e367c99175b8f0d014d996f0e5ed9e5 upstream.

Kernel bz#12176 reports that nf2 hardreset simply doesn't work.  Give
up.  Argh...

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Robert Hancock &lt;hancockr@shaw.ca&gt;
Reported-by: Saro &lt;saro_v@hotmail.it&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libata: fix EH device failure handling</title>
<updated>2009-02-17T17:29:03+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2009-01-29T11:31:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1d40aaebcbcac89b609841425eb0018488dc24fe'/>
<id>1d40aaebcbcac89b609841425eb0018488dc24fe</id>
<content type='text'>
commit d89293abd95bfd7dd9229087d6c30c1464c5ac83 upstream.

The dev-&gt;pio_mode &gt; XFER_PIO_0 test is there to avoid unnecessary
speed down warning messages but it accidentally disabled SATA link spd
down during configuration phase after reset where PIO mode is always
zero.

This patch fixes the problem by moving the test where it belongs.
This makes libata probing sequence behave better when the connection
is flaky at higher link speeds which isn't too uncommon for eSATA
devices.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d89293abd95bfd7dd9229087d6c30c1464c5ac83 upstream.

The dev-&gt;pio_mode &gt; XFER_PIO_0 test is there to avoid unnecessary
speed down warning messages but it accidentally disabled SATA link spd
down during configuration phase after reset where PIO mode is always
zero.

This patch fixes the problem by moving the test where it belongs.
This makes libata probing sequence behave better when the connection
is flaky at higher link speeds which isn't too uncommon for eSATA
devices.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sata_via: Add VT8261 support</title>
<updated>2009-02-12T17:50:38+00:00</updated>
<author>
<name>JosephChan@via.com.tw</name>
<email>JosephChan@via.com.tw</email>
</author>
<published>2009-01-16T11:44:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f5d7b376ef4ef7acde7049d2c0f6222ccfcd964c'/>
<id>f5d7b376ef4ef7acde7049d2c0f6222ccfcd964c</id>
<content type='text'>
commit 6813952021a7820a505002de260bda36978671f7 upstream.

Signed-off-by: Joseph Chan &lt;josephchan@via.com.tw&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6813952021a7820a505002de260bda36978671f7 upstream.

Signed-off-by: Joseph Chan &lt;josephchan@via.com.tw&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sata_mv: Fix chip type for Hightpoint RocketRaid 1740/1742</title>
<updated>2009-02-06T21:47:24+00:00</updated>
<author>
<name>Mark Lord</name>
<email>liml@rtr.ca</email>
</author>
<published>2009-01-27T21:33:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1b3826f5b9b1b9e3e60300080834b8979e63bd94'/>
<id>1b3826f5b9b1b9e3e60300080834b8979e63bd94</id>
<content type='text'>
commit 4462254ac6be9150aae87d54d388fc348d6fcead upstream.

Fix chip type for the Highpoint RocketRAID 1740 and 1742 PCI cards.
These really do have Marvell 6042 chips on them, rather than the 5081 chip.

Confirmed by multiple (two) users (for the 1740), and by examining
the product photographs from Highpoint's web site.

Signed-off-by: Mark Lord &lt;mlord@pobox.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4462254ac6be9150aae87d54d388fc348d6fcead upstream.

Fix chip type for the Highpoint RocketRAID 1740 and 1742 PCI cards.
These really do have Marvell 6042 chips on them, rather than the 5081 chip.

Confirmed by multiple (two) users (for the 1740), and by examining
the product photographs from Highpoint's web site.

Signed-off-by: Mark Lord &lt;mlord@pobox.com&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sata_nv: ck804 has borked hardreset too</title>
<updated>2009-02-06T21:47:19+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2009-02-01T01:56:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8550890004fb0220bef61604d82a96fb183e2b82'/>
<id>8550890004fb0220bef61604d82a96fb183e2b82</id>
<content type='text'>
commit 8d993eaa9c3c61b8a5929a7f695078a1fcfb4869 upstream.

While playing with nvraid, I found out that rmmoding and insmoding
often trigger hardreset failure on the first port (the second one was
always okay).  Seriously, how diverse can you get with hardreset
behaviors?  Anyways, make ck804 use noclassify variant too.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8d993eaa9c3c61b8a5929a7f695078a1fcfb4869 upstream.

While playing with nvraid, I found out that rmmoding and insmoding
often trigger hardreset failure on the first port (the second one was
always okay).  Seriously, how diverse can you get with hardreset
behaviors?  Anyways, make ck804 use noclassify variant too.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sata_nv: fix MCP5x reset</title>
<updated>2009-02-06T21:47:19+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2009-01-25T02:29:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bd646a877c03473f3f736a54d54ca15735c45255'/>
<id>bd646a877c03473f3f736a54d54ca15735c45255</id>
<content type='text'>
commit 2d775708bc6613f1be47f1e720781343341ecc94 upstream.

MCP5x family of controllers seem to share much more with nf2's as far
as reset protocol is concerned.  It requires heardreset to get the PHY
going and classfication code report after hardreset is unreliable.
Create a new board type MCP5x and use noclassify hardreset.  SWNCQ is
modified to inherit from this new type.

This fixes hotplug regression reported in kernel bz#12351.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2d775708bc6613f1be47f1e720781343341ecc94 upstream.

MCP5x family of controllers seem to share much more with nf2's as far
as reset protocol is concerned.  It requires heardreset to get the PHY
going and classfication code report after hardreset is unreliable.
Create a new board type MCP5x and use noclassify hardreset.  SWNCQ is
modified to inherit from this new type.

This fixes hotplug regression reported in kernel bz#12351.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
