> On Tue, 19 Oct 1999, Donald Becker wrote:
> >
> > That pci scan code has significant limitations.
> > It doesn't handle the ACPI-D3 problem when warm-booting from Windows.
> > This generates a bunch of bug reports, and they all go to me.
>
> "enable_pci_device()" does that.
>
> I do NOT think that finding a device should automatically enable it.
The scan code has an option to disable the ACPI power activation.
> Especially as there are known instances where you might have to do extra
> work before you truly enable it (ie USB would usually need to make sure
> that the SMI interrupt is disabled before it takes over the USB device, so
> that a SMM BIOS won't do anything confusing).
That's unrelated to the ACPI issue. The ACPI problem usually happens when a
Windows driver leaves the card powered down, or even when Linux leaves a
card in W-O-L mode. It's frequently the case that a device is updated with
ACPI, yet the PCI IDs and programming interface doesn't change.
> Don't make a monster. Make something that is simple, and expand on it as
> needed. I do not like the way you usually sit on the code until you are
> happy, and then release it in one big bunch without any input from others.
I don't "sit on the code". The process is far from opaque. The updates are
describe on web pages, mailing lists and hypermail archives. Yes, many
private test versions are sent to individuals and then have limited alpha
releases. I do seek to minimize the number of "real" releases, so I don't
have to track a zillion released driver versions.
But I wonder why I put in the effort -- all of my work is thrown away when
you accept random, tested-only-on-one-machine patches from anywhere, and
then refuse to put in the tested, updated drivers.
Donald Becker
Scyld Computing Corporation, and
USRA-CESDIS, becker@cesdis.gsfc.nasa.gov
-
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/