linux-toradex.git/drivers/ata, branch v2.6.27.56

libata: disable ATAPI AN by default

2010-07-05T18:08:41+00:00

commit e7ecd435692ca9bde9d124be30b3a26e672ea6c2 upstream.

There are ATAPI devices which raise AN when hit by commands issued by
open().  This leads to infinite loop of AN -> MEDIA_CHANGE uevent ->
udev open() to check media -> AN.

Both ACS and SerialATA standards don't define in which case ATAPI
devices are supposed to raise or not raise AN.  They both list media
insertion event as a possible use case for ATAPI ANs but there is no
clear description of what constitutes such events.  As such, it seems
a bit too naive to export ANs directly to userland as MEDIA_CHANGE
events without further verification (which should behave similarly to
windows as it apparently is the only thing that some hardware vendors
are testing against).

This patch adds libata.atapi_an module parameter and disables ATAPI AN
by default for now.

Signed-off-by: Tejun Heo 
Cc: Kay Sievers 
Cc: Nick Bowler 
Cc: David Zeuthen 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: retry FS IOs even if it has failed with AC_ERR_INVALID

2010-05-26T21:27:08+00:00

commit 534ead709235b967b659947c55d9130873a432c4 upstream.

libata currently doesn't retry if a command fails with AC_ERR_INVALID
assuming that retrying won't get it any further even if retried.
However, a failure may be classified as invalid through hardware
glitch (incorrect reading of the error register or firmware bug) and
there isn't whole lot to gain by not retrying as actually invalid
commands will be failed immediately.  Also, commands serving FS IOs
are extremely unlikely to be invalid.  Retry FS IOs even if it's
marked invalid.

Transient and incorrect invalid failure was seen while debugging
firmware related issue on Samsung n130 on bko#14314.

  http://bugzilla.kernel.org/show_bug.cgi?id=14314

Signed-off-by: Tejun Heo 
Reported-by: Johannes Stezenbach 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: ensure NCQ error result taskfile is fully initialized before returning it via qc->result_tf.

2010-05-26T21:27:08+00:00

commit a09bf4cd53b8ab000197ef81f15d50f29ecf973c upstream.

Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

pata_cmd64x: fix overclocking of UDMA0-2 modes

2010-01-06T23:17:09+00:00

commit 509426bd46ad0903dca409803e0ee3d30f99f1e8 upstream.

adev->dma_mode stores the transfer mode value not UDMA mode number
so the condition in cmd64x_set_dmamode() is always true and the higher
UDMA clock is always selected.  This can potentially result in data
corruption when UDMA33 device is used, when 40-wire cable is used or
when the error recovery code decides to lower the device speed down.

The issue was introduced in the commit 6a40da0 ("libata cmd64x: whack
into a shape that looks like the documentation") which goes back to
kernel 2.6.20.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

pata_hpt{37x|3x2n}: fix timing register masks (take 2)

2009-12-18T21:30:46+00:00

commit 5600c70e576199a7552e1c0fff43f3fe16f5566e upstream.

These drivers inherited from the older 'hpt366' IDE driver the buggy timing
register masks in their set_piomode() metods. As a result, too low command
cycle active time is programmed for slow PIO modes.  Quite fortunately, it's
later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram
the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA
mode #N also reprograms already set PIO data timings, usually to MWDMA mode #
max(N, 2) timings...

However, the drivers added some breakage of their own too:  the bit that they
set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of
the command cycle setup time; also, setting it in DMA mode is wrong as this
bit is only for PIO actually and clearing it for PIO modes is not needed as
no mode in any timing table has it set...

Fix all this, inverting the masks while at it, like in the 'hpt366' and
'pata_hpt366' drivers; bump the drivers' versions, accounting for recent
patches that forgot to do it...

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: fix internal command failure handling

2009-11-10T00:52:09+00:00

commit f4b31db92d163df8a639f5a8c8633bdeb6e8432d upstream.

When an internal command fails, it should be failed directly without
invoking EH.  In the original implemetation, this was accomplished by
letting internal command bypass failure handling in ata_qc_complete().
However, later changes added post-successful-completion handling to
that code path and the success path is no longer adequate as internal
command failure path.  One of the visible problems is that internal
command failure due to timeout or other freeze conditions would
spuriously trigger WARN_ON_ONCE() in the success path.

This patch updates failure path such that internal command failure
handling is contained there.

Signed-off-by: Tejun Heo 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: fix off-by-one error in ata_tf_read_block()

2009-09-24T15:47:35+00:00

commit ac8672ea922bde59acf50eaa1eaa1640a6395fd2 upstream.

ata_tf_read_block() has off-by-one error when converting CHS address
to LBA.  The bug isn't very visible because ata_tf_read_block() is
used only when generating sense data for a failed RW command and CHS
addressing isn't used too often these days.

This problem was spotted by Atsushi Nemoto.

Signed-off-by: Tejun Heo 
Reported-by: Atsushi Nemoto 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

pata_hpt37x: fix HPT370 DMA timeouts

2009-05-02T17:24:25+00:00

upstream commit: 265b7215aed36941620b65ecfff516200fb190c1

The libata driver has copied the code from the IDE driver which caused a post
2.4.18 regression on many HPT370[A] chips -- DMA stopped to work completely,
only causing timeouts.  Now remove hpt370_bmdma_start() for good...

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jeff Garzik 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

ata_piix: add workaround for Samsung DB-P70

2009-03-23T21:59:59+00:00

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 
Reported-by: Joseph Jang 
Reported-by: Jonghyon Sohn 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

libata: make sure port is thawed when skipping resets

2009-03-17T00:52:53+00:00

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
->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 ->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, ->prereset() determines that
there's no need for softreset and both ->softreset() and ->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 
Cc: Robert Hancock 
Reported-by: Dan Andresan 
Reported-by: Arne Woerner 
Reported-by: Stefan Lippers-Hollmann 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman