> There are other problems too. This design of pm_idle has been copied > by numerous other architectures. arm/blackfin/cris/ia64/m32r/m68knomm > /microblaze/mn10300/sh/sparc all have pm_idle. This will keep spreading > in future I guess. Presumably because they've decided it is a good model and works for them. That's a matter for their arch maintainers surely. > https://lkml.org/lkml/2010/10/19/449 . The problem is that it > results in two places of registration: cpuidle subsystem and > this. It was pointed that 99.99% of people run cpuidle and > we should directly call cpuidle and use its registration mechanism > rather than duplicate code. That makes sense. However what Len is trying to do doesn't seem to. The most likely case is nobody really needs APM idle now. In which case Len's first patches (adding the warnings) make sense, but instead of rushing headlong into everything else a simple years wait until the WARNs have been in Fedora and co for a few months would avoid any further work on it. In the mean time it produces a WARN, it can even be marked __deprecated to ensure nobody else uses it. The less likely case is that at some point within the year it turns out a few people do need and care about it, so it needs shuffling into cpuidle nicely. In computing terms this seems to be a lazy evaluation problem - why do all the extra work and risk bugs and problems trying to do things within one release when you can just let it chill for a year and maybe not do any work at all ? Don't let me stop anyone actually doing the work but it seems to be impatience before sanity ? Alan _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm