Open networkimprov opened 9 years ago
Can confirm power_supply_changed() is the only visible uevent from the driver. Need to check the effort for battery percentage calculations.
@networkimprov @tmlind Reviewing the other battery drivers in drivers/power and none use uevents to report battery levels. Are we sure that we want to rely on uevents + udev?
Seems an daemon service polling the battery capacity property would be a better solution?
Under what conditions does the driver call power_supply_changed()? I imagined catching one of those events...
Does the driver already support sysfs_notify?
On Tue, Sep 13, 2016 at 4:13 PM, Liam notifications@github.com wrote:
Under what conditions does the driver call power_supply_changed()? I imagined catching one of those events...
Actually it is reporting battery percentage left in 3% steps.. so nothing to do here kernel wise.
$ udevadm monitor --kernel --property .... ACTION=change DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 POWER_SUPPLY_CAPACITY=85 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_CHARGE_FULL=1127000 POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000 POWER_SUPPLY_CHARGE_NOW=996000 POWER_SUPPLY_CURRENT_NOW=-340000 POWER_SUPPLY_MANUFACTURER=Texas Instruments POWER_SUPPLY_NAME=bq27425-0 POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_TEMP=457 POWER_SUPPLY_VOLTAGE_NOW=3841000 SEQNUM=1430 SUBSYSTEM=power_supply ...
Does the driver already support sysfs_notify?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-246855574, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOcyXJQuzq1pICfdVug2WSZL68GOgks5qpy4GgaJpZM4DSnCg .
OK, but maybe it should report more often under 10%...
Ah it is a poll interval of 6 minutes, not anything with 3% discharge.
Do you want to decrease the poll_interval?
.....
static unsigned int poll_interval = 360;
module_param(poll_interval, uint, 0644);
MODULE_PARM_DESC(poll_interval,
"battery poll interval in seconds - 0 disables polling");
.....
Ya, let's reduce that under 10% to 3min, and maybe again to 1min.
Ok will add this functionality today.
@tmlind @networkimprov Patchset to enable configurable poll_interval rates for battery level
https://github.com/networkimprov/linux/commit/524bf5b08794abb354432996d55d1e0d4258d576.patch https://github.com/networkimprov/linux/commit/cc51ae388ff936ce4647d691c5cadc88232ee0b6.patch
Is OK/preferable to make a new branch (off anvl-v4.7) for patches to a diff component :-)
I don't think we need to emit uevent if the battery level hasn't changed since last poll.
Can you draft a sample udev rule for the gauge? I gather it can adjust the poll_interval depending on battery capacity?
Ok I'll look into the udev rule... not sure you can have conditionals greater or less than for battery capacity rule
I'll add a couple rules with wildcards to adjust down the poll_interval, just need to know how to set it, e.g.
KERNEL=="bq..." ACTION=="change" ATTR{voltage}=="3.[65]*" ATTR{poll_interval}="180" RUN+="/bin/sh -c 'echo DING > /dev/console'"
Can you test this rule idea...
KERNEL=="bq..." ACTION=="change" ATTR{voltage}=="3.[65]*" ATTR{poll_interval}="180" RUN+="/bin/sh -c 'echo DING > /dev/console'"
On Fri, Sep 16, 2016 at 12:18 PM, Liam notifications@github.com wrote:
Can you test this rule idea...
Ok will do.. I think the voltage needs to be voltage_now and it isn't a floating point but in microvolts
KERNEL=="bq..." ACTION=="change" ATTR{voltage}=="3.[65]*" ATTR{poll_interval}="180" RUN+="/bin/sh -c 'echo DING > /dev/console'"
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-247684554, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOXdSnzHXUH35ASL1JVLQzDXJpoHFks5qquuYgaJpZM4DSnCg .
Should match uV: {voltage_now}=="3[654]?????"
KERNEL=="bq27425-0" ACTION=="change" ATTRS{voltage_now}=="3[56]*" RUN+="/bin/sh -c 'echo DING > /dev/console'"
Works. However dropped the ATTRS{poll_interval} because that will not exist because /sys/module/bq27xxx_battery/parameters/poll_interval is the correct place since it already exists
@tmlind Please review. https://github.com/networkimprov/linux/commit/cba20bc11b8a3c6a469e2401a3670201f8d12e15.patch
We need to write poll_interval from the rule. Can we move the existing sysfs entity, or add a sysfs entity which is an alias for it?
Can't do?
KERNEL=="bq27425-0" ACTION=="change" ATTRS{voltage_now}=="3[56]*" RUN+="/bin/sh -c 'echo 10 > /sys/module/bq27xxx_battery/parameters/poll_interval'"
Well, ya, but that's not what users expect; voltage_now is available; why not poll_interval?
On Fri, Sep 16, 2016 at 6:41 PM, Liam notifications@github.com wrote:
Well, ya, but that's not what users expect; voltage_now is available; why not poll_interval?
voltage_now is an actual device related to a changing quantity.
poll_interval is a kernel parameter isn't going to change without userspace doing it, and I don't see anyone basing rules on what a ATTR{poll_interval} is set too (and really shouldn't). And much more importantly the sysfs way will not be accepted upstream (at least I suspect so, maybe Tony has thoughts on that) because a kernel parameter already exists.
—
You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-247741868, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOUIheAn6tdmabjo2vXKjEN1xrbSlks5qq0U3gaJpZM4DSnCg .
I need it accessible in udev to assign to it, not read it; lots of rules do ATTR{thing}="x"
On Fri, Sep 16, 2016 at 7:31 PM, Liam notifications@github.com wrote:
I need it accessible in udev to assign to it, not read it; lots of rules do ATTR{thing}="x"
Ah of course... ok so the previous patchset is good enough for that then. Having that use case maybe upstream will be okay... be nice to avoid any technical debt though
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-247744214, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOT1kxqrAKG49Vn0_Xdd6KNiL9N0aks5qq1EFgaJpZM4DSnCg .
Can you post patch you sent upstream to your bq27xxx branch (after reverting https://github.com/networkimprov/linux/commit/2aeea223) ?
The power-supply fix, if allowed upstream, can also go on this branch.
Ok will do.
On Tue, Sep 20, 2016 at 11:12 AM, Liam notifications@github.com wrote:
Can you post patch you sent upstream to your bq27xxx branch (after reverting networkimprov/linux@2aeea22 https://github.com/networkimprov/linux/commit/2aeea223) ?
The power-supply fix, if allowed upstream, can also go on this branch.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248384942, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXORIblAm8vr2sJjygYvfJP7ztZfLkks5qsCH4gaJpZM4DSnCg .
Re property UPDATE_INTERVAL when I apply these two https://github.com/networkimprov/linux/commit/2626f43c (accepted upstream) https://github.com/networkimprov/linux/compare/b2cc66eb...7bf8c2ef (new patches)
I get: error: patch failed: drivers/power/bq27xxx_battery.c:1026 error: drivers/power/bq27xxx_battery.c: patch does not apply
On Tue, Sep 20, 2016 at 8:16 PM, Liam notifications@github.com wrote:
Re property UPDATE_INTERVAL when I apply these two networkimprov/linux@2626f43 https://github.com/networkimprov/linux/commit/2626f43c (accepted upstream) networkimprov/linux@b2cc66e...7bf8c2e https://github.com/networkimprov/linux/compare/b2cc66eb...7bf8c2ef (new patches)
I get: error: patch failed: drivers/power/bq27xxx_battery.c:1026 error: drivers/power/bq27xxx_battery.c: patch does not apply
Probably since I reverted that sysfs way in that branch as well.. we probably want rebase interactive and drop the reverts and original patches at some point.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248500032, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOQT6gqDJxl5QQTG3ZcwNapt6ji0uks5qsKGcgaJpZM4DSnCg .
Would you want to call the new poll_interval_param_set() in new set_property()?
On Tue, Sep 20, 2016 at 8:33 PM, Liam notifications@github.com wrote:
Would you want to call the new poll_interval_param_set() in net set_property()?
I don't, and this has nothing to do with that other method. What I am saying is a simple cherry-pick to the anvl-4.7 branch isn't going to work.
Note the revert here of the sysfs way of updating https://github.com/networkimprov/linux/commit/b2cc66eb60dbd4f78cffaf857e1ea7c4e1c61a10
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248502190, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOemKIF3RnwassoThZXc8VbbfyucAks5qsKVxgaJpZM4DSnCg .
You can fix the patch-apply issue when sending upstream; not important for me now.
Aren't poll_interval_param_set() and set_property() updating the same field?
On Tue, Sep 20, 2016 at 8:49 PM, Liam notifications@github.com wrote:
You can fix the patch-apply issue when sending upstream; not important for me now.
Aren't poll_interval_param_set() and set_property() updating the same field?
Yes there are. Shouldn't need locking on the global... ideally it would be in the data struct for the driver, but can't break the ABI.
Maybe Tony can comment on if this is the best way.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248504204, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOa90KYBy0zezc-UhM4QkQfpydMEwks5qsKlQgaJpZM4DSnCg .
Ah, setting module param updates every instance of the driver, and new patch updates one instance. Why didncha say so! :-)
This file needs a description of the new param: https://github.com/networkimprov/linux/blob/anvl-v4.7-bq27xxx/Documentation/power/power_supply_class.txt
There are two existing time parameters; maybe we should use "TIME_TO_UPDATE"?
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load)
TIME_TO_FULL - seconds left for battery to be considered full (i.e. while battery is charging)
Besides docs, looks good to go upstream :-)
If they complain that we are the only client for this option, I'm sure we can find other drivers that are the sole clients of different options!
On Wed, Sep 21, 2016 at 11:50 AM, Liam notifications@github.com wrote:
This file needs a description of the new param: https://github.com/networkimprov/linux/blob/anvl- v4.7-bq27xxx/Documentation/power/power_supply_class.txt
There are two existing time parameters; maybe we should use "TIME_TO_UPDATE"?
Yeah only issue with using that is that assumes it is a countdown till the next update...
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load) TIME_TO_FULL - seconds left for battery to be considered full (i.e. while battery is charging)
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-248706529, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOdz4dkMof2047APAYZrDWvaPdb4gks5qsXxegaJpZM4DSnCg .
True, and time_between_updates is a lil verbose. Perhaps stick with poll_interval since that's the module param?
fyi, I pushed patch already accepted upstream to anvl-v4.7
What do you think about reposting this patchset with a Documentation rev, and CC'ing Sebastian? http://lkml.iu.edu/hypermail/linux/kernel/1609.2/04064.html
Ok needs to be done. Better than poking him I guess :)
On Mon, Sep 26, 2016 at 2:09 PM, Liam notifications@github.com wrote:
What do you think about reposting this patchset with a Documentation rev, and CC'ing Sebastian? http://lkml.iu.edu/hypermail/linux/kernel/1609.2/04064.html
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249698182, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOZ0xV7vBllCAttRmhpY0bINW3a9uks5quDRtgaJpZM4DSnCg .
Yes :) Post docs commit on https://github.com/networkimprov/linux/commits/anvl-v4.7-bq27xxx
Proposed param docs:
TIME_TO_FULL - seconds left for battery ...
POLL_INTERVAL - seconds between I2C requests to retrieve battery
stats from chip.
On Mon, Sep 26, 2016 at 8:32 PM, Liam notifications@github.com wrote:
Proposed param docs:
TIME_TO_FULL - seconds left for battery ... POLL_INTERVAL - seconds between I2C requests to retrieve battery stats from chip.
We shouldn't say the interface.. it doesn't have to be I2C there are likely SPI, and other interface fuel gauge parts.
https://github.com/networkimprov/linux/blob/anvl- v4.7-bq27xxx/Documentation/power/power_supply_class.txt
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249757628, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOTuez-P2VHpY6ep3q4ZZ279ANHaMks5quI5MgaJpZM4DSnCg .
OK
Unrelated to poll_interval... We used to apply this patch. The current code has just one compatible item and no #else section. Do we need this?
+#ifdef CONFIG_OF
+static const struct of_device_id bq27xxx_of_match[] = {
+ { .compatible = "ti,bq27200", },
+ { .compatible = "ti,bq27500", },
+ { .compatible = "ti,bq27425", },
+ { .compatible = "ti,bq27742", },
+ { .compatible = "ti,bq27518", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, bq27xxx_of_match);
+#else
+static const struct of_device_id bq27xxx_of_match[] = {
+ { },
+};
+#endif
On Tue, Sep 27, 2016 at 1:20 PM, Liam notifications@github.com wrote:
Unrelated to poll_interval... We used to apply this patch. The current code has just one compatible item and no #else section. Do we need this?
Probably not.. but I'll check this afternoon
+#ifdef CONFIG_OF +static const struct of_device_id bq27xxx_of_match[] = {
- { .compatible = "ti,bq27200", },
- { .compatible = "ti,bq27500", },
- { .compatible = "ti,bq27425", },
- { .compatible = "ti,bq27742", },
- { .compatible = "ti,bq27518", },
- { }, +}; +MODULE_DEVICE_TABLE(of, bq27xxx_of_match); +#else +static const struct of_device_id bq27xxx_of_match[] = {
- { }, +}; +#endif
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249986043, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOWXoWXiG8-qLEXCo3kBn0_XMeQwgks5quXqAgaJpZM4DSnCg .
On Tue, Sep 27, 2016 at 1:33 PM, Matt Ranostay mranostay@gmail.com wrote:
On Tue, Sep 27, 2016 at 1:20 PM, Liam notifications@github.com wrote:
Unrelated to poll_interval... We used to apply this patch. The current code has just one compatible item and no #else section. Do we need this?
Probably not.. but I'll check this afternoon
We could change the "ti,bq27425" in our device tree to "ti,bq27000" so we don't have to worry about that patchset.
I suspect a) another version got upstreamed b) or the maintainer rathers to keep the match table more generic unless a device needs the data pointer.
+#ifdef CONFIG_OF +static const struct of_device_id bq27xxx_of_match[] = {
- { .compatible = "ti,bq27200", },
- { .compatible = "ti,bq27500", },
- { .compatible = "ti,bq27425", },
- { .compatible = "ti,bq27742", },
- { .compatible = "ti,bq27518", },
- { }, +}; +MODULE_DEVICE_TABLE(of, bq27xxx_of_match); +#else +static const struct of_device_id bq27xxx_of_match[] = {
- { }, +}; +#endif
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-249986043, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOWXoWXiG8-qLEXCo3kBn0_XMeQwgks5quXqAgaJpZM4DSnCg .
Please review the same two patchsets from before now on the anvl-v4.7-bq27xxx branch. Only changes is the property name and two patchsets have been squashed. Let me know if anything needs to be updated (maybe docs ?) before sending off v2
There's a grammar flaw in docs. How about:
POLL_INTERVAL - seconds between queries to retrieve stats from hardware.
Sent from my iPhone
On Sep 27, 2016, at 18:04, Liam notifications@github.com wrote:
Please review the same two patchsets from before now on the anvl-v4.7-bq27xxx branch. Only changes is the property name and two patchsets have been squashed. Let me know if anything needs to be updated (maybe docs ?) before sending off v2
There's a grammar flaw in docs. How about:
POLL_INTERVAL - seconds between queries to retrieve stats from hardware.
Ok thought I recalled a comment about that issue. Will fix
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.
My gauge claims to be charging when it's discharging. The first check, shortly after boot, is correct. Within an hour it was wrong. Hope this is a driver bug vs hw...
[root@anvl ~]# udevadm info /sys/class/power_supply/bq27425-0
P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: POWER_SUPPLY_CAPACITY=86
E: POWER_SUPPLY_CAPACITY_LEVEL=Normal
E: POWER_SUPPLY_CHARGE_FULL=1178000
E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000
E: POWER_SUPPLY_CHARGE_NOW=1037000
E: POWER_SUPPLY_CURRENT_NOW=-47000
E: POWER_SUPPLY_MANUFACTURER=Texas Instruments
E: POWER_SUPPLY_NAME=bq27425-0
E: POWER_SUPPLY_PRESENT=1
E: POWER_SUPPLY_STATUS=Discharging <========== OK ==========<
E: POWER_SUPPLY_TECHNOLOGY=Li-ion
E: POWER_SUPPLY_TEMP=304
E: POWER_SUPPLY_VOLTAGE_NOW=3979000
E: SUBSYSTEM=power_supply
P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0
E: POWER_SUPPLY_CAPACITY=82
E: POWER_SUPPLY_CAPACITY_LEVEL=Normal
E: POWER_SUPPLY_CHARGE_FULL=1178000
E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000
E: POWER_SUPPLY_CHARGE_NOW=996000
E: POWER_SUPPLY_CURRENT_NOW=-54000
E: POWER_SUPPLY_MANUFACTURER=Texas Instruments
E: POWER_SUPPLY_NAME=bq27425-0
E: POWER_SUPPLY_PRESENT=1
E: POWER_SUPPLY_STATUS=Charging <========== WRONG ==========<
E: POWER_SUPPLY_TECHNOLOGY=Li-ion
E: POWER_SUPPLY_TEMP=264
E: POWER_SUPPLY_VOLTAGE_NOW=3975000
E: SUBSYSTEM=power_supply
On Tue, Sep 27, 2016 at 11:45 PM, Liam notifications@github.com wrote:
My gauge claims to be charging when it's discharging. The first check, shortly after boot, is correct. Within an hour it was wrong. Hope this is a driver bug vs hw...
Scary but I don't think any kernel changes we have done could cause this.
We need to check how the POWER_SUPPLY_STATUS state is set.... call be naive but battery charging circuits (not the fuel gauge in this case) are rather well validated because of lawsuits from fires.
Fuel gauge reporting charging doesn't exactly mean it is esp if is using a metric like voltage change.. but late will check in the morning :)
[root@anvl ~]# udevadm info /sys/class/power_supply/bq27425-0 P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: POWER_SUPPLY_CAPACITY=86 E: POWER_SUPPLY_CAPACITY_LEVEL=Normal E: POWER_SUPPLY_CHARGE_FULL=1178000 E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000 E: POWER_SUPPLY_CHARGE_NOW=1037000 E: POWER_SUPPLY_CURRENT_NOW=-47000 E: POWER_SUPPLY_MANUFACTURER=Texas Instruments E: POWER_SUPPLY_NAME=bq27425-0 E: POWER_SUPPLY_PRESENT=1 E: POWER_SUPPLY_STATUS=Discharging <========== OK ==========< E: POWER_SUPPLY_TECHNOLOGY=Li-ion E: POWER_SUPPLY_TEMP=304 E: POWER_SUPPLY_VOLTAGE_NOW=3979000 E: SUBSYSTEM=power_supply
P: /devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: DEVPATH=/devices/platform/68000000.ocp/48072000.i2c/i2c-1/1-0055/power_supply/bq27425-0 E: POWER_SUPPLY_CAPACITY=82 E: POWER_SUPPLY_CAPACITY_LEVEL=Normal E: POWER_SUPPLY_CHARGE_FULL=1178000 E: POWER_SUPPLY_CHARGE_FULL_DESIGN=1340000 E: POWER_SUPPLY_CHARGE_NOW=996000 E: POWER_SUPPLY_CURRENT_NOW=-54000 E: POWER_SUPPLY_MANUFACTURER=Texas Instruments E: POWER_SUPPLY_NAME=bq27425-0 E: POWER_SUPPLY_PRESENT=1 E: POWER_SUPPLY_STATUS=Charging <========== WRONG ==========< E: POWER_SUPPLY_TECHNOLOGY=Li-ion E: POWER_SUPPLY_TEMP=264 E: POWER_SUPPLY_VOLTAGE_NOW=3975000 E: SUBSYSTEM=power_supply
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/networkimprov/arch-packages/issues/31#issuecomment-250085313, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwXOTRXpf9Llcn-whxDdUKlUFMQ4SUCks5qug0SgaJpZM4DSnCg .
Source: https://github.com/networkimprov/linux/blob/anvl-v4.7/drivers/power/bq27xxx_battery.c https://github.com/networkimprov/linux/blob/anvl-v4.7/drivers/power/bq27xxx_battery_i2c.c
1) verify driver with our gauge. Current_now is negative. Does it reflect measured current draw? Status is charging when really discharging.
2) what uevents (e.g. power_supply_changed()) does this emit, on what conditions? We probably want a sequence of events on low battery, e.g. 15, 10, 8, 6, 4, 2, 1% A udev rule will alert user, (alt-)suspend, or power off. Alt-suspend: https://github.com/networkimprov/arch-packages/issues/42
3) skip poll_interval_param_set if interval is unchanged.
let PMIC turn off itself from alt-suspend state? probably not.