On Sat, Dec 28, 2024 at 1:55 PM Nolan Woods <nolan@xxxxxxxxx> wrote: > > 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. It would help if you sent the current version of the patch afresh, with a proper changelog. > --- > 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. >
