Re: [PATCH] ACPI/Battery: Retry to get Battery information if failed during probing

[Lan Tianyu <tianyu.lan@intel.com>]

On 2014年06月12日 14:55, David Rientjes wrote:
> On Thu, 12 Jun 2014, Lan Tianyu wrote:
> 
>> Some machines'(E,G Lenovo Z480) ECs are not stable during boot up
>> and causes battery driver fails to be probed due to failure of getting
>> battery information from EC sometimes. After several retries, the
>> operation will work. This patch is to retry to get battery information 5
>> times if the first try fails.
>>
>> Reported-and-tested-by: naszar <naszar@ya.ru>
>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75581
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>> ---
>>  drivers/acpi/battery.c | 12 +++++++++++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
>> index e48fc98..485009d 100644
>> --- a/drivers/acpi/battery.c
>> +++ b/drivers/acpi/battery.c
>> @@ -34,6 +34,7 @@
>>  #include <linux/dmi.h>
>>  #include <linux/slab.h>
>>  #include <linux/suspend.h>
>> +#include <linux/delay.h>
>>  #include <asm/unaligned.h>
>>  
>>  #ifdef CONFIG_ACPI_PROCFS_POWER
>> @@ -1119,7 +1120,7 @@ static struct dmi_system_id bat_dmi_table[] = {
>>  
>>  static int acpi_battery_add(struct acpi_device *device)
>>  {
>> -	int result = 0;
>> +	int result = 0, retry = 5;
>>  	struct acpi_battery *battery = NULL;
>>  
>>  	if (!device)
>> @@ -1135,7 +1136,16 @@ static int acpi_battery_add(struct acpi_device *device)
>>  	mutex_init(&battery->sysfs_lock);
>>  	if (acpi_has_method(battery->device->handle, "_BIX"))
>>  		set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
>> +
>> +retry_get_info:
>>  	result = acpi_battery_update(battery, false);
>> +
>> +	if (result && retry) {
>> +		msleep(20);
> 

Hi David:
	Thanks for review.

> We're really going to wait up to 20 * 5 = 100ms for acpi_battery_update() 
> to succeed?

No, this depends which retry acpi_battery_update() will succeed. For
most machines, there will be no delay.

> How are these the numbers that are determined to be optimal 
> for probing?

So far, it depends the return values of executing ACPI methods. If they
were failed, the probing would not go further.

> 
>> +		retry--;
>> +		goto retry_get_info;
>> +	}
> 
> This most certainly could be rewritten as a for-loop and remove the ugly 
> goto.

Ok. I will update.

> 
>> +
>>  	if (result)
>>  		goto fail;
>>  #ifdef CONFIG_ACPI_PROCFS_POWER


-- 
Best regards
Tianyu Lan