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] [day] [month] [year] [list]
Message-id: <5493E01E.6090806@samsung.com>
Date:	Fri, 19 Dec 2014 17:21:50 +0900
From:	jonghwa3.lee@...sung.com
To:	myungjoo.ham@...sung.com
Cc:	이종화 <jonghwa3.lee@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"sre@...nel.org" <sre@...nel.org>,
	"dbaryshkov@...il.com" <dbaryshkov@...il.com>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"anton@...msg.org" <anton@...msg.org>,
	"pavel@....cz" <pavel@....cz>,
	최찬우 <cw00.choi@...sung.com>
Subject: Re: [PATCH RESEND v2 02/10] power: charger-manager: Use
 power_supply_changed() not private uevent.

On 2014년 12월 19일 16:41, MyungJoo Ham wrote:

>>   
>>  Whenever battery status is changed, charger manager tries to trigger uevent
>> through private interface. This patch modifies it to use power_supply_changed()
>> since it belongs to power supply subsystem.
>>
>> Signed-off-by: Jonghwa Lee <jonghwa3.lee@...sung.com>
> 
> The original uevent_notify() has two additional mechanisms:
> C1. Save events in suspend-again context and show them up at wakeup.
> C2. If the new event is a duplicated event, ignore it.
> 
> Questions:
> Q1. Have you checked if C1 is met with the modification? Besides, have
> you made it sure that the modification won't change the behavior of
> suspend-again context? (whether "theoretical" or "experimental")


It won't ruin suspend-again context because it just changes the location where
the charger manager's notice to go.

> Q2. Do you still support C2?
>   For example, if we have notifited the user that we are charging
>   30 seconds ago, we should never bother the user with another message
>   that declares that it is charging unless we have notified that
>   we are not charging since then.
> 


Above case never happens. If charging state is not changed, the report will not
be triggered. Maybe current driver will send same event repeatedly even though,
these patch series will guarantee not to do so.

And also if we have a status changing while short time wake-up which expects
suspend-again proceeds in near future, I think it is better to notify it to the
user not to keep until undetermined 'TRUE' wake-up.

Thanks,
Jonghwa

> Cheers,
> MyungJoo.
> 
>> ---
>>  drivers/power/charger-manager.c |   91 +++++----------------------------------
>>  1 file changed, 11 insertions(+), 80 deletions(-)
>>
> N�����r��y���b�X��ǧv�^�)޺{.n�+����{��h��.��ܨ}���Ơz�&j:+v���.����zZ+��+zf���h���~����i���z�.�w���?����&�)ߢ.fl===


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