> > > > Beyond the lack of a upstream-visible feature-removal-schedule entry, we > > > > still have an Arcnet driver which hardware was obsoleted by Ethernet in the > > > > late 80s, and we still have i486 support and those are *much* older than > > > > APM. > > So how does your reasoning not apply to those drivers? There's several which > > are older than APM support. If we follow-through with the proposed cpuidle changes, then we'll have to cut APM code. The problem isn't cutting the code, it is testing it. I do have a couple of 15-year old laptops which include APM support. However, with ACPI disabled to enable APM, they don't even boot the upstream kernel today. > > We had this really big battle about x86/Voyager two years ago, which x86 > > subarchitecture literally had just a single user left, and the code was more > > intrusive than APM. Even there after much flaming the eventual consensus was > > that we'd accept it back if it was done cleanly, as part of the new-style > > x86_platform code. > > > > Given that APM fits into the current PM frameworks there's no such problem here > > that i can see. Somebody was pushing for Voyager support in the kernel and was energetic about maintaining it. cheers, -Len _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
