linux-kernel - Re: [PATCH] Request driver inclusion

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:	Thu, 18 Jun 2009 13:49:30 +0200
From:	Peter Feuerer <peter@...e.net>
To:	Borislav Petkov <petkovbb@...glemail.com>
Cc:	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,

Borislav Petkov writes:

> Hi,
> 
> On Thu, Jun 18, 2009 at 12:55 PM, Peter Feuerer<peter@...e.net> wrote:
>>>>> Didn't someone argue that pre_suspend_kernelmode was unnecessary?
>>>>> It's still in there. (could be submitted together with the
>>>>> Kconfig ACPI depends ;)
>>>>
>>>> Actually I think pre_suspend_kernelmode is needed, so it won't be
>>>> dropped.
>>>
>>> and it is needed, because...?
>>
>> It's needed because we do now a clean revert to bios mode before we suspend.
>> And after resume we have to switch to kernelmode again, if the driver was in
>> kernelmode before suspend. So we need to keep track of in what state the
>> driver was before suspending. That's what's this variable is for.
> 
> You've got that state in the 'kernelmode' variable. See full comment:
> http://marc.info/?l=linux-kernel&m=124482114200865

We are talking about patch 0.5.9 and not 0.5.8, are we?
http://patchwork.kernel.org/patch/30733/mbox/

have a look at at line 543:
+	/* remember previous setting */
+	pre_suspend_kernelmode = kernelmode;
+
+	if (kernelmode) {
+		acerhdf_revert_to_bios_mode();
+		if (acerhdf_thz_dev)
+			thermal_zone_device_update(acerhdf_thz_dev);
+       }

o we save the kernelmode to pre_suspend_kernelmode
o then if kernelmode is on, we call acerhdf_revert_to_bios_mode()
o we start a thermal_zone_device_update which let the thermal layer 
call acerhdf_set_cur_state
o acerhdf_set_cur_state then disables kernelmode (and sets kernelmode 
= 0) so we would lose the state of the kernelmode if we didn't save it 
within pre_suspend_kernelmode

> 
>>>> I'll add the ACPI dependency to Kconfig and submit the patch to lkml
>>>> and directly to Linus, as Len doesn't seem to react?! - Boris what do
>>>> you think? I mean, even if there's a problem with suspend / resume,
>>>> this can also be fixed after the merge window, while all those release
>>>> candidates are done.
>>>
>>> Nope, this has to be fixed before submission. The merge window is open,
>>> I think, until mid next week so there's plenty of time.
>>
>> I'll be only there until Sunday evening. I'm going to be on business trip
>> starting on Monday (and returning probably at Saturday). But I'll do my best
>> to figure out the problem.
>>
>> I wasn't able to reproduce the suspend / resume problem Andreas has with
>> acerhdf 0.5.9 yesterday and the day before. Do you also have the problem,
>> that acerhdf is reading sometimes an unexpected Fan state after resuming?
> 
> Will look into it on the weekend.

Great! Thank you very much!

regards,
--peter
--
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/