"A 'General Purpose Input/Output' (GPIO) is a flexible software-controlled digital signal. They are provided from many kinds of chip, and are familiar to Linux developers working with embedded and custom hardware, begins Documentation/gpio.txt. In a recent four patch series, David Brownell noted, "when we hashed out the Documentation/gpio.txt GPIO programming interfaces last year, there were a few features in the 'we want this eventually, but can live without it for now' category. Following this post are patches adding some of those features." He went on to describe the two new features introduced in his patches:

"1) Implementation framework in lib/gpiolib.c ... the interface provided to GPIO _users_ is unchanged, but providers can now hook up through a 'gpio_chip' that lets multiple types of GPIO provider coexist. Examples: SOC-native GPIOs, ones provided by an FPGA, I2C or SPI GPIO expanders, etc."

"2) I2C driver for common pcf8574/8575 GPIO expanders ... these are pretty common on embedded hardware, and it's routine for external trees to have ugly board-specific hacks exposing those GPIOs to drivers. Unlike such hacks, I think support using standard GPIO calls should be mergable upstream."

"Since many alternative approaches to hibernation are now being considered and discussed," Rafael Wysocki began on the lkml, "I thought it might be a good idea to list some things that in my not so humble opinion should be taken care of by any hibernation framework. They are listed below, not in any particular order, because I think they all are important." He continued with the following list, including a paragraph discussing each: "filesystems mounted before the hibernation are untouchable; swap space in use before the hibernation must be handled with care; there are memory regions that must not be saved or restored; the user should be able to limit the size of a hibernation image; hibernation should be transparent from the applications' point of view; state of devices from before hibernation should be restored, if possible; on ACPI systems special platform-related actions have to be carried out at the right points, so that the platform works correctly after the restore; hibernation and restore should not be too slow; hibernation framework should not be too difficult to set up." Rafael went on to summarize:

"In my opinion any hibernation framework that doesn't take the above requirements into account in any way will be a failure. Moreover, the existing frameworks fail to follow some of them too, so I consider all of these frameworks as a work in progress. For this reason, I will much more appreciate ideas allowing us to improve the existing frameworks in a more or less evolutionary way, then attempts to replace them all with something entirely new."

Nadia Derbey posted a set of patches to the Linux Kernel Mailing List titled Automatic Kernel Tunables, or AKT, explaining, "this is a series of patches that introduces a feature that makes the kernel automatically change the tunables values as it sees resources running out." The kernel portion of the AKT framework is described as providing sysfs interfaces for registering tunables, and for activating the automatic tuning of registered tunables. Nadia explains the second feature, "it can be called during resource allocation to tune up, and during resource freeing to tune down the registered tunable." The userland portion of the framework provides an interface for configuring whether or not a tunable should be set automatically.

The default automatic adjustment routine provided by the patches simply allow a tunable to be configured with a minimum and maximum values, as well as a thresholds. If a monitored value grows beyond the defined threshold, the tunable is increased. If the monitored values shrinks below the defined threshold, the tunable is decreased. The patches also allow more complicated adjustment routines to be defined. The effort is part of the larger libtune project, aiming "at providing a standard API to unify the various ways Linux developers have to access kernel tunables, system information, resource consumptions."