At this point we are really talking about PCI Power Management not
ACPI. If we needed ACPI for driver power management, tons of existing
installations using APM or swsusp would be sunk.
> The only calls to udelay(2000) that I see are when the hardware
> is being reset, a hopefully a rare event. However, I agree it would be
> good to determine if those 2ms delays can be eliminated.
Definitely attempt to remove the delay. However, see if sleeping is
possible in lieu of calling udelay.
> natsemi.c (Don's driver) - This driver used {read,write}{b,w,l}
> to memory addresses that apparently mapped into IO ports, which the
> 2.4.0-testX kernels discourage strongly by printing a warning every
> time it happens. (I guess this ability is going to be removed.)
> Changing the code to use {in,out}{b,w,l} has not worked as far as I
> can tell, even though the IO addresses appear to be correct, and I
> have verified that porting the TeamF1 routine for reading the mac
> address into this driver works (and in this style of this driver), so
> the board is alive.
Sounds like things got fubar'd in your conversion. This MMIO stuff
hasn't changed since 2.2.x; it sounds like the driver might be picking
the wrong PCI base address register to read for its ioaddr.
It shouldn't take long at all to port Donald's new natsemi.c to 2.4.x,
so I might do it. (I've done the ports for several of the other PCI net
drivers in the 2.4.x kernel)
Jeff
-- Jeff Garzik | Building 1024 | Yossarian lives. MandrakeSoft, Inc. |- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/