(i don't know a single bit of details of what i'm writing, so... ;) Jeff Garzik wrote: > Alan wrote: > >>I'm very upset, that hardware nvidia-lego forces system software (and > >>programmers) to know "unfortunately no standard" ways of desinging > >>things... One read-only-for-os, hardware set bit in kind of control > > > >The hardware doesn't. The BIOS authors do by not setting the cable flags. > >We actually need to use the STM and GTM methods for PC suspend/resume so > >it makes sense to see if they will work out in this case too.
Before that. I mean, to let Vendor to choose (and software operate) GPIO and then to have headache, you've described. Also, here i'm not going wider, than hardware cabel detection/max speed test (IMHO it must be pretty easy). > We also need ACPI, where available, because that's the only way to > obtain a BIOS-set hard drive password. Plain-text passwords -- i don't actually know, if they are useful at all. What if BIOS has admin/user passwords set? (kernel: if you have BIOS password, press RESET; if you don't press POWER ;) > And BIOS vendors often deliver hard drive-specific errata this way, if > the problem is serious enough (though certainly we would prefer that > the OS knows about drive errata, when a runtime patch is necessary) I thought versions, revisions, stepping are indicators of that, and OS have workarounds, fixes, optimizations, based on that kind of information. "BIOS vendors", as i read here, are IMHO -bug-in-the-middle- attack (: Kind regards, guys. -- -o--=O`C #oo'L O <___=E M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
