Alan Cox wrote:
I have explained everything in the prior mail. I hadn't expect you to start the patch fencing.
I don't see an explanation just points I queried.
Have you seen this mail: http://marc.info/?l=linux-ide&m=123299798729575 If you haven't, read it. After you have, the argument must be over.
I shall draw the obvious conclusion from the fact you don't feel like providing one
The logic is this
ATA-3 or higher - that word has a defined meaning ATA < 3 that word should be 0x0000 pre ATA (EIDE) or head up backside implementations that would will be anything but usually 0x0000 or 0xFFFF
We cannot test for ATA < 3 because there is no version bit for it
That's not quite true, read the ATA-3 standard better.
Therefore we want to check
CFA signature -> CFA (good for CFA 1.1 and later devices using it) ATA >= 3 claimed - word is trustable bit is 0 or means CFA
The problem is that the CF specs explicitly forbid (!) to report anything in word 80 -- it's reserved and must be 0.
Yes the implementation is paranoid, but having done ten years working for a distro dealing with PC hardware in volume day in and day out I've yet
Working while checking word 82 ISO word 83? Who are you trying to cheat?
to regret being paranoid.
Again, I'm not seeing this kind of version paranoia in any place but the one that was wrong: ata_id_is_cfa().
Assuming every piece of hardware sucks, nobody ever read the standard and every BIOS table is wrong is a staple part of writing a robust OS for the PC platform.
Yes, we just had report of the CF drive which is totally unidentifiable... but perhaps you still should start reading the specs as more manufacturers are doing it now and following them?
Alan
MBR, Sergei -- 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
