PATCH: Fix ide probe double detection

PATCH: Fix ide probe double detection

[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.

Alan


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
--- linux-2.6.7/drivers/ide/ide-probe.c	2004-06-16 21:11:35.000000000 +0100
+++ 2.6.7-ac/drivers/ide/ide-probe.c	2004-06-16 21:19:28.000000000 +0100
@@ -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 ||

Re: PATCH: Fix ide probe double detection

[Benjamin Herrenschmidt]

On Wed, 2004-07-28 at 08:46, Alan Cox wrote:
> 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.

Re: PATCH: Fix ide probe double detection

[Alan Cox]

On Thu, Jul 29, 2004 at 01:22:44PM +1000, Benjamin Herrenschmidt wrote:
> 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

Re: PATCH: Fix ide probe double detection

[Doug Maxey]

On Thu, 29 Jul 2004 13:22:44 +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2004-07-28 at 08:46, Alan Cox wrote:
>> 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.

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

Re: PATCH: Fix ide probe double detection

[Alan Cox]

On Thu, Jul 29, 2004 at 10:56:38AM -0500, Doug Maxey wrote:
> 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 ?