13 files changed, 1301 insertions, 19 deletions

diff --git a/Documentation/ABI/testing/sysfs-class-regulator b/Documentation/ABI/testing/sysfs-class-regulator
new file mode 100644
index 000000000000..79a4a75b2d2c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-regulator
@@ -0,0 +1,315 @@
+What:           /sys/class/regulator/.../state
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                state. This holds the regulator output state.
+
+                This will be one of the following strings:
+
+                'enabled'
+                'disabled'
+                'unknown'
+
+                'enabled' means the regulator output is ON and is supplying
+                power to the system.
+
+                'disabled' means the regulator output is OFF and is not
+                supplying power to the system..
+
+                'unknown' means software cannot determine the state.
+
+                NOTE: this field can be used in conjunction with microvolts
+                and microamps to determine regulator output levels.
+
+
+What:           /sys/class/regulator/.../type
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                type. This holds the regulator type.
+
+                This will be one of the following strings:
+
+                'voltage'
+                'current'
+                'unknown'
+
+                'voltage' means the regulator output voltage can be controlled
+                by software.
+
+                'current' means the regulator output current limit can be
+                controlled by software.
+
+                'unknown' means software cannot control either voltage or
+                current limit.
+
+
+What:           /sys/class/regulator/.../microvolts
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                microvolts. This holds the regulator output voltage setting
+                measured in microvolts (i.e. E-6 Volts).
+
+                NOTE: This value should not be used to determine the regulator
+                output voltage level as this value is the same regardless of
+                whether the regulator is enabled or disabled.
+
+
+What:           /sys/class/regulator/.../microamps
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                microamps. This holds the regulator output current limit
+                setting measured in microamps (i.e. E-6 Amps).
+
+                NOTE: This value should not be used to determine the regulator
+                output current level as this value is the same regardless of
+                whether the regulator is enabled or disabled.
+
+
+What:           /sys/class/regulator/.../opmode
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                opmode. This holds the regulator operating mode setting.
+
+                The opmode value can be one of the following strings:
+
+                'fast'
+                'normal'
+                'idle'
+                'standby'
+                'unknown'
+
+                The modes are described in include/linux/regulator/regulator.h
+
+                NOTE: This value should not be used to determine the regulator
+                output operating mode as this value is the same regardless of
+                whether the regulator is enabled or disabled.
+
+
+What:           /sys/class/regulator/.../min_microvolts
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                min_microvolts. This holds the minimum safe working regulator
+                output voltage setting for this domain measured in microvolts.
+
+                NOTE: this will return the string 'constraint not defined' if
+                the power domain has no min microvolts constraint defined by
+                platform code.
+
+
+What:           /sys/class/regulator/.../max_microvolts
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                max_microvolts. This holds the maximum safe working regulator
+                output voltage setting for this domain measured in microvolts.
+
+                NOTE: this will return the string 'constraint not defined' if
+                the power domain has no max microvolts constraint defined by
+                platform code.
+
+
+What:           /sys/class/regulator/.../min_microamps
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                min_microamps. This holds the minimum safe working regulator
+                output current limit setting for this domain measured in
+                microamps.
+
+                NOTE: this will return the string 'constraint not defined' if
+                the power domain has no min microamps constraint defined by
+                platform code.
+
+
+What:           /sys/class/regulator/.../max_microamps
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                max_microamps. This holds the maximum safe working regulator
+                output current limit setting for this domain measured in
+                microamps.
+
+                NOTE: this will return the string 'constraint not defined' if
+                the power domain has no max microamps constraint defined by
+                platform code.
+
+
+What:           /sys/class/regulator/.../num_users
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                num_users. This holds the number of consumer devices that
+                have called regulator_enable() on this regulator.
+
+
+What:           /sys/class/regulator/.../requested_microamps
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                requested_microamps. This holds the total requested load
+                current in microamps for this regulator from all its consumer
+                devices.
+
+
+What:           /sys/class/regulator/.../parent
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Some regulator directories will contain a link called parent.
+                This points to the parent or supply regulator if one exists.
+
+What:           /sys/class/regulator/.../suspend_mem_microvolts
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_mem_microvolts. This holds the regulator output
+                voltage setting for this domain measured in microvolts when
+                the system is suspended to memory.
+
+                NOTE: this will return the string 'not defined' if
+                the power domain has no suspend to memory voltage defined by
+                platform code.
+
+What:           /sys/class/regulator/.../suspend_disk_microvolts
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_disk_microvolts. This holds the regulator output
+                voltage setting for this domain measured in microvolts when
+                the system is suspended to disk.
+
+                NOTE: this will return the string 'not defined' if
+                the power domain has no suspend to disk voltage defined by
+                platform code.
+
+What:           /sys/class/regulator/.../suspend_standby_microvolts
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_standby_microvolts. This holds the regulator output
+                voltage setting for this domain measured in microvolts when
+                the system is suspended to standby.
+
+                NOTE: this will return the string 'not defined' if
+                the power domain has no suspend to standby voltage defined by
+                platform code.
+
+What:           /sys/class/regulator/.../suspend_mem_mode
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_mem_mode. This holds the regulator operating mode
+                setting for this domain when the system is suspended to
+                memory.
+
+                NOTE: this will return the string 'not defined' if
+                the power domain has no suspend to memory mode defined by
+                platform code.
+
+What:           /sys/class/regulator/.../suspend_disk_mode
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_disk_mode. This holds the regulator operating mode
+                setting for this domain when the system is suspended to disk.
+
+                NOTE: this will return the string 'not defined' if
+                the power domain has no suspend to disk mode defined by
+                platform code.
+
+What:           /sys/class/regulator/.../suspend_standby_mode
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_standby_mode. This holds the regulator operating mode
+                setting for this domain when the system is suspended to
+                standby.
+
+                NOTE: this will return the string 'not defined' if
+                the power domain has no suspend to standby mode defined by
+                platform code.
+
+What:           /sys/class/regulator/.../suspend_mem_state
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_mem_state. This holds the regulator operating state
+                when suspended to memory.
+
+                This will be one of the following strings:
+
+                'enabled'
+                'disabled'
+                'not defined'
+
+What:           /sys/class/regulator/.../suspend_disk_state
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_disk_state. This holds the regulator operating state
+                when suspended to disk.
+
+                This will be one of the following strings:
+
+                'enabled'
+                'disabled'
+                'not defined'
+
+What:           /sys/class/regulator/.../suspend_standby_state
+Date:           May 2008
+KernelVersion:  2.6.26
+Contact:        Liam Girdwood <lg@opensource.wolfsonmicro.com>
+Description:
+                Each regulator directory will contain a field called
+                suspend_standby_state. This holds the regulator operating
+                state when suspended to standby.
+
+                This will be one of the following strings:
+
+                'enabled'
+                'disabled'
+                'not defined'
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl
index e8acd1f03456..372dec20c8da 100644
--- a/Documentation/DocBook/kgdb.tmpl
+++ b/Documentation/DocBook/kgdb.tmpl
@@ -98,6 +98,24 @@
     "Kernel debugging" select "KGDB: kernel debugging with remote gdb".
     </para>
     <para>
+    It is advised, but not required that you turn on the
+    CONFIG_FRAME_POINTER kernel option.  This option inserts code to
+    into the compiled executable which saves the frame information in
+    registers or on the stack at different points which will allow a
+    debugger such as gdb to more accurately construct stack back traces
+    while debugging the kernel.
+    </para>
+    <para>
+    If the architecture that you are using supports the kernel option
+    CONFIG_DEBUG_RODATA, you should consider turning it off.  This
+    option will prevent the use of software breakpoints because it
+    marks certain regions of the kernel's memory space as read-only.
+    If kgdb supports it for the architecture you are using, you can
+    use hardware breakpoints if you desire to run with the
+    CONFIG_DEBUG_RODATA option turned on, else you need to turn off
+    this option.
+    </para>
+    <para>
     Next you should choose one of more I/O drivers to interconnect debugging
     host and debugged target.  Early boot debugging requires a KGDB
     I/O driver that supports early debugging and the driver must be
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt
index 44c97e6accb2..fabcb0e00f25 100644
--- a/Documentation/filesystems/configfs/configfs.txt
+++ b/Documentation/filesystems/configfs/configfs.txt
@@ -311,9 +311,20 @@ the subsystem must be ready for it.
 [An Example]
 
 The best example of these basic concepts is the simple_children
-subsystem/group and the simple_child item in configfs_example.c  It
-shows a trivial object displaying and storing an attribute, and a simple
-group creating and destroying these children.
+subsystem/group and the simple_child item in configfs_example_explicit.c
+and configfs_example_macros.c.  It shows a trivial object displaying and
+storing an attribute, and a simple group creating and destroying these
+children.
+
+The only difference between configfs_example_explicit.c and
+configfs_example_macros.c is how the attributes of the childless item
+are defined.  The childless item has extended attributes, each with
+their own show()/store() operation.  This follows a convention commonly
+used in sysfs.  configfs_example_explicit.c creates these attributes
+by explicitly defining the structures involved.  Conversely
+configfs_example_macros.c uses some convenience macros from configfs.h
+to define the attributes.  These macros are similar to their sysfs
+counterparts.
 
 [Hierarchy Navigation and the Subsystem Mutex]
 
diff --git a/Documentation/filesystems/configfs/configfs_example.c b/Documentation/filesystems/configfs/configfs_example_explicit.c
index 039648791701..d428cc9f07f3 100644
--- a/Documentation/filesystems/configfs/configfs_example.c
+++ b/Documentation/filesystems/configfs/configfs_example_explicit.c
@@ -1,8 +1,10 @@
 /*
  * vim: noexpandtab ts=8 sts=0 sw=8:
  *
- * configfs_example.c - This file is a demonstration module containing
- *      a number of configfs subsystems.
+ * configfs_example_explicit.c - This file is a demonstration module
+ *      containing a number of configfs subsystems.  It explicitly defines
+ *      each structure without using the helper macros defined in
+ *      configfs.h.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public
@@ -281,7 +283,6 @@ static struct config_item *simple_children_make_item(struct config_group *group,
         if (!simple_child)
                 return ERR_PTR(-ENOMEM);
 
-
         config_item_init_type_name(&simple_child->item, name,
                                    &simple_child_type);
 
@@ -302,8 +303,8 @@ static struct configfs_attribute *simple_children_attrs[] = {
 };
 
 static ssize_t simple_children_attr_show(struct config_item *item,
-                                         struct configfs_attribute *attr,
-                                         char *page)
+                                         struct configfs_attribute *attr,
+                                         char *page)
 {
         return sprintf(page,
 "[02-simple-children]\n"
@@ -318,7 +319,7 @@ static void simple_children_release(struct config_item *item)
 }
 
 static struct configfs_item_operations simple_children_item_ops = {
-        .release        = simple_children_release,
+        .release        = simple_children_release,
         .show_attribute = simple_children_attr_show,
 };
 
@@ -368,7 +369,6 @@ static struct config_group *group_children_make_group(struct config_group *group
         if (!simple_children)
                 return ERR_PTR(-ENOMEM);
 
-
         config_group_init_type_name(&simple_children->group, name,
                                     &simple_children_type);
 
@@ -387,8 +387,8 @@ static struct configfs_attribute *group_children_attrs[] = {
 };
 
 static ssize_t group_children_attr_show(struct config_item *item,
-                                        struct configfs_attribute *attr,
-                                        char *page)
+                                        struct configfs_attribute *attr,
+                                        char *page)
 {
         return sprintf(page,
 "[03-group-children]\n"
diff --git a/Documentation/filesystems/configfs/configfs_example_macros.c b/Documentation/filesystems/configfs/configfs_example_macros.c
new file mode 100644
index 000000000000..d8e30a0378aa
--- /dev/null
+++ b/Documentation/filesystems/configfs/configfs_example_macros.c
@@ -0,0 +1,448 @@
+/*
+ * vim: noexpandtab ts=8 sts=0 sw=8:
+ *
+ * configfs_example_macros.c - This file is a demonstration module
+ *      containing a number of configfs subsystems.  It uses the helper
+ *      macros defined by configfs.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ *
+ * Based on sysfs:
+ *      sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
+ *
+ * configfs Copyright (C) 2005 Oracle.  All rights reserved.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <linux/configfs.h>
+
+
+
+/*
+ * 01-childless
+ *
+ * This first example is a childless subsystem.  It cannot create
+ * any config_items.  It just has attributes.
+ *
+ * Note that we are enclosing the configfs_subsystem inside a container.
+ * This is not necessary if a subsystem has no attributes directly
+ * on the subsystem.  See the next example, 02-simple-children, for
+ * such a subsystem.
+ */
+
+struct childless {
+        struct configfs_subsystem subsys;
+        int showme;
+        int storeme;
+};
+
+static inline struct childless *to_childless(struct config_item *item)
+{
+        return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL;
+}
+
+CONFIGFS_ATTR_STRUCT(childless);
+#define CHILDLESS_ATTR(_name, _mode, _show, _store)     \
+struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR(_name, _mode, _show, _store)
+#define CHILDLESS_ATTR_RO(_name, _show) \
+struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR_RO(_name, _show);
+
+static ssize_t childless_showme_read(struct childless *childless,
+                                     char *page)
+{
+        ssize_t pos;
+
+        pos = sprintf(page, "%d\n", childless->showme);
+        childless->showme++;
+
+        return pos;
+}
+
+static ssize_t childless_storeme_read(struct childless *childless,
+                                      char *page)
+{
+        return sprintf(page, "%d\n", childless->storeme);
+}
+
+static ssize_t childless_storeme_write(struct childless *childless,
+                                       const char *page,
+                                       size_t count)
+{
+        unsigned long tmp;
+        char *p = (char *) page;
+
+        tmp = simple_strtoul(p, &p, 10);
+        if (!p || (*p && (*p != '\n')))
+                return -EINVAL;
+
+        if (tmp > INT_MAX)
+                return -ERANGE;
+
+        childless->storeme = tmp;
+
+        return count;
+}
+
+static ssize_t childless_description_read(struct childless *childless,
+                                          char *page)
+{
+        return sprintf(page,
+"[01-childless]\n"
+"\n"
+"The childless subsystem is the simplest possible subsystem in\n"
+"configfs.  It does not support the creation of child config_items.\n"
+"It only has a few attributes.  In fact, it isn't much different\n"
+"than a directory in /proc.\n");
+}
+
+CHILDLESS_ATTR_RO(showme, childless_showme_read);
+CHILDLESS_ATTR(storeme, S_IRUGO | S_IWUSR, childless_storeme_read,
+               childless_storeme_write);
+CHILDLESS_ATTR_RO(description, childless_description_read);
+
+static struct configfs_attribute *childless_attrs[] = {
+        &childless_attr_showme.attr,
+        &childless_attr_storeme.attr,
+        &childless_attr_description.attr,
+        NULL,
+};
+
+CONFIGFS_ATTR_OPS(childless);
+static struct configfs_item_operations childless_item_ops = {
+        .show_attribute         = childless_attr_show,
+        .store_attribute        = childless_attr_store,
+};
+
+static struct config_item_type childless_type = {
+        .ct_item_ops    = &childless_item_ops,
+        .ct_attrs       = childless_attrs,
+        .ct_owner       = THIS_MODULE,
+};
+
+static struct childless childless_subsys = {
+        .subsys = {
+                .su_group = {
+                        .cg_item = {
+                                .ci_namebuf = "01-childless",
+                                .ci_type = &childless_type,
+                        },
+                },
+        },
+};
+
+
+/* ----------------------------------------------------------------- */
+
+/*
+ * 02-simple-children
+ *
+ * This example merely has a simple one-attribute child.  Note that
+ * there is no extra attribute structure, as the child's attribute is
+ * known from the get-go.  Also, there is no container for the
+ * subsystem, as it has no attributes of its own.
+ */
+
+struct simple_child {
+        struct config_item item;
+        int storeme;
+};
+
+static inline struct simple_child *to_simple_child(struct config_item *item)
+{
+        return item ? container_of(item, struct simple_child, item) : NULL;
+}
+
+static struct configfs_attribute simple_child_attr_storeme = {
+        .ca_owner = THIS_MODULE,
+        .ca_name = "storeme",
+        .ca_mode = S_IRUGO | S_IWUSR,
+};
+
+static struct configfs_attribute *simple_child_attrs[] = {
+        &simple_child_attr_storeme,
+        NULL,
+};
+
+static ssize_t simple_child_attr_show(struct config_item *item,
+                                      struct configfs_attribute *attr,
+                                      char *page)
+{
+        ssize_t count;
+        struct simple_child *simple_child = to_simple_child(item);
+
+        count = sprintf(page, "%d\n", simple_child->storeme);
+
+        return count;
+}
+
+static ssize_t simple_child_attr_store(struct config_item *item,
+                                       struct configfs_attribute *attr,
+                                       const char *page, size_t count)
+{
+        struct simple_child *simple_child = to_simple_child(item);
+        unsigned long tmp;
+        char *p = (char *) page;
+
+        tmp = simple_strtoul(p, &p, 10);
+        if (!p || (*p && (*p != '\n')))
+                return -EINVAL;
+
+        if (tmp > INT_MAX)
+                return -ERANGE;
+
+        simple_child->storeme = tmp;
+
+        return count;
+}
+
+static void simple_child_release(struct config_item *item)
+{
+        kfree(to_simple_child(item));
+}
+
+static struct configfs_item_operations simple_child_item_ops = {
+        .release                = simple_child_release,
+        .show_attribute         = simple_child_attr_show,
+        .store_attribute        = simple_child_attr_store,
+};
+
+static struct config_item_type simple_child_type = {
+        .ct_item_ops    = &simple_child_item_ops,
+        .ct_attrs       = simple_child_attrs,
+        .ct_owner       = THIS_MODULE,
+};
+
+
+struct simple_children {
+        struct config_group group;
+};
+
+static inline struct simple_children *to_simple_children(struct config_item *item)
+{
+        return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;
+}
+
+static struct config_item *simple_children_make_item(struct config_group *group, const char *name)
+{
+        struct simple_child *simple_child;
+
+        simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);
+        if (!simple_child)
+                return ERR_PTR(-ENOMEM);
+
+        config_item_init_type_name(&simple_child->item, name,
+                                   &simple_child_type);
+
+        simple_child->storeme = 0;
+
+        return &simple_child->item;
+}
+
+static struct configfs_attribute simple_children_attr_description = {
+        .ca_owner = THIS_MODULE,
+        .ca_name = "description",
+        .ca_mode = S_IRUGO,
+};
+
+static struct configfs_attribute *simple_children_attrs[] = {
+        &simple_children_attr_description,
+        NULL,
+};
+
+static ssize_t simple_children_attr_show(struct config_item *item,
+                                         struct configfs_attribute *attr,
+                                         char *page)
+{
+        return sprintf(page,
+"[02-simple-children]\n"
+"\n"
+"This subsystem allows the creation of child config_items.  These\n"
+"items have only one attribute that is readable and writeable.\n");
+}
+
+static void simple_children_release(struct config_item *item)
+{
+        kfree(to_simple_children(item));
+}
+
+static struct configfs_item_operations simple_children_item_ops = {
+        .release        = simple_children_release,
+        .show_attribute = simple_children_attr_show,
+};
+
+/*
+ * Note that, since no extra work is required on ->drop_item(),
+ * no ->drop_item() is provided.
+ */
+static struct configfs_group_operations simple_children_group_ops = {
+        .make_item      = simple_children_make_item,
+};
+
+static struct config_item_type simple_children_type = {
+        .ct_item_ops    = &simple_children_item_ops,
+        .ct_group_ops   = &simple_children_group_ops,
+        .ct_attrs       = simple_children_attrs,
+        .ct_owner       = THIS_MODULE,
+};
+
+static struct configfs_subsystem simple_children_subsys = {
+        .su_group = {
+                .cg_item = {
+                        .ci_namebuf = "02-simple-children",
+                        .ci_type = &simple_children_type,
+                },
+        },
+};
+
+
+/* ----------------------------------------------------------------- */
+
+/*
+ * 03-group-children
+ *
+ * This example reuses the simple_children group from above.  However,
+ * the simple_children group is not the subsystem itself, it is a
+ * child of the subsystem.  Creation of a group in the subsystem creates
+ * a new simple_children group.  That group can then have simple_child
+ * children of its own.
+ */
+
+static struct config_group *group_children_make_group(struct config_group *group, const char *name)
+{
+        struct simple_children *simple_children;
+
+        simple_children = kzalloc(sizeof(struct simple_children),
+                                  GFP_KERNEL);
+        if (!simple_children)
+                return ERR_PTR(-ENOMEM);
+
+        config_group_init_type_name(&simple_children->group, name,
+                                    &simple_children_type);
+
+        return &simple_children->group;
+}
+
+static struct configfs_attribute group_children_attr_description = {
+        .ca_owner = THIS_MODULE,
+        .ca_name = "description",
+        .ca_mode = S_IRUGO,
+};
+
+static struct configfs_attribute *group_children_attrs[] = {
+        &group_children_attr_description,
+        NULL,
+};
+
+static ssize_t group_children_attr_show(struct config_item *item,
+                                        struct configfs_attribute *attr,
+                                        char *page)
+{
+        return sprintf(page,
+"[03-group-children]\n"
+"\n"
+"This subsystem allows the creation of child config_groups.  These\n"
+"groups are like the subsystem simple-children.\n");
+}
+
+static struct configfs_item_operations group_children_item_ops = {
+        .show_attribute = group_children_attr_show,
+};
+
+/*
+ * Note that, since no extra work is required on ->drop_item(),
+ * no ->drop_item() is provided.
+ */
+static struct configfs_group_operations group_children_group_ops = {
+        .make_group     = group_children_make_group,
+};
+
+static struct config_item_type group_children_type = {
+        .ct_item_ops    = &group_children_item_ops,
+        .ct_group_ops   = &group_children_group_ops,
+        .ct_attrs       = group_children_attrs,
+        .ct_owner       = THIS_MODULE,
+};
+
+static struct configfs_subsystem group_children_subsys = {
+        .su_group = {
+                .cg_item = {
+                        .ci_namebuf = "03-group-children",
+                        .ci_type = &group_children_type,
+                },
+        },
+};
+
+/* ----------------------------------------------------------------- */
+
+/*
+ * We're now done with our subsystem definitions.
+ * For convenience in this module, here's a list of them all.  It
+ * allows the init function to easily register them.  Most modules
+ * will only have one subsystem, and will only call register_subsystem
+ * on it directly.
+ */
+static struct configfs_subsystem *example_subsys[] = {
+        &childless_subsys.subsys,
+        &simple_children_subsys,
+        &group_children_subsys,
+        NULL,
+};
+
+static int __init configfs_example_init(void)
+{
+        int ret;
+        int i;
+        struct configfs_subsystem *subsys;
+
+        for (i = 0; example_subsys[i]; i++) {
+                subsys = example_subsys[i];
+
+                config_group_init(&subsys->su_group);
+                mutex_init(&subsys->su_mutex);
+                ret = configfs_register_subsystem(subsys);
+                if (ret) {
+                        printk(KERN_ERR "Error %d while registering subsystem %s\n",
+                               ret,
+                               subsys->su_group.cg_item.ci_namebuf);
+                        goto out_unregister;
+                }
+        }
+
+        return 0;
+
+out_unregister:
+        for (; i >= 0; i--) {
+                configfs_unregister_subsystem(example_subsys[i]);
+        }
+
+        return ret;
+}
+
+static void __exit configfs_example_exit(void)
+{
+        int i;
+
+        for (i = 0; example_subsys[i]; i++) {
+                configfs_unregister_subsystem(example_subsys[i]);
+        }
+}
+
+module_init(configfs_example_init);
+module_exit(configfs_example_exit);
+MODULE_LICENSE("GPL");
diff --git a/Documentation/ftrace.txt b/Documentation/ftrace.txt
index f218f616ff6b..d330fe3103da 100644
--- a/Documentation/ftrace.txt
+++ b/Documentation/ftrace.txt
@@ -4,6 +4,7 @@
 Copyright 2008 Red Hat Inc.
    Author:   Steven Rostedt <srostedt@redhat.com>
   License:   The GNU Free Documentation License, Version 1.2
+               (dual licensed under the GPL v2)
 Reviewers:   Elias Oltmanns, Randy Dunlap, Andrew Morton,
              John Kacur, and David Teigland.
 
diff --git a/Documentation/hwmon/dme1737 b/Documentation/hwmon/dme1737
index 8f446070e64a..b1fe00999439 100644
--- a/Documentation/hwmon/dme1737
+++ b/Documentation/hwmon/dme1737
@@ -22,6 +22,10 @@ Module Parameters
                         and PWM output control functions. Using this parameter
                         shouldn't be required since the BIOS usually takes care
                         of this.
+* probe_all_addr: bool  Include non-standard LPC addresses 0x162e and 0x164e
+                        when probing for ISA devices. This is required for the
+                        following boards:
+                        - VIA EPIA SN18000
 
 Note that there is no need to use this parameter if the driver loads without
 complaining. The driver will say so if it is necessary.
diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85
index 9549237530cf..6d41db7f17f8 100644
--- a/Documentation/hwmon/lm85
+++ b/Documentation/hwmon/lm85
@@ -96,11 +96,6 @@ initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
 confirmed this "bug". The ADT7463 is reported to work as described in the
 documentation. The current lm85 driver does not show the offset register.
 
-The ADT7463 has a THERM asserted counter. This counter has a 22.76ms
-resolution and a range of 5.8 seconds. The driver implements a 32-bit
-accumulator of the counter value to extend the range to over a year. The
-counter will stay at it's max value until read.
-
 See the vendor datasheets for more information. There is application note
 from National (AN-1260) with some additional information about the LM85.
 The Analog Devices datasheet is very detailed and describes a procedure for
@@ -206,13 +201,15 @@ Configuration choices:
 
 The National LM85's have two vendor specific configuration
 features. Tach. mode and Spinup Control. For more details on these,
-see the LM85 datasheet or Application Note AN-1260.
+see the LM85 datasheet or Application Note AN-1260. These features
+are not currently supported by the lm85 driver.
 
 The Analog Devices ADM1027 has several vendor specific enhancements.
 The number of pulses-per-rev of the fans can be set, Tach monitoring
 can be optimized for PWM operation, and an offset can be applied to
 the temperatures to compensate for systemic errors in the
-measurements.
+measurements. These features are not currently supported by the lm85
+driver.
 
 In addition to the ADM1027 features, the ADT7463 also has Tmin control
 and THERM asserted counts. Automatic Tmin control acts to adjust the
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt
index a8686e5a6857..c6cd4956047c 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -101,6 +101,10 @@ of charge when battery became full/empty". It also could mean "value of
 charge when battery considered full/empty at given conditions (temperature,
 age)". I.e. these attributes represents real thresholds, not design values.
 
+CHARGE_COUNTER - the current charge counter (in µAh).  This could easily
+be negative; there is no empty or full value.  It is only useful for
+relative, time-based measurements.
+
 ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
 
 CAPACITY - capacity in percents.
diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt
new file mode 100644
index 000000000000..82b7a43aadba
--- /dev/null
+++ b/Documentation/power/regulator/consumer.txt
@@ -0,0 +1,182 @@
+Regulator Consumer Driver Interface
+===================================
+
+This text describes the regulator interface for consumer device drivers.
+Please see overview.txt for a description of the terms used in this text.
+
+
+1. Consumer Regulator Access (static & dynamic drivers)
+=======================================================
+
+A consumer driver can get access to it's supply regulator by calling :-
+
+regulator = regulator_get(dev, "Vcc");
+
+The consumer passes in it's struct device pointer and power supply ID. The core
+then finds the correct regulator by consulting a machine specific lookup table.
+If the lookup is successful then this call will return a pointer to the struct
+regulator that supplies this consumer.
+
+To release the regulator the consumer driver should call :-
+
+regulator_put(regulator);
+
+Consumers can be supplied by more than one regulator e.g. codec consumer with
+analog and digital supplies :-
+
+digital = regulator_get(dev, "Vcc");  /* digital core */
+analog = regulator_get(dev, "Avdd");  /* analog */
+
+The regulator access functions regulator_get() and regulator_put() will
+usually be called in your device drivers probe() and remove() respectively.
+
+
+2. Regulator Output Enable & Disable (static & dynamic drivers)
+====================================================================
+
+A consumer can enable it's power supply by calling:-
+
+int regulator_enable(regulator);
+
+NOTE: The supply may already be enabled before regulator_enabled() is called.
+This may happen if the consumer shares the regulator or the regulator has been
+previously enabled by bootloader or kernel board initialization code.
+
+A consumer can determine if a regulator is enabled by calling :-
+
+int regulator_is_enabled(regulator);
+
+This will return > zero when the regulator is enabled.
+
+
+A consumer can disable it's supply when no longer needed by calling :-
+
+int regulator_disable(regulator);
+
+NOTE: This may not disable the supply if it's shared with other consumers. The
+regulator will only be disabled when the enabled reference count is zero.
+
+Finally, a regulator can be forcefully disabled in the case of an emergency :-
+
+int regulator_force_disable(regulator);
+
+NOTE: this will immediately and forcefully shutdown the regulator output. All
+consumers will be powered off.
+
+
+3. Regulator Voltage Control & Status (dynamic drivers)
+======================================================
+
+Some consumer drivers need to be able to dynamically change their supply
+voltage to match system operating points. e.g. CPUfreq drivers can scale
+voltage along with frequency to save power, SD drivers may need to select the
+correct card voltage, etc.
+
+Consumers can control their supply voltage by calling :-
+
+int regulator_set_voltage(regulator, min_uV, max_uV);
+
+Where min_uV and max_uV are the minimum and maximum acceptable voltages in
+microvolts.
+
+NOTE: this can be called when the regulator is enabled or disabled. If called
+when enabled, then the voltage changes instantly, otherwise the voltage
+configuration changes and the voltage is physically set when the regulator is
+next enabled.
+
+The regulators configured voltage output can be found by calling :-
+
+int regulator_get_voltage(regulator);
+
+NOTE: get_voltage() will return the configured output voltage whether the
+regulator is enabled or disabled and should NOT be used to determine regulator
+output state. However this can be used in conjunction with is_enabled() to
+determine the regulator physical output voltage.
+
+
+4. Regulator Current Limit Control & Status (dynamic drivers)
+===========================================================
+
+Some consumer drivers need to be able to dynamically change their supply
+current limit to match system operating points. e.g. LCD backlight driver can
+change the current limit to vary the backlight brightness, USB drivers may want
+to set the limit to 500mA when supplying power.
+
+Consumers can control their supply current limit by calling :-
+
+int regulator_set_current_limit(regulator, min_uV, max_uV);
+
+Where min_uA and max_uA are the minimum and maximum acceptable current limit in
+microamps.
+
+NOTE: this can be called when the regulator is enabled or disabled. If called
+when enabled, then the current limit changes instantly, otherwise the current
+limit configuration changes and the current limit is physically set when the
+regulator is next enabled.
+
+A regulators current limit can be found by calling :-
+
+int regulator_get_current_limit(regulator);
+
+NOTE: get_current_limit() will return the current limit whether the regulator
+is enabled or disabled and should not be used to determine regulator current
+load.
+
+
+5. Regulator Operating Mode Control & Status (dynamic drivers)
+=============================================================
+
+Some consumers can further save system power by changing the operating mode of
+their supply regulator to be more efficient when the consumers operating state
+changes. e.g. consumer driver is idle and subsequently draws less current
+
+Regulator operating mode can be changed indirectly or directly.
+
+Indirect operating mode control.
+--------------------------------
+Consumer drivers can request a change in their supply regulator operating mode
+by calling :-
+
+int regulator_set_optimum_mode(struct regulator *regulator, int load_uA);
+
+This will cause the core to recalculate the total load on the regulator (based
+on all it's consumers) and change operating mode (if necessary and permitted)
+to best match the current operating load.
+
+The load_uA value can be determined from the consumers datasheet. e.g.most
+datasheets have tables showing the max current consumed in certain situations.
+
+Most consumers will use indirect operating mode control since they have no
+knowledge of the regulator or whether the regulator is shared with other
+consumers.
+
+Direct operating mode control.
+------------------------------
+Bespoke or tightly coupled drivers may want to directly control regulator
+operating mode depending on their operating point. This can be achieved by
+calling :-
+
+int regulator_set_mode(struct regulator *regulator, unsigned int mode);
+unsigned int regulator_get_mode(struct regulator *regulator);
+
+Direct mode will only be used by consumers that *know* about the regulator and
+are not sharing the regulator with other consumers.
+
+
+6. Regulator Events
+===================
+Regulators can notify consumers of external events. Events could be received by
+consumers under regulator stress or failure conditions.
+
+Consumers can register interest in regulator events by calling :-
+
+int regulator_register_notifier(struct regulator *regulator,
+                              struct notifier_block *nb);
+
+Consumers can uregister interest by calling :-
+
+int regulator_unregister_notifier(struct regulator *regulator,
+                                struct notifier_block *nb);
+
+Regulators use the kernel notifier framework to send event to thier interested
+consumers.
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt
new file mode 100644
index 000000000000..c9a35665cf70
--- /dev/null
+++ b/Documentation/power/regulator/machine.txt
@@ -0,0 +1,101 @@
+Regulator Machine Driver Interface
+===================================
+
+The regulator machine driver interface is intended for board/machine specific
+initialisation code to configure the regulator subsystem. Typical things that
+machine drivers would do are :-
+
+ 1. Regulator -> Device mapping.
+ 2. Regulator supply configuration.
+ 3. Power Domain constraint setting.
+
+
+
+1. Regulator -> device mapping
+==============================
+Consider the following machine :-
+
+  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
+               |
+               +-> [Consumer B @ 3.3V]
+
+The drivers for consumers A & B must be mapped to the correct regulator in
+order to control their power supply. This mapping can be achieved in machine
+initialisation code by calling :-
+
+int regulator_set_device_supply(const char *regulator, struct device *dev,
+                                const char *supply);
+
+and is shown with the following code :-
+
+regulator_set_device_supply("Regulator-1", devB, "Vcc");
+regulator_set_device_supply("Regulator-2", devA, "Vcc");
+
+This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
+to the 'Vcc' supply for Consumer A.
+
+
+2. Regulator supply configuration.
+==================================
+Consider the following machine (again) :-
+
+  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
+               |
+               +-> [Consumer B @ 3.3V]
+
+Regulator-1 supplies power to Regulator-2. This relationship must be registered
+with the core so that Regulator-1 is also enabled when Consumer A enables it's
+supply (Regulator-2).
+
+This relationship can be register with the core via :-
+
+int regulator_set_supply(const char *regulator, const char *regulator_supply);
+
+In this example we would use the following code :-
+
+regulator_set_supply("Regulator-2", "Regulator-1");
+
+Relationships can be queried by calling :-
+
+const char *regulator_get_supply(const char *regulator);
+
+
+3. Power Domain constraint setting.
+===================================
+Each power domain within a system has physical constraints on voltage and
+current. This must be defined in software so that the power domain is always
+operated within specifications.
+
+Consider the following machine (again) :-
+
+  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
+               |
+               +-> [Consumer B @ 3.3V]
+
+This gives us two regulators and two power domains:
+
+                   Domain 1: Regulator-2, Consumer B.
+                   Domain 2: Consumer A.
+
+Constraints can be registered by calling :-
+
+int regulator_set_platform_constraints(const char *regulator,
+        struct regulation_constraints *constraints);
+
+The example is defined as follows :-
+
+struct regulation_constraints domain_1 = {
+        .min_uV = 3300000,
+        .max_uV = 3300000,
+        .valid_modes_mask = REGULATOR_MODE_NORMAL,
+};
+
+struct regulation_constraints domain_2 = {
+        .min_uV = 1800000,
+        .max_uV = 2000000,
+        .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+        .valid_modes_mask = REGULATOR_MODE_NORMAL,
+};
+
+regulator_set_platform_constraints("Regulator-1", &domain_1);
+regulator_set_platform_constraints("Regulator-2", &domain_2);
diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt
new file mode 100644
index 000000000000..bdcb332bd7fb
--- /dev/null
+++ b/Documentation/power/regulator/overview.txt
@@ -0,0 +1,171 @@
+Linux voltage and current regulator framework
+=============================================
+
+About
+=====
+
+This framework is designed to provide a standard kernel interface to control
+voltage and current regulators.
+
+The intention is to allow systems to dynamically control regulator power output
+in order to save power and prolong battery life. This applies to both voltage
+regulators (where voltage output is controllable) and current sinks (where
+current limit is controllable).
+
+(C) 2008  Wolfson Microelectronics PLC.
+Author: Liam Girdwood <lg@opensource.wolfsonmicro.com>
+
+
+Nomenclature
+============
+
+Some terms used in this document:-
+
+  o Regulator    - Electronic device that supplies power to other devices.
+                   Most regulators can enable and disable their output whilst
+                   some can control their output voltage and or current.
+
+                   Input Voltage -> Regulator -> Output Voltage
+
+
+  o PMIC         - Power Management IC. An IC that contains numerous regulators
+                   and often contains other susbsystems.
+
+
+  o Consumer     - Electronic device that is supplied power by a regulator.
+                   Consumers can be classified into two types:-
+
+                   Static: consumer does not change it's supply voltage or
+                   current limit. It only needs to enable or disable it's
+                   power supply. It's supply voltage is set by the hardware,
+                   bootloader, firmware or kernel board initialisation code.
+
+                   Dynamic: consumer needs to change it's supply voltage or
+                   current limit to meet operation demands.
+
+
+  o Power Domain - Electronic circuit that is supplied it's input power by the
+                   output power of a regulator, switch or by another power
+                   domain.
+
+                   The supply regulator may be behind a switch(s). i.e.
+
+                   Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
+                              |             |
+                              |             +-> [Consumer B], [Consumer C]
+                              |
+                              +-> [Consumer D], [Consumer E]
+
+                   That is one regulator and three power domains:
+
+                   Domain 1: Switch-1, Consumers D & E.
+                   Domain 2: Switch-2, Consumers B & C.
+                   Domain 3: Consumer A.
+
+                   and this represents a "supplies" relationship:
+
+                   Domain-1 --> Domain-2 --> Domain-3.
+
+                   A power domain may have regulators that are supplied power
+                   by other regulators. i.e.
+
+                   Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
+                                |
+                                +-> [Consumer B]
+
+                   This gives us two regulators and two power domains:
+
+                   Domain 1: Regulator-2, Consumer B.
+                   Domain 2: Consumer A.
+
+                   and a "supplies" relationship:
+
+                   Domain-1 --> Domain-2
+
+
+  o Constraints  - Constraints are used to define power levels for performance
+                   and hardware protection. Constraints exist at three levels:
+
+                   Regulator Level: This is defined by the regulator hardware
+                   operating parameters and is specified in the regulator
+                   datasheet. i.e.
+
+                     - voltage output is in the range 800mV -> 3500mV.
+                     - regulator current output limit is 20mA @ 5V but is
+                       10mA @ 10V.
+
+                   Power Domain Level: This is defined in software by kernel
+                   level board initialisation code. It is used to constrain a
+                   power domain to a particular power range. i.e.
+
+                     - Domain-1 voltage is 3300mV
+                     - Domain-2 voltage is 1400mV -> 1600mV
+                     - Domain-3 current limit is 0mA -> 20mA.
+
+                   Consumer Level: This is defined by consumer drivers
+                   dynamically setting voltage or current limit levels.
+
+                   e.g. a consumer backlight driver asks for a current increase
+                   from 5mA to 10mA to increase LCD illumination. This passes
+                   to through the levels as follows :-
+
+                   Consumer: need to increase LCD brightness. Lookup and
+                   request next current mA value in brightness table (the
+                   consumer driver could be used on several different
+                   personalities based upon the same reference device).
+
+                   Power Domain: is the new current limit within the domain
+                   operating limits for this domain and system state (e.g.
+                   battery power, USB power)
+
+                   Regulator Domains: is the new current limit within the
+                   regulator operating parameters for input/ouput voltage.
+
+                   If the regulator request passes all the constraint tests
+                   then the new regulator value is applied.
+
+
+Design
+======
+
+The framework is designed and targeted at SoC based devices but may also be
+relevant to non SoC devices and is split into the following four interfaces:-
+
+
+   1. Consumer driver interface.
+
+      This uses a similar API to the kernel clock interface in that consumer
+      drivers can get and put a regulator (like they can with clocks atm) and
+      get/set voltage, current limit, mode, enable and disable. This should
+      allow consumers complete control over their supply voltage and current
+      limit. This also compiles out if not in use so drivers can be reused in
+      systems with no regulator based power control.
+
+        See Documentation/power/regulator/consumer.txt
+
+   2. Regulator driver interface.
+
+      This allows regulator drivers to register their regulators and provide
+      operations to the core. It also has a notifier call chain for propagating
+      regulator events to clients.
+
+        See Documentation/power/regulator/regulator.txt
+
+   3. Machine interface.
+
+      This interface is for machine specific code and allows the creation of
+      voltage/current domains (with constraints) for each regulator. It can
+      provide regulator constraints that will prevent device damage through
+      overvoltage or over current caused by buggy client drivers. It also
+      allows the creation of a regulator tree whereby some regulators are
+      supplied by others (similar to a clock tree).
+
+        See Documentation/power/regulator/machine.txt
+
+   4. Userspace ABI.
+
+      The framework also exports a lot of useful voltage/current/opmode data to
+      userspace via sysfs. This could be used to help monitor device power
+      consumption and status.
+
+        See Documentation/ABI/testing/regulator-sysfs.txt
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt
new file mode 100644
index 000000000000..a69050143592
--- /dev/null
+++ b/Documentation/power/regulator/regulator.txt
@@ -0,0 +1,30 @@
+Regulator Driver Interface
+==========================
+
+The regulator driver interface is relatively simple and designed to allow
+regulator drivers to register their services with the core framework.
+
+
+Registration
+============
+
+Drivers can register a regulator by calling :-
+
+struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
+                                          void *reg_data);
+
+This will register the regulators capabilities and operations the regulator
+core. The core does not touch reg_data (private to regulator driver).
+
+Regulators can be unregistered by calling :-
+
+void regulator_unregister(struct regulator_dev *rdev);
+
+
+Regulator Events
+================
+Regulators can send events (e.g. over temp, under voltage, etc) to consumer
+drivers by calling :-
+
+int regulator_notifier_call_chain(struct regulator_dev *rdev,
+                                  unsigned long event, void *data);