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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cone.1248787508.386883.15136.1000@arca>
Date:	Tue, 28 Jul 2009 15:25:08 +0200
From:	Peter Feuerer <peter@...e.net>
To:	Borislav Petkov <petkovbb@...glemail.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>, lenb@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] acerhdf: convert to dev_pm_ops

Hi,

Borislav Petkov writes:

> Hi,
> 
> On Tue, Jul 28, 2009 at 9:25 AM, Peter Feuerer<peter@...e.net> wrote:
> 
> [..]
> 
>>>> Hmm, looking at the driver I think the only function that actually
>>>> is needed is poweroff() that would turn the fan in automatic mode
>>>> before shutting down. The driver does not perform any actions when
>>>> resuming so why bother?
>>>
>>> Agreed.
>>>
>>> Also, the fan comes out of warm and cold reboot in mode AUTO and
>>> when the driver is enabled, the fan is turned off on the next run of
>>> thermal_zone_device_update() when the read out temperature is within
>>> limits.
>>>
>>> Correct me if I'm wrong, but the only reason I see for setting the
>>> fan to mode AUTO before suspending/hibernating/etc is if it is taking
>>> a really long time to hibernate and write RAM image to disk and the
>>> machine is getting hot during that process. Otherwise, we might just
>>> as well do _nothing_ when suspending and remove all suspend/resume
>>> functionality altogether, no?
>>
>> This is right, currently the only reason for calling the suspend /
>> hibernate functions is to set the fan to auto to ensure it doesn't get
>> too hot while the kernel prepares the machine to suspend / hibernate.
>>
>> I would like to keep the resume function too. It's a nice to see
>> what's happening with verbose=1.
> 
> That's not a reason for keeping code in the kernel and raising bloat
> levels unnecessarily. If the driver doesn't need to do anything on
> resume, then no function is needed.

I don't think the verbose message is useless. If an user has a problem with 
suspend / hibernate I can just ask him to load the module with verbose=1 and 
dmesg tells whether the module is waking up or not. Searching for such an 
error is much easier this way as the user doesn't have to recompile the 
kernelmodule. In my opinion keeping these 4 lines of code is worth it.

kind 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ