On Wed, Feb 27, 2002 at 09:01:37PM +1300, Lloyd Parkes wrote:
> > 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.

It is reserved in newer ATA specs, but in older ones (I can find the exact
rev if needed) it is valid. So not setting this bit may break older ATA
devices.

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

I recall an example as of why the reset is needed:
before pciide.c rev 1.105 no reset would be done on pciide controllers in
native mode (the wrong I/O was written); the result was nonfunctionnal drives
on sparc64 and macppc.

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

This restriction isn't removed by a soft reset, if I remember properly.
Some laptop uses this already and this isn't a problem with NetBSD.

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

And when a new feature appears, we need to update the driver. This isn't
good.

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

I can't see how a standart can recommend that. Also note that this is the
only way to wake up a drive from deep sleep mode.

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

This is not the reason, as the delay problem has already been worked around
for most cases. This is for hot-plug IDE devices.

> 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 

Well, so we strongly disagree on this. I think there are a number of NetBSD
systems running on old drives.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--