On Fri, 2016-06-24 at 00:31 +0200, Rafael J. Wysocki wrote: > On Thu, Jun 23, 2016 at 11:42 PM, Srinivas Pandruvada > <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote: > > > > This driver adds support for Dynamic Platform and Thermal Framework > > (DPTF) Platform Power Participant device support. > > This participant is responsible for exposing platform telemetry > > such as > > platform Power, battery Information such as state of Charge, > > estimated > > maximum sustainable power (PMax), SMART battery spec information. > > > > This driver is implemented as a platform driver for INT3407 and > > presented > > as power_supply device. Since this has common features with the > > ACPI > > battery, existing interface provide by battery_common driver are > > reused > > to present as a battery power supply device. > > > > When both CONFIG_ACPI_BATTERY and CONFIG_DPTF_POWER are defined and > > platform has support for INT3407, then dptf power registration is > > delayed for 100ms. In 100 ms, if there is no ACPI battery is > > registered > > then dptf power will be registered. Since both can be modules and > > battery driver loads in async thread, there can be race even if we > > specify loading order for initialization. > First, does the waiting actually help, though? Yes, if the acpi_battery registered then if (!battery_registered) will be false. > > Second, to my eyes, even if acpi_battery load first, the dptf_power > thing will still bind to the same device, but via the platform bus > instead of the ACPI bus type. I don't see anything preventing that > from happening in the patch, but maybe I missed something? > The INT3407 object also has battery _BST and _BIX, so driver will bind to this device not with PNP0C0A battery device. Either of them should be able to register and provide battery information. But the names are different (BAT vs TPWR on my platform) The check if (!battery_registered) will fail, so dptf_power will not register. So we will not see two batteries registered with power supply class (and hence no two batteries in desktop UI). Thanks, Srinivas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html