On Wed, 2008-03-19 at 21:51 +0100, Rafael J. Wysocki wrote: > On Wednesday, 19 of March 2008, Venki Pallipadi wrote: > > On Sat, Mar 15, 2008 at 02:16:11PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > > @@ -421,7 +423,9 @@ > > > > else > > > > acpi_safe_halt(); > > > > > > > > - local_irq_enable(); > > > > + if (irqs_disabled()) > > > > + local_irq_enable(); > > > > + > > > > return; > > > > } > > > > > > > > @@ -530,7 +534,9 @@ > > > > * skew otherwise. > > > > */ > > > > sleep_ticks = 0xFFFFFFFF; > > > > - local_irq_enable(); > > > > + if (irqs_disabled()) > > > > + local_irq_enable(); > > > > + > > > > break; > > > > > > > > case ACPI_STATE_C2: > > > > > > That's pretty ugly. Could the code be modified to have interrupt > > > consistent at this point? > > > > > > > Agreed that this is not very clean. The problem is that we cannot be sure > > about the interrupt state at this point as the low level idle handlers at > > this point can come from variety of different places like safe_halt, arch > > dependent pm_idle code (which is different for (32 and 64 bit at this point) > > and also pm_idle can be somewhere outside the kernel in some module as it is > > a function pointer. > > Well, I'd add a comment that this is to make lockdep happy. Otherwise it looks > bizarre. I'd suggest to clean up the source of this mess instead; this is quite horrible. -- 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
