Hi, > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time > > On Tuesday, August 15, 2017 11:59:00 AM CEST Zheng, Lv wrote: > > Hi, > > > > > From: Rafael J. Wysocki [mailto:rjw@xxxxxxxxxxxxx] > > > Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time > > > > > > On Friday, August 11, 2017 7:40:56 AM CEST Zheng, Lv wrote: > > > > Hi, Rafael > > > > > > > > > From: Rafael J. Wysocki [mailto:rjw@xxxxxxxxxxxxx] > > > > > Subject: Re: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time > > > > > > > > > > On Thursday, August 10, 2017 3:48:58 AM CEST Zheng, Lv wrote: > > > > > > Hi, Rafael > > > > > > > > > > > > > From: Rafael J. Wysocki [mailto:rjw@xxxxxxxxxxxxx] > > > > > > > Subject: [PATCH 1/3] ACPICA: Dispatch active GPEs at init time > > > > > > > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > > > > > > > > > > In some cases GPEs are already active when they are enabled by > > > > > > > acpi_ev_initialize_gpe_block() and whatever happens next may depend > > > > > > > on the result of handling the events signaled by them, so the > > > > > > > events should not be discarded (which is what happens currently) and > > > > > > > they should be handled as soon as reasonably possible. > > > > > > > > > > > > > > For this reason, modify acpi_ev_initialize_gpe_block() to > > > > > > > dispatch GPEs with the status flag set in-band right after > > > > > > > enabling them. > > > > > > > > > > > > In fact, what we need seems to be invoking acpi_ev_gpe_dispatch() > > > > > > right after enabling an GPE. So there are 2 conditions related: > > > > > > 1. GPE is enabled for the first time. > > > > > > 2. GPE is initialized. > > > > > > > > > > > > And we need to make sure that before acpi_update_all_gpes() is invoked, > > > > > > all GPE EN bits are actually disabled. > > > > > > > > > > But we don't do it today, do we? > > > > > > > > We don't do that. > > > > > > > > > > > > > > And still calling _dispatch() should not be incorrect even if the GPE > > > > > has been enabled already at this point. Worst case it just will > > > > > queue up the execution of _Lxx/_Exx which may or may not do anything > > > > > useful. > > > > > > > > > > And BTW this is all done under acpi_gbl_gpe_lock so acpi_ev_gpe_detect() > > > > > will block on it if run concurrently and we've checked the status, so > > > > > we know that the GPE *should* be dispatched, so I sort of fail to see > > > > > the problem. > > > > > > > > There is another problem related: > > > > ACPICA clears GPEs before enabling it. > > > > This is proven to be wrong, and we have to fix it: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=196249 > > > > > > > > without fixing this issue, in this solution, we surely need to save the > > > > GPE STS bit before incrementing GPE reference count, and poll it according > > > > to the saved STS bit. Because if we poll it after enabling, STS bit will > > > > be wrongly cleared. > > > > > > I'm not sure if I understand you correctly, but why would we poll it? > > > > > > In the $subject patch the status is checked and then > > > acpi_ev_add_gpe_reference() is called to add a reference to the GPE. > > > > > > If this is the first reference (which will be the case in the majority > > > of cases), acpi_ev_enable_gpe() will be called and that will clear the > > > status. > > > > > > Then, acpi_ev_gpe_dispatch() is called if the status was set and that > > > itself doesn't check the status. It disables the GPE upfront (so the > > > status doesn't matter from now on until the GPE is enabled again) and > > > clears the status unconditionally if the GPE is edge-triggered. This > > > means that for edge-triggered GPEs the clearing of the status by > > > acpi_ev_enable_gpe() doesn't matter here. > > > > No problem, I understood. > > And was thinking thought this patch [edge GPE dispatch fix] should be > > correct and good for current Linux upstream. > > > > What I meant is: > > PATCH [edge GPE clear fix] https://patchwork.kernel.org/patch/9894983/ > > is a fix we need for upstream as it is the only possible fix for the > > issue fixed by it. > > On top of that, when acpi_ev_enable_gpe() is called, GPE won't be cleared. > > and then things can be done in a simpler way: > > PATCH [edge GPE enable fix] https://patchwork.kernel.org/patch/9894989/ > > > > As [edge GPE clear fix] is risky, I think [edge GPE dispatch fix] is OK > > for Linux upstream. > > > > So we can have 2 processes: > > 1. Merge [edge GPE dispatch fix] and let [edge GPE clear fix] and > > [edge GPE enable fix] released from ACPICA upstream so that: > > 1. We can enhance them in ACPICA upstream. > > 2. It will be regression safer for us to merge [edge GPE clear fix]. > > 2. Merge [edge GPE clear fix] and [edge GPE enable fix] without > > merging [edge GPE dispatch fix]. > > > > What I meant is: > > It's up to you to decide which process we should take. :) > > OK > > So I would go with what is already there in my tree. Please work on top of > that. OK. Then I'll do that from ACPICA upstream to have more eyes on the enhancements and more time to create the stable baseline for the [edge GPE clear fix]. Best regards, Lv -- 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
