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. Thanks, Srinivas > Thanks, > Rafael -- 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
