Patched in Tegra support.

3 files changed, 37 insertions, 54 deletions

diff --git a/Documentation/driver-model/binding.txt b/Documentation/driver-model/binding.txt
index abfc8e290d5..f7ec9d625bf 100644
--- a/Documentation/driver-model/binding.txt
+++ b/Documentation/driver-model/binding.txt
@@ -48,6 +48,10 @@ devclass_add_device is called to enumerate the device within the class
 and actually register it with the class, which happens with the
 class's register_dev callback.
 
+NOTE: The device class structures and core routines to manipulate them
+are not in the mainline kernel, so the discussion is still a bit
+speculative. 
+
 
 Driver
 ~~~~~~
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index 1e70220d20f..bdefe728a73 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -45,52 +45,33 @@ struct device_attribute {
                          const char *buf, size_t count);
 };
 
-Attributes of devices can be exported by a device driver through sysfs.
+Attributes of devices can be exported via drivers using a simple
+procfs-like interface. 
 
 Please see Documentation/filesystems/sysfs.txt for more information
 on how sysfs works.
 
-As explained in Documentation/kobject.txt, device attributes must be be
-created before the KOBJ_ADD uevent is generated. The only way to realize
-that is by defining an attribute group.
-
 Attributes are declared using a macro called DEVICE_ATTR:
 
 #define DEVICE_ATTR(name,mode,show,store)
 
 Example:
 
-static DEVICE_ATTR(type, 0444, show_type, NULL);
-static DEVICE_ATTR(power, 0644, show_power, store_power);
-
-This declares two structures of type struct device_attribute with respective
-names 'dev_attr_type' and 'dev_attr_power'. These two attributes can be
-organized as follows into a group:
+DEVICE_ATTR(power,0644,show_power,store_power);
 
-static struct attribute *dev_attrs[] = {
-        &dev_attr_type.attr,
-        &dev_attr_power.attr,
-        NULL,
-};
-
-static struct attribute_group dev_attr_group = {
-        .attrs = dev_attrs,
-};
+This declares a structure of type struct device_attribute named
+'dev_attr_power'. This can then be added and removed to the device's
+directory using:
 
-static const struct attribute_group *dev_attr_groups[] = {
-        &dev_attr_group,
-        NULL,
-};
+int device_create_file(struct device *device, struct device_attribute * entry);
+void device_remove_file(struct device * dev, struct device_attribute * attr);
 
-This array of groups can then be associated with a device by setting the
-group pointer in struct device before device_register() is invoked:
+Example:
 
-      dev->groups = dev_attr_groups;
-      device_register(dev);
+device_create_file(dev,&dev_attr_power);
+device_remove_file(dev,&dev_attr_power);
 
-The device_register() function will use the 'groups' pointer to create the
-device attributes and the device_unregister() function will use this pointer
-to remove the device attributes.
+The file name will be 'power' with a mode of 0644 (-rw-r--r--).
 
 Word of warning:  While the kernel allows device_create_file() and
 device_remove_file() to be called on a device at any time, userspace has
@@ -103,4 +84,24 @@ not know about the new attributes.
 This is important for device driver that need to publish additional
 attributes for a device at driver probe time.  If the device driver simply
 calls device_create_file() on the device structure passed to it, then
-userspace will never be notified of the new attributes.
+userspace will never be notified of the new attributes.  Instead, it should
+probably use class_create() and class->dev_attrs to set up a list of
+desired attributes in the modules_init function, and then in the .probe()
+hook, and then use device_create() to create a new device as a child
+of the probed device.  The new device will generate a new uevent and
+properly advertise the new attributes to userspace.
+
+For example, if a driver wanted to add the following attributes:
+struct device_attribute mydriver_attribs[] = {
+        __ATTR(port_count, 0444, port_count_show),
+        __ATTR(serial_number, 0444, serial_number_show),
+        NULL
+};
+
+Then in the module init function is would do:
+        mydriver_class = class_create(THIS_MODULE, "my_attrs");
+        mydriver_class.dev_attr = mydriver_attribs;
+
+And assuming 'dev' is the struct device passed into the probe hook, the driver
+probe function would do something like:
+        device_create(&mydriver_class, dev, chrdev, &private_data, "my_name");
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 43cff70465a..d79aead9418 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -233,10 +233,6 @@ certainly invest a bit more effort into libata core layer).
   6. List of managed interfaces
   -----------------------------
 
-MEM
-  devm_kzalloc()
-  devm_kfree()
-
 IO region
   devm_request_region()
   devm_request_mem_region()
@@ -266,25 +262,7 @@ IOMAP
   devm_ioremap()
   devm_ioremap_nocache()
   devm_iounmap()
-  devm_request_and_ioremap() : checks resource, requests region, ioremaps
   pcim_iomap()
   pcim_iounmap()
   pcim_iomap_table()    : array of mapped addresses indexed by BAR
   pcim_iomap_regions()  : do request_region() and iomap() on multiple BARs
-
-REGULATOR
-  devm_regulator_get()
-  devm_regulator_put()
-  devm_regulator_bulk_get()
-
-CLOCK
-  devm_clk_get()
-  devm_clk_put()
-
-PINCTRL
-  devm_pinctrl_get()
-  devm_pinctrl_put()
-
-PWM
-  devm_pwm_get()
-  devm_pwm_put()