On Mon, Jun 27, 2016 at 3:31 AM, Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote: > On Fri, 2016-06-24 at 02:26 +0200, Rafael J. Wysocki wrote: >> > > > >> On Fri, Jun 24, 2016 at 1:19 AM, Srinivas Pandruvada >> <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote: >> > 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: > [...] > >> I think what you need is that if acpi_battery is bound to at least >> one >> device, you don't want to bind dptf_power to anything. Conversely, >> if >> dptf_power has been bound to at least one device, you don't want to >> bind acpi_battery to anything. >> >> That may be achieved with a lock and two counters, one (A) >> incremented >> only by acpi_battery and the other (B) incremented only by dptf_power >> and such that you can't increment A if B is different from 0 and you >> can't increment B if A is different from 0. Of course, each driver >> would need to specify which counter it wants to use (A or B), so that >> would take an additional argument to acpi_battery_common_add() and an >> additional field in struct acpi_battery (for the remove operation). >> >> With that, I think it should only be possible to build both >> acpi_battery and dptf_power if they are both modules. IOW, >> DPTF_POWER >> should depend on (!ACPI_BATTERY || ACPI_BATTERY=m) or similar. And >> if >> they are both modules, let user space manage that. >> >> And the waiting itself doesn't add any value then IMO. > Yes. I think the best solution is not to let define DPTF_POWER when the > ACPI_BATTERY is defined same as my first version of the patch or let > both add as there is no harm as they will show same levels. The reason > is: > We have some devices with two ACPI_BATTERIES (primary and > secondary/backup) and they must be presented as two power supply > devices to user space. In those devices DPTF_POWER may be equivalent to > only one of the ACPI_BATTERY (Will point to same battery for Battery > levels). So we can't simply refuse to add ACPI_BATTERY device addition > because DPTF_POWER device is registered before. OK Say dptf_power points to the same battery device as acpi_battery. Is there any way to tell when that happens? -- 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