Correction: the event action string is 'change' and not 'update' (not
sure where
I got that from..).
Also, despite my IDEs repeated insistence the kobj member type is not a
pointer. Here is my updated patch, I would still like some input on the
items in my original message before finalizing the patch.
---
drivers/acpi/battery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 3d5342f8d7b3..abe861946eb6 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -899,6 +899,7 @@ static int sysfs_add_battery(struct acpi_battery
*battery)
return result;
}
battery_hook_add_battery(battery);
+ kobject_uevent(&battery->bat->dev.kobj, KOBJ_CHANGE);
return 0;
}
--
On 12/27/24 8:35 PM, Nolan Woods wrote:
A 'add' uevent is emitted after adding respective /sys/class/
power_supply/BAT* devices via battery.c:sysfs_add_battery(...) ->
power_supply_core.c:power_supply_register(...) ->
core.c:device_add(...). Additional drivers (asus-wmi for example) can
register hooks that are called after the sysfs attributes are added by
power_supply_register. These hooks are normally used to add additional
attributes to sysfs. These additional attributes are not available at
the time that the 'add' uevent is emitted. udev rules are not able to
interact with them as the hooks are called after the 'add' uevent is
resolved. An additional 'update' uevent is needed to allow udev rules to
trigger once all hooks have been processed.
Signed-off-by: Nolan Woods <nolan@xxxxxxxxx>
---
drivers/acpi/battery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 3d5342f8d7b3..abe861946eb6 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -899,6 +899,7 @@ static int sysfs_add_battery(struct acpi_battery
*battery)
return result;
}
battery_hook_add_battery(battery);
+ kobject_uevent(battery->bat->dev->kobj, KOBJ_CHANGE);
return 0;
}
--
This is my first contribution to this repo. Please let me know if
there are any formatting issues of this submission.
I am looking for feedback on if kobject_uevent() should be called as
described in this patch or if it should be at the end of the
definition of battery_hook_add_battery.
Also, does it make sense that the "update" (KOBJ_CHANGE) event is sent
after the battery hooks make arbitrary changes? or is "update"
strictly for hardware/device initiated changes and I need to find a
different mechanism to trigger user space logic after the battery hooks?
An example udev rule that only works with this patch:
ACTION=="update", KERNEL=="BAT0", RUN+="/bin/chmod 666
/sys/class/power_supply/BAT0/charge_control_end_threshold"
The following does not work as
/sys/class/power_supply/BAT0/charge_control_end_threshold does not
exist when the event is resolved:
ACTION=="add", KERNEL=="BAT0", RUN+="/bin/chmod 666
/sys/class/power_supply/BAT0/charge_control_end_threshold"
charge_control_end_threshold is created at asus-wmi.c:1446.
Thank you for your time.
