On 02/21/2010 12:41 PM, Bartlomiej Zolnierkiewicz wrote:
DISCLAIMER: the fact of getting patches merged into atang tree means
that from now on they will be getting updates for changes happening
in atang tree and it should not be treated as an indication regarding
decisions taken by 'upstream' kernel trees
Improve SSD detection so block layer optimizations can be applied
to many more SSD devices.
The following changes since commit 17c619273d412ed7b6120e448f87b2329457fc90:
Bartlomiej Zolnierkiewicz (1):
pata_oldpiix: enable parallel scan
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-v4.7
Bartlomiej Zolnierkiewicz (1):
libata: enhanced SSD detection
drivers/ata/libata-core.c | 3 +++
drivers/ata/libata-scsi.c | 18 ++++++++++--------
include/linux/libata.h | 1 +
3 files changed, 14 insertions(+), 8 deletions(-)
commit ded92e0d01fbb7f27bec7a35606847a2547e95e0
Author: Bartlomiej Zolnierkiewicz<bzolnier@xxxxxxxxx>
Date: Sun Feb 21 18:31:18 2010 +0100
libata: enhanced SSD detection
Many SSD devices predate or just don't implement non-rotational
media type advertisement through the word 217 of the id block so
check also the product id for 'SSD' substring to automatically
detect SSD devices and apply relevant block layer optimizations.
This is based on earlier Jeff Garzik's patch from April 2009:
http://lkml.org/lkml/2009/4/7/495
While at it:
- cleanup ata_scsi_dev_config() a bit
Tested with ASUS-PHISON SSD devices found in Asus Eee 901.
Cc: Jeff Garzik<jeff@xxxxxxxxxx>
Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@xxxxxxxxx>
Yes, I agree we need something like this. I will review for atang
dependencies, and then make sure it gets applied to upstream.
The previous discussion of this approach concluded weakly with "poor
heuristic", but a better approach did not materialize.
One question, though: why did you drop ata_id_is_ssd() test?
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
