linux-kernel - Re: [ibm-acpi-devel] Fan level 7 after resume wit 2.6.28-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Nov 2008 23:45:36 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	ibm-acpi-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [ibm-acpi-devel] Fan level 7 after resume wit 2.6.28-rc3

On Thursday, 6 of November 2008, Henrique de Moraes Holschuh wrote:
> On Thu, 06 Nov 2008, Tino Keitel wrote:
> > The whole fan level stuff looks a bit complicated to me. Especially the
> 
> It is.  The sysfs hwmon interface does not map 1:1 with the three possible
> thinkpad fan control interfaces.  fan_control_desired_level is used for that
> interface mainly, since I have to remember the last state used that was in
> the set of 0-7, ignoring AUTO (which is a separate pwm control mode for
> hwmon) and full-speed (which is a separate pwm control mode for hwmon).
> 
> It is hijacked by fan_suspend/fan_resume to store state between
> sleep/resume, because that was convenient.  Too bad I failed to notice it
> would not work properly for that.
> 
> > The attached patch tries to simplify this a bit. It sets
> 
> NAK, it would break a lot of stuff.   See my previous reply on this thread
> for *some* of the stuff it would break.
> 
> I will have a proper patch out probably within 24h but most certainly before
> next Monday.
> 
> Meanwhile, I suggest you just remove the calls to fan_suspend and fan_resume
> as a workaround.

Speaking of which, last time I looked at fan_suspend and fan_resume, they
were hopelessly broken (I admit that was quite some time ago, though).

IMO, fan_suspend() is not necessary at all and the only thing fan_resume()
could do is to make the kernel's data structures reflect the actual state of
the fan.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/