On Friday, January 07, 2011, David Brownell wrote: > > --- On Thu, 1/6/11, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > > > > > > The wake_capable ACPI device flag is not necessary, because > > it is > > only used in scan.c for recording the information > > > Only for ACPI, yes? Generically, it records data for any > wake-capable dvice, and is not ACPI-specific... You're wrong, sorry. It _is_ ACPI-specific. > My bias is that ACPI should work the way other PM > solutions/hardware work, not collect special cases > unique to ACPI (kind of like this.) ... So this patch is going into the right direction, isn't it? > that _PRW > > is > > present for the given device. That information is > > only used by > > acpi_add_single_object() to decide whether or not to call > > acpi_bus_get_wakeup_device_flags(), so the flag may be > > dropped > > if the _PRW check is moved to > > acpi_bus_get_wakeup_device_flags(). > > Only if you presume ACPI .... What do you mean _exactly_? This flags is _not_ used anywhere outside of drivers/acpi/scan.c, so what's the problem? > I'm glad to see that generic-vs-ACPI duplication > of flags vanishing; way back when I started to add > wakeup support, I had to stop part way through ACPI > in large part because wake didn't work well yet in the Linux PM > framework, except for select non-ACPI HW. > (Starting with a USB subset: OTG and hub port sleep and ewakeup); oh, also GPIO wake on some HW, e.g. > or buttons, and switches like MMC/SD card detect. ISTR that stuff still wierds out a bit as it goes > through Linux-ACPI. > > Also, to the extent that the ACPI code was supposed > to be generic and not Linux-specific, I thought Len > or someone from Intel should drive such issues. Again, please be more specific. It appears you haven't been following the development in this area for years and now you're making comments I can't really understand. What's up, really? 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
