> > What good things happen after this patch that didn't happen before it?
>
> The guy sees a valid temperature, in /proc-/sys and also in the
> corresponding X-apps (which his original complaints were).
>
> The thermal zone has a valid passive trip point (95 C), which now is
> active again.
I understand the 1st patch to not disqualify a TZ if it has
a bogus _CRT. That would make a TZ show up rather than
get discarded. If that patch compiled cleanly, I'd apply it...
I don't understand this patch to scan a TZ for trip points
and print out a kernel warning about a firmware bug
for TZ's which have none, and disqualify those TZ's.
That isn't going to make temperature available when it
was not already available. That is going to add an additional
kernel message about a firmware bug we can't fix, and could
actually delete a thermal zone with a working temperature
that used to be present, no?
> He reported this as a regression, let me double check:
>
> Oh dear..., _CRT doesn't return anything for Windows 2006
> (or newer, not defined Windowses) -> broken trip point.
>
> There is a Linux workaround (which does not work anymore,
> this probably was the reason for the regression -> OSI!=Linux),
> which make _CRT return a valid trip point like on old Windowses.
>
> So this makes the behavior more "latest Windows OS" like.
> Hmm, depends whether Windows still takes the thermal zone into
> account if _CRT is not available or invalid.
> The fact that a valid _HOT trip point is only exported on latest
> Windowses, hardens the guess that Windows also serves this
> thermal zone with an invalid critical trip point.
> It looks like the (TPOS == 0x40) thermal workarounds wants to avoid
> thermal shutdowns (critical) in case 100 C are reached and change it
> into a (debug?) message (_HOT) on latest Windowses.
> Related ASL output:
>
>
> If (_OSI ("Linux"))
> {
> Store (One, LINX)
> Store (0x80, OSTB)
> Store (0x80, TPOS)
> }
> If (_OSI ("Windows 2006"))
> {
> Store (0x40, OSTB)
> Store (0x40, TPOS)
> }
>
> ...
> Name (TPC, 0x64)
> Method (_HOT, 0, Serialized)
> {
> If (LEqual (TPOS, 0x40))
> {
> Return (Add (0x0AAC, Multiply (TPC, 0x0A)))
> }
> }
>
> Method (_CRT, 0, Serialized)
> {
> If (LNotEqual (TPOS, 0x40))
> {
> Return (Add (0x0AAC, Multiply (TPC, 0x0A)))
> }
> }
It appears that if acpi_osi=Linux were set (or TPOS were
anything other than Windows 2006), then you
would not get a _HOT or _CRT in this TZ.
I don't understand how that is related to this issue,
as acpi_osi=Linux is not set, right?
acpi_osi="Windows 2006", on the other hand, should be set.
In that case the AML will return a valid trip point for
both _HOT and _CRT, yes? So what is the problem?
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
