Skip to contentSkip to conversation

PATCH: Fix ide probe double detection

PATCH Alan Cox 3 participants 5 messages Jul 27, 2004 – Jul 29, 2004

lore
Share & tools
lore

Alan Cox

author
#0 lore raw

Some devices don't decode master/slave - notably PCMCIA adapters. Unfortunately for us some also do, which makes it hard to guess if we should probe the slave.

This patch fixes the problem by probing the slave and then using the model and serial information to spot undecoded pairs. An additional check is done to catch pairs of pre ATA devices just in case.

Alan

drivers/ide/ide-probe.c +10 -0
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux-2.6.7/drivers/ide/ide-probe.c 2.6.7-ac/drivers/ide/ide-probe.c
@@ -749,6 +749,16 @@
 		ide_drive_t *drive = &hwif->drives[unit];
 		drive->dn = (hwif->channel ? 2 : 0) + unit;
 		(void) probe_for_drive(drive);
+		if (drive->present && hwif->present && unit == 1)
+		{
+			if(strcmp(hwif->drives[0].id->model, drive->id->model) == 0 &&
+			   strcmp(drive->id->model, "UNKNOWN") && /* Don't do this for non ATA or for noprobe */
+			   strncmp(hwif->drives[0].id->serial_no, drive->id->serial_no, 20) == 0)
+			{
+				printk(KERN_WARNING "ide-probe: ignoring undecoded slave\n");
+				drive->present = 0;
+			}
+		}
 		if (drive->present && !hwif->present) {
 			hwif->present = 1;
 			if (hwif->chipset != ide_4drives ||
#1 lore raw
Quoted 7 lines · Alan Cox

Some devices don't decode master/slave - notably PCMCIA adapters. Unfortunately for us some also do, which makes it hard to guess if we should probe the slave.

This patch fixes the problem by probing the slave and then using the model and serial information to spot undecoded pairs. An additional check is done to catch pairs of pre ATA devices just in case.

What about checking if drive->select sticks ? And if that doesn't work, something like

- select 0
- write a value to reg X
- select 1
- write a different value to reg X
- select 0
- check value

reg X could be nsect or such ...

I don't like relying on drive->id and serial_no, but that may just be paranoia...

Ben.

author
#2 lore raw
Quoted 2 lines · Benjamin Herrenschmidt

I don't like relying on drive->id and serial_no, but that may just be paranoia...

I've seen no evidence to indicate anyone has duplicate serial numbers even with CF cards so I think its fine. The problem with playing with registers and seeing if they stick is that on the newer cards the register bank you are programming is sometimes a fifo ahead of the real drive.

Alan

#3 lore raw
In reply to Benjamin Herrenschmidt
Quoted 19 lines · Benjamin Herrenschmidt
Quoted 7 lines · Alan Cox

Some devices don't decode master/slave - notably PCMCIA adapters. Unfortunately for us some also do, which makes it hard to guess if we should probe the slave.

This patch fixes the problem by probing the slave and then using the model and serial information to spot undecoded pairs. An additional check is done to catch pairs of pre ATA devices just in case.

What about checking if drive->select sticks ? And if that doesn't work, something like

- select 0
- write a value to reg X
- select 1
- write a different value to reg X
- select 0
- check value

Quoted 6 lines

reg X could be nsect or such ...

I don't like relying on drive->id and serial_no, but that may just be paranoia...

Ben.

One strategy would be to reverse the order of probes, doing drive 1 first, then drive 0. When I was working IDE in AIX, we had some ATAPI devices that were recalcitrant until the strategy was switched to 1,0 order

++doug

author
#4 lore raw
Quoted 3 lines · Doug Maxey

One strategy would be to reverse the order of probes, doing drive 1 first, then drive 0. When I was working IDE in AIX, we had some ATAPI devices that were recalcitrant until the strategy was switched to 1,0 order

I'm missing something here - how is this helpful when the slave bit is simply not decoded and you get master both times ?