2.6.24-rc1 acpi battery driver -> sysfs interface does not update correctly

PATCH New Ash Milsted 4 participants 19 messages Oct 24, 2007 – Oct 28, 2007 1 message not in the archive ACPI

Share & tools

Ash Milsted

author

2007-10-24 18:14 UTC #0 lore raw

Hello,

I just tried out the new RC on my laptop system, initially neglecting to enable ACPI_PROCFS support. Thus I was thrust into using the new sysfs interface for the battery.c driver. ..

Unfortunately the charge values etc do not seem to update periodically
- only (un)plugging the AC power updates the status if ACPI_PROCFS is disabled.
If ACPI_PROCFS is enabled then a read to /proc/acpi/battery/state gets the up-to-date data, and a subsequent read to the sysfs equivalents gives the same results - otherwise sysfs stays stale.

If you need any more info please say so - this is on an ageing Toshiba Satellite 1110.

Thanks,

Ash

Alexey Starikovskiy

2007-10-24 18:53 UTC #1 lore raw

Quoted 13 lines · Ash Milsted

Hello,
I just tried out the new RC on my laptop system, initially neglecting to enable ACPI_PROCFS support. Thus I was thrust into using the new sysfs interface for the battery.c driver. ..
Unfortunately the charge values etc do not seem to update periodically
- only (un)plugging the AC power updates the status if ACPI_PROCFS is disabled.
If ACPI_PROCFS is enabled then a read to /proc/acpi/battery/state gets the up-to-date data, and a subsequent read to the sysfs equivalents gives the same results - otherwise sysfs stays stale.

Quoted 2 lines

If you need any more info please say so - this is on an ageing Toshiba Satellite 1110.

Could you please test this patch?

Quoted 9 lines

Thanks,
Ash
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

ACPI: battery: run acpi_battery_update from sysfs read

From: Alexey Starikovskiy <[email protected]>

Update battery information at sysfs read.

Signed-off-by Alexey Starikovskiy <[email protected]>

---

 drivers/acpi/battery.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

drivers/acpi/battery.c +3 -0

index 681e26b..02a396d 100644
@@ -130,6 +130,8 @@ static int acpi_battery_technology(struct acpi_battery *battery)
 	return POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
 }
 
+static int acpi_battery_update(struct acpi_battery *battery);
+
 static int acpi_battery_get_property(struct power_supply *psy,
 				     enum power_supply_property psp,
 				     union power_supply_propval *val)

@@ -139,6 +141,7 @@ static int acpi_battery_get_property(struct power_supply *psy,
 	if ((!acpi_battery_present(battery)) &&
 	     psp != POWER_SUPPLY_PROP_PRESENT)
 		return -ENODEV;
+	acpi_battery_update(battery);
 	switch (psp) {
 	case POWER_SUPPLY_PROP_STATUS:
 		if (battery->state & 0x01)

Ash Milsted

author

2007-10-24 19:52 UTC #2 lore raw

Quoted 1 line · Alexey Starikovskiy

Could you please test this patch?

Appears to work again - sysfs values now seem to update correctly without help from a proc read. Will check without ACPI_PROCFS and let you know if anything still seems wrong.

Ash

Ash Milsted

author

2007-10-24 20:23 UTC #3 lore raw

Quoted 9 lines · Ash Milsted

Quoted 1 line · Alexey Starikovskiy
Could you please test this patch?
Appears to work again - sysfs values now seem to update correctly without help from a proc read. Will check without ACPI_PROCFS and let you know if anything still seems wrong.
Ash

Okay, I have a further suspicion that uevents are not being sent as the battery charge changes. I have HAL 0.5.10 running and it only updates it's battery status if I (un)plug the power, despite cat /sys/class/power_supply/BAT1/charge_now now giving a current value.

Alexey Starikovskiy

2007-10-24 20:33 UTC #4 lore raw

Quoted 7 lines · Ash Milsted

Quoted 6 lines · Ash Milsted
Quoted 1 line · Alexey Starikovskiy
Could you please test this patch?
Appears to work again - sysfs values now seem to update correctly without help from a proc read. Will check without ACPI_PROCFS and let you know if anything still seems wrong.

Quoted 8 lines

Quoted 2 lines
Ash
Okay, I have a further suspicion that uevents are not being sent as the battery charge changes. I have HAL 0.5.10 running and it only updates it's battery status if I (un)plug the power, despite cat /sys/class/power_supply/BAT1/charge_now now giving a current value.

This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?

Ash Milsted

author

2007-10-24 21:17 UTC #5 lore raw

Quoted 11 lines · Alexey Starikovskiy

Quoted 10 lines · Ash Milsted
Quoted 8 lines · Ash Milsted
Quoted 1 line · Alexey Starikovskiy
Could you please test this patch?
Appears to work again - sysfs values now seem to update correctly without help from a proc read. Will check without ACPI_PROCFS and let you know if anything still seems wrong.
Ash

Quoted 9 lines

Quoted 5 lines
Okay, I have a further suspicion that uevents are not being sent as the battery charge changes. I have HAL 0.5.10 running and it only updates it's battery status if I (un)plug the power, despite cat /sys/class/power_supply/BAT1/charge_now now giving a current value.
This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?

Forgive my ignorance, but I'm not entirely sure how to capture uevents. If "udevmonitor --kernel" is sufficient then it appears there are no events associated with the battery discharging or charging, whereas those associated with (un)plugging do appear. To clarify, I've seen cat /sys/.../charge_now change without udevmonitor picking up a single kernel event.

Alexey Starikovskiy

2007-10-24 21:49 UTC #6 lore raw

Quoted 20 lines · Ash Milsted

Quoted 10 lines · Alexey Starikovskiy
Quoted 9 lines · Ash Milsted
Quoted 8 lines · Ash Milsted
Quoted 1 line · Alexey Starikovskiy
Could you please test this patch?
Appears to work again - sysfs values now seem to update correctly without help from a proc read. Will check without ACPI_PROCFS and let you know if anything still seems wrong.
Ash
Quoted 9 lines
Quoted 5 lines
Okay, I have a further suspicion that uevents are not being sent as the battery charge changes. I have HAL 0.5.10 running and it only updates it's battery status if I (un)plug the power, despite cat /sys/class/power_supply/BAT1/charge_now now giving a current value.
This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?

Quoted 6 lines

Forgive my ignorance, but I'm not entirely sure how to capture uevents. If "udevmonitor --kernel" is sufficient then it appears there are no events associated with the battery discharging or charging, whereas those associated with (un)plugging do appear. To clarify, I've seen cat /sys/.../charge_now change without udevmonitor picking up a single kernel event.

Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c? This is the only place which could send uevent. If you don't see this printk in dmesg, then HAL uses some other method to get battery state changes.

Ash Milsted

author

2007-10-24 22:28 UTC #7 lore raw

Quoted 12 lines · Alexey Starikovskiy

Quoted 11 lines · Ash Milsted
Quoted 4 lines · Alexey Starikovskiy
This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?
Forgive my ignorance, but I'm not entirely sure how to capture uevents. If "udevmonitor --kernel" is sufficient then it appears there are no events associated with the battery discharging or charging, whereas those associated with (un)plugging do appear. To clarify, I've seen cat /sys/.../charge_now change without udevmonitor picking up a single kernel event.

Quoted 4 lines

Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c? This is the only place which could send uevent. If you don't see this printk in dmesg, then HAL uses some other method to get battery state changes.

I can confirm that this function is *not* called as the battery (dis)charges (having seen charge_now fall), but is called on power-plug events.

Ash Milsted

2007-10-24 22:37 UTC #8 lore raw

Quoted 13 lines · Ash Milsted

Quoted 12 lines · Alexey Starikovskiy
Quoted 11 lines · Ash Milsted
Quoted 4 lines · Alexey Starikovskiy
This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?
Forgive my ignorance, but I'm not entirely sure how to capture uevents. If "udevmonitor --kernel" is sufficient then it appears there are no events associated with the battery discharging or charging, whereas those associated with (un)plugging do appear. To clarify, I've seen cat /sys/.../charge_now change without udevmonitor picking up a single kernel event.

Quoted 7 lines

Quoted 4 lines
Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c? This is the only place which could send uevent. If you don't see this printk in dmesg, then HAL uses some other method to get battery state changes.
I can confirm that this function is *not* called as the battery (dis)charges (having seen charge_now fall), but is called on power-plug events.

Sorry... I mean it appears to be called on module-insertion and then *never* again (not on plug events).

Alexey Starikovskiy

2007-10-25 03:09 UTC #9 lore raw

Quoted 18 lines · Ash Milsted

Quoted 17 lines · Ash Milsted
Quoted 16 lines · Alexey Starikovskiy
Quoted 11 lines · Ash Milsted
Quoted 4 lines · Alexey Starikovskiy
This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?
Forgive my ignorance, but I'm not entirely sure how to capture uevents. If "udevmonitor --kernel" is sufficient then it appears there are no events associated with the battery discharging or charging, whereas those associated with (un)plugging do appear. To clarify, I've seen cat /sys/.../charge_now change without udevmonitor picking up a single kernel event.
Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c? This is the only place which could send uevent. If you don't see this printk in dmesg, then HAL uses some other method to get battery state changes.

Quoted 6 lines

Quoted 3 lines
I can confirm that this function is *not* called as the battery (dis)charges (having seen charge_now fall), but is called on power-plug events.
Sorry... I mean it appears to be called on module-insertion and then *never* again (not on plug events).

Could you please confirm, that there were no battery discharge uevents before, e.g in 2.6.23?

Ash Milsted

author

2007-10-25 09:31 UTC #10 lore raw

Quoted 19 lines · Alexey Starikovskiy

Quoted 18 lines · Ash Milsted
Quoted 17 lines · Ash Milsted
Quoted 16 lines · Alexey Starikovskiy
Quoted 11 lines · Ash Milsted
Quoted 4 lines · Alexey Starikovskiy
This one is not easy. According to code, it should send twice as many notifications now. One over netlink, and one as power_supply class device...
Could you log all the uevents?
Forgive my ignorance, but I'm not entirely sure how to capture uevents. If "udevmonitor --kernel" is sufficient then it appears there are no events associated with the battery discharging or charging, whereas those associated with (un)plugging do appear. To clarify, I've seen cat /sys/.../charge_now change without udevmonitor picking up a single kernel event.
Could you try to insert prink() into acpi_battery_notify() in drivers/acpi/battery.c? This is the only place which could send uevent. If you don't see this printk in dmesg, then HAL uses some other method to get battery state changes.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
I can confirm that this function is *not* called as the battery (dis)charges (having seen charge_now fall), but is called on power-plug events.
Sorry... I mean it appears to be called on module-insertion and then *never* again (not on plug events).
Could you please confirm, that there were no battery discharge uevents before, e.g in 2.6.23?

Just tested the stock Archlinux 2.6.23.1 - no discharge uevents *or* (un)plug uevents no matter what I do. Reading the relevant proc file always gives the current state of the battery.

Also, back on 2.6.24-rc1, it seems I can provoke a single 'changed' uevent (my printks trigger) after a reboot by reading charge_now a couple of times (it does not seem to occur spontaneously). What happens is that the charge_now value 'jumps' to an apparently odd value (e.g. it increases a little even though AC is unplugged) on the read that triggers the uevent and then settles back to normal on subsequent reads. After that single event I get no response and everything is as before (the function is never called again)

Ash Milsted

author

2007-10-27 16:52 UTC #11 lore raw

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

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.

Alexey Starikovskiy

2007-10-27 17:23 UTC #12 lore raw

Quoted 4 lines · Ash Milsted

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?

Quoted 4 lines

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.

Quoted 16 lines

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

Quoted 3 lines

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.

drivers/acpi/battery.c +1 -0

index 6c06879..bcd489c 100644
@@ -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;
 }

Ash Milsted

author

2007-10-28 12:06 UTC #13 lore raw

Quoted 6 lines · Alexey Starikovskiy

Quoted 4 lines · Ash Milsted
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?

Yeah, no uevents for (dis)charges or (un)plugs in 2.6.23.

Quoted 3 lines

Quoted 3 lines
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.

Reading the sysfs value is, it turns out, not necessary to trigger this single update (which also sends a change uevent). I guess this is just the battery driver grabbing the initial value - after that there are no more change uevents.

Quoted 2 lines

Quoted 1 line
I attach a few extra details, in case they help.
your acpidump output might be usefull at this point.

Attached.

Quoted 16 lines

Quoted 16 lines
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

Quoted 5 lines

Quoted 3 lines
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

Turns out that the string was "Li-Ion", not "lion". ...ACPI: unmatched technology 'Li-Ion'
I guess, chemically speaking, it's more precise :)

Quoted 2 lines

Thanks,
Alex.

No problem. One other thing - I just saw this is my dmesg...

Oct 28 13:41:49 tuktuk omnibook: Driver version 2.20070211-trunk.
Oct 28 13:41:49 tuktuk omnibook: Toshiba Satellite 1110 detected.
Oct 28 13:41:49 tuktuk omnibook: LCD backlight turn off at console
blanking is enabled.
Oct 28 13:41:49 tuktuk omnibook: Enabling all hotkeys.
Oct 28 13:41:49 tuktuk ACPI: EC: non-query interrupt received,

switching to interrupt mode

ACPI switched to interrupt mode only after the (out-of-tree) omnibook driver loads. Will test without this module, however I know it was not loaded when I tested 2.6.23.

Ash

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alexey Starikovskiy

2007-10-28 12:33 UTC #15 lore raw

PATCH 1/1 ACPI: battery: Support for non-spec name for LiIon technology

Support Li-Ion as possible name for technology.

Signed-off-by Alexey Starikovskiy <[email protected]>

---

 drivers/acpi/battery.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

drivers/acpi/battery.c +2 -0

index 6c06879..06b68de 100644
@@ -125,6 +125,8 @@ static int acpi_battery_technology(struct acpi_battery *battery)
 		return POWER_SUPPLY_TECHNOLOGY_NiMH;
 	if (!strcasecmp("LION", battery->type))
 		return POWER_SUPPLY_TECHNOLOGY_LION;
+	if (!strcasecmp("LI-ION", battery->type))
+		return POWER_SUPPLY_TECHNOLOGY_LION;
 	if (!strcasecmp("LiP", battery->type))
 		return POWER_SUPPLY_TECHNOLOGY_LIPO;
 	return POWER_SUPPLY_TECHNOLOGY_UNKNOWN;

Alexey Starikovskiy

2007-10-28 12:41 UTC #16 lore raw

In reply to a message not in the archive

Quoted 9 lines · Ash Milsted

Quoted 9 lines

No problem. One other thing - I just saw this is my dmesg...

Oct 28 13:41:49 tuktuk omnibook: Driver version 2.20070211-trunk.
Oct 28 13:41:49 tuktuk omnibook: Toshiba Satellite 1110 detected.
Oct 28 13:41:49 tuktuk omnibook: LCD backlight turn off at console
blanking is enabled.
Oct 28 13:41:49 tuktuk omnibook: Enabling all hotkeys.
Oct 28 13:41:49 tuktuk ACPI: EC: non-query interrupt received,

switching to interrupt mode

Quoted 7 lines

Quoted 4 lines
ACPI switched to interrupt mode only after the (out-of-tree) omnibook driver loads. Will test without this module, however I know it was not loaded when I tested 2.6.23.
Okay - eliminating the omnibook module has no effect on the battery issue and the "switching to interrupt mode" message appears at some point anyway. There goes one more shot-in-the-dark.

Don't bother, this is new auto-switching mode behavior of EC driver. It now starts in poll (safe) mode, and if gets interrupts goes into interrupt mode.

Problem (not fatal) would be if it starts oscillating between modes.

Quoted 3 lines

Ash

Alexey Starikovskiy

2007-10-28 12:58 UTC #17 lore raw

In reply to Ash Milsted

Quoted 19 lines · Ash Milsted

Quoted 6 lines · Alexey Starikovskiy
Quoted 4 lines · Ash Milsted
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?
Yeah, no uevents for (dis)charges or (un)plugs in 2.6.23.
Quoted 3 lines
Quoted 3 lines
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.
Reading the sysfs value is, it turns out, not necessary to trigger this single update (which also sends a change uevent). I guess this is just the battery driver grabbing the initial value - after that there are no more change uevents.

Quoted 5 lines

Quoted 2 lines
Quoted 1 line
I attach a few extra details, in case they help.
your acpidump output might be usefull at this point.
Attached.

Ok, it seems to be related with ECDY variable of your DSDT.
It is equal to 5 by default, but could be set to 0 or 3 if _OS string matches
some magic length (guess Linux does not match).
BST (method for reading state out of memory) may send notify event if ECDY
is 1 (it will become this only uevent you see at very start).
I do not see how battery driver could help in this situation.
What you could do is try to play with acpi_os variable so that ECDY becomes 0.
You also could patch your DSDT to have ECDY=0 always (or try to update BIOS, it might be done already).

Ash Milsted

author

2007-10-28 14:03 UTC #18 lore raw

Quoted 9 lines · Alexey Starikovskiy

Ok, it seems to be related with ECDY variable of your DSDT.
It is equal to 5 by default, but could be set to 0 or 3 if _OS string matches
some magic length (guess Linux does not match).
BST (method for reading state out of memory) may send notify event if ECDY
is 1 (it will become this only uevent you see at very start).
I do not see how battery driver could help in this situation.
What you could do is try to play with acpi_os variable so that ECDY becomes 0.
You also could patch your DSDT to have ECDY=0 always (or try to update BIOS, it might be done already).

I see. I'll see what I can do to get that fixed, although I think I'm using the latest bios for this machine. I guess I'll play with the acpi_os value.

I wonder how common this problem is. This laptop is quite old (Toshiba Satellite 1110), but if this is a common issue I guess it makes sense for either HAL or the battery driver to poll in certain cases (e.g. poll if we haven't been receiving events/interrupts but we should be charging/discharging or, if it ain't common, this could be a HAL 'quirk'). As long as users of the uevent interface are aware of this possible issue I guess they could be responsible for polling - do you think I should let the HAL guys know?

Ash

Alexey Starikovskiy

2007-10-28 14:27 UTC #19 lore raw

Quoted 2 lines · Ash Milsted

I wonder how common this problem is. This laptop is quite old (Toshiba Satellite 1110), but if this is a common issue I guess it makes sense

I've seen only one bug report with similar issue -- DSDT required 10 false _BST executions before returning actual value.
So, I'd say it is rare enough.

Quoted 6 lines

for either HAL or the battery driver to poll in certain cases (e.g. poll if we haven't been receiving events/interrupts but we should be charging/discharging or, if it ain't common, this could be a HAL 'quirk'). As long as users of the uevent interface are aware of this possible issue I guess they could be responsible for polling - do you think I should let the HAL guys know?

You decide :)