linux-toradex.git/drivers/ata, branch v2.6.34-rc4

libata: unlock HPA if device shrunk

2010-04-06T14:55:33+00:00

Some BIOSes don't configure HPA during boot but do so while resuming.
This causes harddrives to shrink during resume making libata detach
and reattach them.  This can be worked around by unlocking HPA if old
size equals native size.

Add ATA_DFLAG_UNLOCK_HPA so that HPA unlocking can be controlled
per-device and update ata_dev_revalidate() such that it sets
ATA_DFLAG_UNLOCK_HPA and fails with -EIO when the above condition is
detected.

This patch fixes the following bug.

  https://bugzilla.kernel.org/show_bug.cgi?id=15396

Signed-off-by: Tejun Heo 
Reported-by: Oleksandr Yermolenko 
Signed-off-by: Jeff Garzik

libata: disable NCQ on Crucial C300 SSD

2010-04-06T14:55:06+00:00

Crucial said,

  Thank you for contacting us. We know that with our M225 line of SSDs
  you sometimes need to disable NCQ (native command queuing) to avoid
  just the type of errors you're seeing. Our recommendation for the
  M225 is to add libata.force=noncq to your Linux kernel boot options,
  under the kernel ATA library option.

  I have sent your feedback to the engineers working on the C300, and
  asked them to please pass it on to the firmware team. I have been
  notified that they are in the process of testing and finalizing a
  new firmware version, that you can expect to see released around the
  end of April. We’ll keep you posted as to when it will be available
  for download.

So, turn off NCQ on the drive w/ the current firmware revision.

Reported in the following bug.

  https://bugzilla.kernel.org/show_bug.cgi?id=15573

Signed-off-by: Tejun Heo 
Reported-by: lethalwp@scarlet.be
Reported-by: Luke Macken 
Signed-off-by: Jeff Garzik

libata: don't whine on spurious IRQ

2010-04-06T14:54:38+00:00

On configurations where IRQ line is shared with a different
controller, spurious IRQs may happen continuously.  The message was
put there primarily for debugging anyway.  Kill it.

Signed-off-by: Tejun Heo 
Signed-off-by: Jeff Garzik

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32+00:00

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo 
Guess-its-ok-by: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Lee Schermerhorn

pata_via: fix VT6410/6415/6330 detection issue

2010-03-28T04:51:50+00:00

When using VT6410/6415/6330 chips on some VIA's platforms, the HDD
connection to VT6410/6415/6330 cannot be detected.

It is because the driver detects wrong via_isa_bridge ID, and then
causes this issue to happen.

Signed-off-by: Joseph Chan 
Signed-off-by: Jeff Garzik

libata-sff: fix spurious IRQ handling

2010-03-23T13:39:08+00:00

Commit 27943620cbd960f710a385ff4a538e14ed3f1922 introduced spurious
IRQ handling but it has a race condition where valid completion can be
lost while trying to clear spurious IRQ leading to occassional command
timeouts.

This patch improves SFF interrupt handler such that

1. Once BMDMA HSM is stopped, the condition is never considered
   spurious.  As there's no way to resume stopped BMDMA HSM, if device
   status doesn't agree with BMDMA status, the only way out is
   aborting the command (otherwise, it will just end up timing out).

2. ap->ops->sff_check_status() can be safely called to clear spurious
   device IRQ as it atomically returns completion status but BMDMA IRQ
   status can't be cleared in safe way if command is in flight.  After
   a spurious IRQ, call ap->ops->sff_irq_clear() only if the
   respective device is idle and retry completion if
   sff_check_status() indicates command completion.

Please note that ata_piix uses bmdma_status for sff_irq_check() and #2
won't weaken spurious IRQ handling even with in-flight command because
if bmdma_status indicates IRQ pending but device status is not on
spurious check, the next IRQ handler invocation will abort the command
due to #1.

This fixes bko#15537.

   https://bugzilla.kernel.org/show_bug.cgi?id=15537

Signed-off-by: Tejun Heo 
Cc: Andrew Benton 
Cc: Petr Uzel 
Cc: Rafael J. Wysocki 
Signed-off-by: Jeff Garzik

pata_via: Add VIA VX900 support

2010-03-23T02:44:17+00:00

Signed-off-by: Joseph Chan 
Signed-off-by: Jeff Garzik

ahci: pp->active_link is not reliable when FBS is enabled

2010-03-17T19:54:55+00:00

pp->active_link is not reliable when FBS is enabled.
Both PORT_SCR_ACT and PORT_CMD_ISSUE should be checked
because mixed NCQ and non-NCQ commands may be in flight.

Signed-off-by: Shane Huang 
Signed-off-by: Jeff Garzik

ahci: use BIOS date in broken_suspend list

2010-03-17T17:47:20+00:00

HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making
ahci_broken_suspend() trigger for later products which are not
affected by the original problems.  Match BIOS date instead of version
and add references to bko's so that full information can be found
easier later.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462

Signed-off-by: Tejun Heo 
Reported-by: tigerfishdaisy@gmail.com
Signed-off-by: Jeff Garzik

ahci: add missing nv IDs

2010-03-17T17:46:43+00:00

bko#15481 shows that we're missing some NVIDIA ahci PCI IDs.  Peer
Chen confirms that IDs 0x580-0x58f are reserved for cases where Linux
ID option is selected in the BIOS and are only used for mcp65-73.  Add
0x0581-0x058f.

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

Signed-off-by: Tejun Heo 
Cc: Peer Chen 
Signed-off-by: Jeff Garzik