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