Hello Bastien, Il giorno lun, 29/06/2020 alle 15.01 +0200, Bastien Nocera ha scritto: > On Mon, 2020-06-29 at 14:58 +0200, Giuseppe Sacco wrote: > > Il giorno lun, 29/06/2020 alle 13.06 +0200, Bastien Nocera ha > > scritto: > > > On Mon, 2020-06-29 at 12:00 +0100, Richard Hughes wrote: > > > > On Mon, 29 Jun 2020 at 02:54, Giuseppe Sacco > > > > <giuse...@eppesuigoccas.homedns.org> wrote: > > > > > Browsing UPower source code I noticed that PMU device is not > > > > > managed at > > > > > all, at least on the Linux branch. > > > > > > > > If it helps, HAL used to have code to read from PMU devices. I > > > > don't > > > > think it got ported all those years ago to DeviceKit-power, the > > > > old > > > > name for UPower. I don't think anyone has noticed until now. > > > > > > CONFIG_BATTERY_PMU in the kernel enables a power_supply class > > > driver > > > for the PMU. The power portion of CONFIG_ADB_PMU shouldn't be used. > > > > Well, yes, I understand it will be not be used that much since it is > > an > > old architecture. If I still try to write the necessary code, is > > there > > any way to exclude it when not compiling for powerpc? Do you already > > selectively compile parts of the code based on the architecture? > > There should be no changes necessary to UPower. Just make sure that a > "power_supply" class device is present in the kernel for the AC and the > battery. UPower should be able to handle those.
If I understood what you wrote, the pmu_battery driver registers the device as of class "power_supply" calling the function power_supply_register() as you may see at line 155 of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/power/pmu_battery.c?h=v3.16.85 Still, upower cannot find it: $ upower --enumerate /org/freedesktop/UPower/devices/DisplayDevice Bye, Giuseppe _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/devkit-devel
