Re: Nvidia cable detection problems & ACPI (beware, slight off-top)

[Oleg Verych]

(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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/