Ash Milsted wrote:
> Hi again,
> I just thought I'd say that this is still occuring with the current
> linux-acpi-2.6 git tree on top of Linus' latest.. I don't get
> (dis)charge uevents and, oddly, the sysfs charge_now value is
As I remember, you did not found uevents in 2.6.23 as well?
> initially wrong on boot-up. For some reason it gives a value of about
> half the full charge of the battery (no matter what the true value is)
> until I read it a couple of times, at which point it corrects itself.
> I attach a few extra details, in case they help.
your acpidump output might be usefull at this point.
>
> cat /sys/class/power_supply/BAT1/uevent
> POWER_SUPPLY_NAME=BAT1
> POWER_SUPPLY_TYPE=Battery
> POWER_SUPPLY_STATUS=Charging
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_TECHNOLOGY=Unknown
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=14800000
> POWER_SUPPLY_VOLTAGE_NOW=14800000
> POWER_SUPPLY_CURRENT_NOW=0
> POWER_SUPPLY_CHARGE_FULL_DESIGN=4000000
> POWER_SUPPLY_CHARGE_FULL=4000000
> POWER_SUPPLY_CHARGE_NOW=1960000
> POWER_SUPPLY_MODEL_NAME=PABAS005
> POWER_SUPPLY_MANUFACTURER=TOSHIBA
>
> One odd thing about this is the TECHNOLOGY field - with the procfs
> interface it is reported as lion, not "Unknown". As before, if I any
> other info would help, just ask.
I check against "LION" (strcasecmp), so lion should be recognized.
Please take a look on dmesg with attached patch
Thanks,
Alex.
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 6c06879..bcd489c 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -127,6 +127,7 @@ static int acpi_battery_technology(struct acpi_battery *battery)
return POWER_SUPPLY_TECHNOLOGY_LION;
if (!strcasecmp("LiP", battery->type))
return POWER_SUPPLY_TECHNOLOGY_LIPO;
+printk(KERN_ERR PREFIX "unmatched technology '%s'\n", battery->type);
return POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
}
