linux.git/drivers/ata, branch v2.6.33 Linux kernel source tree [libata] Call flush_dcache_page after PIO data transfers in libata-sff.c 2010-02-04T06:04:50+00:00 Catalin Marinas catalin.marinas@arm.com 2010-02-04T06:04:50+00:00 2d68b7fe55d9e19a8a868224ed0dfd6526568521 flush_dcache_page() must be called after (!ATA_TFLAG_WRITE) the data copying to avoid D-cache aliasing with user space or I-D cache coherency issues (when reading data from an ATA device using PIO, the kernel dirties the D-cache but there is no flush_dcache_page() required on Harvard architectures). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
flush_dcache_page() must be called after (!ATA_TFLAG_WRITE) the
data copying to avoid D-cache aliasing with user space or I-D cache
coherency issues (when reading data from an ATA device using PIO,
the kernel dirties the D-cache but there is no flush_dcache_page()
required on Harvard architectures).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
ahci: add Acer G725 to broken suspend list 2010-02-04T06:01:39+00:00 Tejun Heo tj@kernel.org 2010-01-28T07:04:15+00:00 cedc9bf906dae044443d403371c887affdb44168 Acer G725 shares the same suspend problem with the HP laptops which lose ATA devices on resume. New firmware which fixes the problem is already available. Add G725 with old firmwares to the broken suspend list. This problem has been reported in bko#15104. http://bugzilla.kernel.org/show_bug.cgi?id=15104 Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Jani-Matti Hätinen <jani-matti.hatinen@iki.fi> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
Acer G725 shares the same suspend problem with the HP laptops which
lose ATA devices on resume.  New firmware which fixes the problem is
already available.  Add G725 with old firmwares to the broken suspend
list.

This problem has been reported in bko#15104.

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

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Jani-Matti Hätinen <jani-matti.hatinen@iki.fi>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
libata-scsi passthru: fix bug which truncated LBA48 return values 2010-02-04T06:01:22+00:00 Douglas Gilbert dgilbert@interlog.com 2010-02-01T18:11:38+00:00 bc496ed00ab1411d3efaf295b72e0c9eb343e1a3 Fix assignment which overwrote SAT ATA PASS-THROUGH command EXTEND bit setting (ATA_TFLAG_LBA48) Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
Fix assignment which overwrote SAT ATA PASS-THROUGH command EXTEND
bit setting (ATA_TFLAG_LBA48)

Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
libata: retry FS IOs even if it has failed with AC_ERR_INVALID 2010-01-20T19:25:11+00:00 Tejun Heo tj@kernel.org 2010-01-14T07:18:09+00:00 534ead709235b967b659947c55d9130873a432c4 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 <tj@kernel.org> Reported-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
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 <tj@kernel.org>
Reported-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
libata: retry link resume if necessary 2010-01-12T19:34:14+00:00 Tejun Heo tj@kernel.org 2010-01-11T02:14:44+00:00 5040ab67a2c6d5710ba497dc52a8f7035729d7b0 Interestingly, when SIDPR is used in ata_piix, writes to DET in SControl sometimes get ignored leading to detection failure. Update sata_link_resume() such that it reads back SControl after clearing DET and retry if it's not clear. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: fengxiangjun <fengxiangjun@neusoft.com> Reported-by: Jim Faulkner <jfaulkne@ccs.neu.edu> Cc: stable@kernel.org Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
Interestingly, when SIDPR is used in ata_piix, writes to DET in
SControl sometimes get ignored leading to detection failure.  Update
sata_link_resume() such that it reads back SControl after clearing DET
and retry if it's not clear.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: fengxiangjun <fengxiangjun@neusoft.com>
Reported-by: Jim Faulkner <jfaulkne@ccs.neu.edu>
Cc: stable@kernel.org
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
ata_piix: enable 32bit PIO on SATA piix 2010-01-12T19:33:23+00:00 Tejun Heo tj@kernel.org 2010-01-11T08:03:11+00:00 0b67c7439fe2a5d76602de36854c88e2beab00b0 Commit 871af1210f13966ab911ed2166e4ab2ce775b99d enabled 32bit PIO for PATA piix but didn't for SATA. There's no reason not to use 32bit PIO on SATA piix. Enable it. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
Commit 871af1210f13966ab911ed2166e4ab2ce775b99d enabled 32bit PIO for
PATA piix but didn't for SATA.  There's no reason not to use 32bit PIO
on SATA piix.  Enable it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
sata_promise: don't classify overruns as HSM errors 2010-01-12T19:33:07+00:00 Mikael Pettersson mikpe@it.uu.se 2010-01-09T22:32:06+00:00 a2342f46437cde56803a36fdf94da635a74ad41c When sata_promise encounters an overrun or underrun error it translates that to a libata AC_ERR_HSM, causing a hard reset. Since over/under-runs were thought to be rare and transient, this action seemed reasonable. Unfortunately it turns out that the controller throws overrun errors when e.g. hal polls a CD or DVD writer containing blank media, causing long sequences of hard resets and retries before EH finally gives up. This patch updates sata_promise to classify over/under-runs as AC_ERR_OTHER instead. This allows libata EH and upper layers to retry or fail the operation as they see fit without the disruption caused by repeated hard resets. This fixes a problem using a DVD-RAM drive with sata_promise, reported by Thomas Schorpp. I also tested it on a DVD-RW drive. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Tested-by: thomas schorpp <thomas.schorpp@googlemail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
When sata_promise encounters an overrun or underrun error it
translates that to a libata AC_ERR_HSM, causing a hard reset.
Since over/under-runs were thought to be rare and transient,
this action seemed reasonable.

Unfortunately it turns out that the controller throws overrun
errors when e.g. hal polls a CD or DVD writer containing blank
media, causing long sequences of hard resets and retries before
EH finally gives up.

This patch updates sata_promise to classify over/under-runs as
AC_ERR_OTHER instead. This allows libata EH and upper layers to
retry or fail the operation as they see fit without the disruption
caused by repeated hard resets.

This fixes a problem using a DVD-RAM drive with sata_promise,
reported by Thomas Schorpp. I also tested it on a DVD-RW drive.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Tested-by: thomas schorpp <thomas.schorpp@googlemail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Merge branch 'misc-2.6.33' into release 2009-12-24T06:19:00+00:00 Len Brown len.brown@intel.com 2009-12-24T06:19:00+00:00 fcb11235d3910c39afece52f6e106a9ca565d34b 






ACPI: do not select ACPI_DOCK from ATA_ACPI
2009-12-24T05:04:40+00:00

Carlos R. Mafra
crmafra@aei.mpg.de

2009-12-22T21:45:39+00:00

2370b5ed03030d554adb345778d5edecab7a510c

In March 2008 commit 0ac4a3c2fbbcadc3e96e4dc47d4ae802d66e6f67 ("ACPI: fix
ATA_ACPI build") made CONFIG_ACPI_DOCK be selected by CONFIG_ATA_ACPI because
of a build error when CONFIG_ATA_ACPI=y and CONFIG_ACPI_DOCK=m.

However, in September 2008 commit 898b054f3eec5921320ae8614b5bdd7b07ea5b43
("dock: make dock driver not a module") removed the possibility of having
CONFIG_ACPI_DOCK=m and therefore there is no need for selecting it when
CONFIG_ATA_ACPI=y.

This makes the kernel ~5 Kb smaller for people who don't have a dock by
allowing them to not have ACPI_DOCK compiled-in because of ATA_ACPI=y.

Signed-off-by: Carlos R. Mafra <crmafra@aei.mpg.de>
Cc: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>





In March 2008 commit 0ac4a3c2fbbcadc3e96e4dc47d4ae802d66e6f67 ("ACPI: fix
ATA_ACPI build") made CONFIG_ACPI_DOCK be selected by CONFIG_ATA_ACPI because
of a build error when CONFIG_ATA_ACPI=y and CONFIG_ACPI_DOCK=m.

However, in September 2008 commit 898b054f3eec5921320ae8614b5bdd7b07ea5b43
("dock: make dock driver not a module") removed the possibility of having
CONFIG_ACPI_DOCK=m and therefore there is no need for selecting it when
CONFIG_ATA_ACPI=y.

This makes the kernel ~5 Kb smaller for people who don't have a dock by
allowing them to not have ACPI_DOCK compiled-in because of ATA_ACPI=y.

Signed-off-by: Carlos R. Mafra <crmafra@aei.mpg.de>
Cc: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>







pata_bf54x: handle portmuxing of pins through GPIO PORTs
2009-12-21T18:55:38+00:00

Sonic Zhang
sonic.zhang@analog.com

2009-07-14T17:39:47+00:00

3439d65062a4af6af0433c8816fd54697d782ff4

By default, the PATA pins are routed to the async address lines in which
case, no peripheral muxing needs to be done.  However, if the pins get
routed through the GPIO PORTs pins, we need to make sure to request them
so that the muxing is properly set up.

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>





By default, the PATA pins are routed to the async address lines in which
case, no peripheral muxing needs to be done.  However, if the pins get
routed through the GPIO PORTs pins, we need to make sure to request them
so that the muxing is properly set up.

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>