Re: Quick aic7xxx bug hunt...

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Justin T. Gibbs wrote:
>>Great, I stand corrected.  Looks like 2.5 code is ancient then?
> 
> 
> Yes.  I didn't do the original port and am now just finishing up my
> port to 2.5.X.
> 
> 
>>comments on the 2.4 code:
>>* the 1000us delay in ahc_reset needs to be turned into a sleep, instead
>>all paths to that function [AFAICS] can sleep.  likewise for the huge
>>delay in ahc_acquire_seeprom.
> 
> 
> For all of these delays, I'd be more than happy to make them all into
> sleeps if I can tell, from inside ahc_delay() if I'm in a context where
> it is safe to sleep.  On the other platforms that this core code runs on
> I'm usually not in a context where it is safe to sleep, so I don't want
> to switch to using a different driver primitive.

For Linux it's unconditionally safe, and other platforms is sounds like 
it's unconditionally not.  So, s/ahc_delay/ahc_sleep/ for the places I 
pointed out, and just make ahc_delay==ahc_sleep on non-Linux platforms 
(or any similarly-functioning solution)

It's pretty much impossible to detect if you are inside certain 
spinlocks, in a generic fashion.


>>* PCI posting?  (aic7xxx_core.c, line 1322, the last statement in the
>>function...)
>>
>>                 ahc_outb(ahc, CLRINT, CLRSCSIINT);
> 
> 
> I don't care when the write occurs only that it will occur eventually.
> The buffer will get flushed eventually so there is no need to call
> ahc_flush_device_writes().

ok, thanks for clarifying.

	Jeff