On Thursday 19 November 2009 19:38:26 Sergei Shtylyov wrote: > Alan Cox wrote: > > >>Fixed where? I posted the patch as soon as I noticed the problem. > > > Its not posted because unlike you I don't post patches as soon as I > > notice them. I test them first. Which is why for example I discovered the > > bug in the drivers/ide one. Did you check the vendor driver and then > > stick 40 and 80 wire cables on the system to check the bits on a 3x2N ? > > > No I didn't think so. You see if you had you'd have discovered something > > else. You'd have discovered another bug in the old IDE one. The driver > > code for these chips isn't reliable and doesn't work at all in some cases. > > >>Told me about it? > > > Yes - or do you only write replies not read them ? > > > NAK - the patch is inadequate. > > No, it was. And yours isn't quite. > > > The procedure in the vendor driver does > > appear to work on the newer chips however. > > > Probably worth double checking > > the HPT37x and seeing if it needs the same debounce delays. > > All vendor drivers I have do call StallExec(10) when detecting cable > type, so need to add the delay to pata_hpt37x too. Given this I take back my ACK to Alan's patch. > I'd suggest to address the delay by another, separate patch to both > pata_hpt37x and pata_hpt3x2n drivers, and accept Bart's original patch for > bit reversing... Yes. -- Bartlomiej Zolnierkiewicz -- 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
