Hi, Rafael Just an idea that. According to the ACPI spec, _WAK must be evaluated before resuming the devices. So it is supposed that the device drivers should be ready to handle notify() during the suspend/resume period, in the same ways as handling an IRQ during this period. If the driver is not able to do that (handling notify during suspend/resume cycle), should it be done by the driver in the way of explicitly "disabling notify", like what the disable_irq() does? Maybe do this via a new set of APs from the ACPI subsystem: acpi_disable_notify()/acpi_enable_notify(). Thanks and best regards -Lv > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Rafael J. Wysocki > Subject: Re: [PATCH v3 2/3] acpi: dptf_power: Add DPTF power participant > > 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 ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
