> Based on the above, I would say that Windows has powered-down the NIC. This
> is outside of the scope of the driver, so I don't think a solution should be
> implemented there. Probably something for our APM folks.
It's actually an ACPI-ish issue, however drivers are probably going to
have to change to support it correctly.
I'm not 100% keen on having the PCI code unconditionally bring a device
to D0 before handing it over for probe or attach; I got bitten by this
just recently with activating I/O and memory ranges, and I think the
only way for things to be done safely is going to be for a PCI driver to
be required to:
- check and enable busmastering
- check and enable memory/port I/O as required
- bring the device to D0 power state
All of these can be abstracted as PCI methods, so they won't require lots
of cut-n-paste in each driver:
pci_enable_busmaster(dev);
pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY);
pci_set_powerstate(dev, PCI_POWERSTATE_D0);
Consider the above a request for review on the matter.
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
