aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/ide/ide-iops.c
diff options
context:
space:
mode:
authorBartlomiej Zolnierkiewicz <bzolnier@gmail.com>2009-05-22 10:23:36 -0400
committerBartlomiej Zolnierkiewicz <bzolnier@gmail.com>2009-05-22 10:23:36 -0400
commit8369d5fa63260cc54464b4687aa6a0f78402d98e (patch)
tree0d36d4d7af4f9acb6b5436a1786170928a7ba888 /drivers/ide/ide-iops.c
parentd8788298d491ee5026981eb751b0341a996b22e4 (diff)
ide: fix 40-wire cable detection for TSST SH-S202* ATAPI devices (v2)
Since 2.6.26 we support UDMA66 on ATAPI devices requiring IVB quirk: commit 8588a2b732928b343233af9b1855705b8286bed4 ("ide: add SH-S202J to ivb_list[]") We also later added support for more such devices in: commit e97564f362a93f8c248246c19828895950341252 ("ide: More TSST drives with broken cable detection") and in: commit 3ced5c49bd2d1f2c7f769e3a54385883de63a652 ("ide: add TSSTcorp CDDVDW SH-S202H to ivb_list[]") It turns out that such devices lack cable detection altogether (which in turn results in incorrect detection of 40-wire cables by our current cable detection strategy) so always handle them by trusting host-side cable detection only. v2: Model detection fixup from Martin. Reported-and-tested-by: Martin Lottermoser <Martin.Lottermoser@t-online.de> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Diffstat (limited to 'drivers/ide/ide-iops.c')
-rw-r--r--drivers/ide/ide-iops.c21
1 files changed, 17 insertions, 4 deletions
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index c19a221b1e18..06fe002116ec 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -206,8 +206,6 @@ EXPORT_SYMBOL_GPL(ide_in_drive_list);
206 206
207/* 207/*
208 * Early UDMA66 devices don't set bit14 to 1, only bit13 is valid. 208 * Early UDMA66 devices don't set bit14 to 1, only bit13 is valid.
209 * We list them here and depend on the device side cable detection for them.
210 *
211 * Some optical devices with the buggy firmwares have the same problem. 209 * Some optical devices with the buggy firmwares have the same problem.
212 */ 210 */
213static const struct drive_list_entry ivb_list[] = { 211static const struct drive_list_entry ivb_list[] = {
@@ -251,10 +249,25 @@ u8 eighty_ninty_three(ide_drive_t *drive)
251 * - force bit13 (80c cable present) check also for !ivb devices 249 * - force bit13 (80c cable present) check also for !ivb devices
252 * (unless the slave device is pre-ATA3) 250 * (unless the slave device is pre-ATA3)
253 */ 251 */
254 if ((id[ATA_ID_HW_CONFIG] & 0x4000) || 252 if (id[ATA_ID_HW_CONFIG] & 0x4000)
255 (ivb && (id[ATA_ID_HW_CONFIG] & 0x2000)))
256 return 1; 253 return 1;
257 254
255 if (ivb) {
256 const char *model = (char *)&id[ATA_ID_PROD];
257
258 if (strstr(model, "TSSTcorp CDDVDW SH-S202")) {
259 /*
260 * These ATAPI devices always report 80c cable
261 * so we have to depend on the host in this case.
262 */
263 if (hwif->cbl == ATA_CBL_PATA80)
264 return 1;
265 } else {
266 /* Depend on the device side cable detection. */
267 if (id[ATA_ID_HW_CONFIG] & 0x2000)
268 return 1;
269 }
270 }
258no_80w: 271no_80w:
259 if (drive->dev_flags & IDE_DFLAG_UDMA33_WARNED) 272 if (drive->dev_flags & IDE_DFLAG_UDMA33_WARNED)
260 return 0; 273 return 0;