linux-kernel - Re: [PATCH V3 11/11] power: charger-manager: Support to change polling rate in runtime.

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]

Message-id: <54977A7D.2060301@samsung.com>
Date:	Mon, 22 Dec 2014 10:57:17 +0900
From:	jonghwa3.lee@...sung.com
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	sre@...nel.org, dbaryshkov@...il.com, dwmw2@...radead.org,
	anton@...msg.org, myungjoo.ham@...sung.com, cw00.choi@...sung.com
Subject: Re: [PATCH V3 11/11] power: charger-manager: Support to change polling
 rate in runtime.

On 2014년 12월 20일 09:29, Pavel Machek wrote:

> 
>> Add 'polling_ms' sysfs node to change charger-manager's monitoring rate
>> in runtime. It can set only bigger than 2 jiffies (for 200 HZ system it
>> is 10 msecs.) as it's allowed for minimum poling rate in previous.
> 
> New sysfs filesneed documentation.
> 
>> It resets poller and re-configure polling rate based on new input if next
> 
> re-configures...", if"
> 
>> polling time is far enough. Otherwise, it just waits expiration of timer
> 
> "waits for"
> 
>> and new polling rate will affects the next scheduling.
> 
> "affect"?
> 


Sorry for so many typos.. including above typos I'll revise all of them.

> 
>> +static ssize_t show_polling_ms(struct device *dev,
>> +				struct device_attribute *attr, char *buf)
>> +{
>> +	struct charger_manager *cm;
>> +	ssize_t len;
>> +
>> +	list_for_each_entry(cm, &cm_list, entry)
>> +		if (cm->charger_psy.dev == dev)
>> +			break;
>> +
>> +	if (cm->charger_psy.dev != dev)
>> +		return -EINVAL;
> 
> Any chance to reorganize data structures so that this kind of list
> walking is not neccessary?
> 


No need to reorganize, I'll fix it to get target data without unnecessary
iteration.

>> +static ssize_t store_polling_ms(struct device *dev,
>> +				struct device_attribute *attr, const char *buf,
>> +				size_t count)
>> +{
>> +	struct charger_manager *cm;
>> +	int polling_ms;
>> +	int ret;
>> +
>> +	ret = sscanf(buf, "%d", &polling_ms);
> 
> "kstrtoul"?
> 


Yes, it would be better. I'll modify it either.

Thanks for reviewing.
Jonghwa

> 									Pavel


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