> Can you be more precise about this ? 

The example that I have spotted so far is that wdc.c:wdcprobe sets WDCTL_4BIT 
in the auxialiary control register when the ATA spec lists this as a reserved 
bit and requires that it be cleared. I don't think that we should go round 
setting reserved bits in important registers, and I don't think we should 
casually drop support for WDC devices that need this bit set.

> > shouldn't be doing resets (according to the bit if the spec that I recall). I 
> 
> I don't recall the specs saying that.

I do recall that, but I've already looked up chapter and verse once today, and 
I can't be bothered doing it again.  It also isn't worth arguing about until 
someone starts actually doing stuff with the code.

> Doing a reset is the only way to have the
> device in a known working state, we can't avoid that.

I think we can, mostly.

> The BIOS or previous OS
> may have done all sort of weirdness to the device, from setting up power
> management to restricting access to parts of the device.

I have to admit that I'm also wary of what the BIOS might do to the device. I 
think that we can handle anything except the security restriction stuff, and 
now that I think some more, we aren't supposed to be allowed to do anything to 
the security stuff. The security restrictions are explicitly designed to 
protect parts of the device from the O/S.

What happens if some vendor uses this facility to prevent their on disk 
pseudo-BIOS from being overwritten? User X asks NetBSD to use the whole disk 
because that's what they did for Windows and blam, their 'BIOS' disappears.

For other more volatile settings, we should be able to set them to whatever we 
want, without a reset.

I'm not hung up on the resets as such, it's just that I think the specs says 
not to do them and I want us to have a driver that we can claim to be a well 
behaved ATA driver. Obviously we need reliability and performance as well, but 
I think the boasting rights are good for proselytising(sp?) NetBSD.

> The problem is that, with some controller, you also have to wait 30s before
> you can decide that there is no device here. With 2 channels this makes a
> 1mn delay.

We certainly don't want this. Especially when you can have more than one 
controller in a machine. I can now see why you are interested in probing for 
devices after interrupts have been enabled. All ATA buses could be probed at 
the same time. Marshalling the responses could be interesting, but I'm sure it 
can be done.

> I agree that a few things here can probably be improved, but splitting
> the pre-ata support in a different driver is not the way to go. Way too much
> code duplication.

My intention is/was to not maintain the pre-ata support. Yeah, yeah. I know 
that it's going to need to be worked on sometimes as the environment 
surrounding it changes, but the hardware that the code supports is EOL. On the 
other hand, I have been thinking about how much code is in wdc.c (since you 
mentioned it), and I have to agree that large scale code duplication is a bad 
thing.

I have two problems

1) I can't tell by looking at wdc.c which parts are ATA conformant, and which 
aren't. I like to fix problems like this by starting with a spec, an empty 
source file, and useful code stolen from elsewhere and then procede to build a 
conformant implementation while avoiding all the hard work by stealing from 
the aforementioned code.

2) The support for old devices isn't as obvious as it might be. (IMVHO - I 
haven't looked at this side of things.)

What would be nice to do would be to remove all of the special case support 
from wdc.c so that we had a nice simple WDC core that could be used by the ATA 
system and by, say, wdc_old.c that bolted on all of the archaic support 
required. This is a bit fair of work/thinking though. I like nice clean code 
that has all the nasty special cases for broken devices hidden away somwhere.

Cheers,
Lloyd