[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090618132510.GA1131@rhlx01.hs-esslingen.de>
Date: Thu, 18 Jun 2009 15:25:10 +0200
From: Andreas Mohr <andi@...as.de>
To: Borislav Petkov <petkovbb@...glemail.com>
Cc: Peter Feuerer <peter@...e.net>, Andreas Mohr <andi@...as.de>,
Ed Tomlinson <edt@....ca>, akpm@...ux-foundation.org,
Len Brown <len.brown@...el.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Request driver inclusion - acer aspire one fan control
Hi,
On Thu, Jun 18, 2009 at 02:45:41PM +0200, Borislav Petkov wrote:
> ok, this starts to look quite a bit overengineered for no reason. First,
> acerhdf_revert_to_bios_mode() sets the fan to auto. Then, you've added
> a thermal_zone_device_update() call in there which does set the fan to
> auto indirectly _again_. And we end up with _three_ variables which
> represent only _one_ state. Here's what it should do:
>
> suspend:
> - set fan to auto
>
> resume:
> - the thermal layer figures out what to do based on the 'kernelmode' and
> current temperature.
>
> That's it, everything else is too much.
No, I'd say it's not as easy as that.
If you want to discover any weird state changes behind your back (and we
want that, that driver should be _safe_), then we need to record the current fan state
as set by us.
But that then means that during interruption of normal operation
(suspend), we need to temporarily stop this checking.
IOW, we need some more variable(s) to indicate:
OPERATION_SUSPENDED (set by .suspend)
OPERATION_ABOUT_TO_CONTINUE (set by .resume)
OPERATING
In state OPERATION_ABOUT_TO_CONTINUE the thermal layer function
would know that they shouldn't check fan state consistency, would
refresh fan state to the current state and then set it to OPERATING.
Or some such (would need further analysis).
Andreas Mohr
--
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/
Powered by blists - more mailing lists