---

yaml --- r: 74315 b: refs/heads/master c: 1011b32 h: refs/heads/master i: 74313: 6c61d99 74311: 09e2224 v: v3
git-mirror · Nov 28, 2007 · 1de11f7 · 1de11f7
1 parent ff0b82c
commit 1de11f7
Show file tree

Hide file tree

Showing 34 changed files with 277 additions and 281 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 34f2c1c35ff014a5d145971e41caa940cd62d563
+refs/heads/master: 1011b326b1e7ab86a480c99b4718d16e6d9f1d11
diff --git a/trunk/Documentation/DocBook/Makefile b/trunk/Documentation/DocBook/Makefile
@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml \
 	    gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-	    genericirq.xml s390-drivers.xml uio-howto.xml
+	    genericirq.xml s390-drivers.xml
 
 ###
 # The build process is as follows (targets):

diff --git a/trunk/Documentation/DocBook/uio-howto.tmpl b/trunk/Documentation/DocBook/uio-howto.tmpl
@@ -29,12 +29,6 @@
 </abstract>
 
 <revhistory>
-	<revision>
-	<revnumber>0.4</revnumber>
-	<date>2007-11-26</date>
-	<authorinitials>hjk</authorinitials>
-	<revremark>Removed section about uio_dummy.</revremark>
-	</revision>
 	<revision>
 	<revnumber>0.3</revnumber>
 	<date>2007-04-29</date>
@@ -100,26 +94,6 @@ interested in translating it, please email me
 	user space. This simplifies development and reduces the risk of
 	serious bugs within a kernel module.
 	</para>
-	<para>
-	Please note that UIO is not an universal driver interface. Devices
-	that are already handled well by other kernel subsystems (like
-	networking or serial or USB) are no candidates for an UIO driver.
-	Hardware that is ideally suited for an UIO driver fulfills all of
-	the following:
-	</para>
-<itemizedlist>
-<listitem>
-	<para>The device has memory that can be mapped. The device can be
-	controlled completely by writing to this memory.</para>
-</listitem>
-<listitem>
-	<para>The device usually generates interrupts.</para>
-</listitem>
-<listitem>
-	<para>The device does not fit into one of the standard kernel
-	subsystems.</para>
-</listitem>
-</itemizedlist>
 </sect1>
 
 <sect1 id="thanks">
@@ -200,9 +174,8 @@ interested in translating it, please email me
 	For cards that don't generate interrupts but need to be
 	polled, there is the possibility to set up a timer that
 	triggers the interrupt handler at configurable time intervals.
-	This interrupt simulation is done by calling
-	<function>uio_event_notify()</function>
-	from the timer's event handler.
+	See <filename>drivers/uio/uio_dummy.c</filename> for an
+	example of this technique.
 	</para>
 
 	<para>
@@ -290,11 +263,63 @@ offset = N * getpagesize();
 </sect1>
 </chapter>
 
+<chapter id="using-uio_dummy" xreflabel="Using uio_dummy">
+<?dbhtml filename="using-uio_dummy.html"?>
+<title>Using uio_dummy</title>
+	<para>
+	Well, there is no real use for uio_dummy. Its only purpose is
+	to test most parts of the UIO system (everything except
+	hardware interrupts), and to serve as an example for the
+	kernel module that you will have to write yourself.
+	</para>
+
+<sect1 id="what_uio_dummy_does">
+<title>What uio_dummy does</title>
+	<para>
+	The kernel module <filename>uio_dummy.ko</filename> creates a
+	device that uses a timer to generate periodic interrupts. The
+	interrupt handler does nothing but increment a counter. The
+	driver adds two custom attributes, <varname>count</varname>
+	and <varname>freq</varname>, that appear under
+	<filename>/sys/devices/platform/uio_dummy/</filename>.
+	</para>
+
+	<para>
+	The attribute <varname>count</varname> can be read and
+	written.  The associated file
+	<filename>/sys/devices/platform/uio_dummy/count</filename>
+	appears as a normal text file and contains the total number of
+	timer interrupts. If you look at it (e.g. using
+	<function>cat</function>), you'll notice it is slowly counting
+	up.
+	</para>
+
+	<para>
+	The attribute <varname>freq</varname> can be read and written.
+	The content of
+	<filename>/sys/devices/platform/uio_dummy/freq</filename>
+	represents the number of system timer ticks between two timer
+	interrupts. The default value of <varname>freq</varname> is
+	the value of the kernel variable <varname>HZ</varname>, which
+	gives you an interval of one second. Lower values will
+	increase the frequency. Try the following:
+	</para>
+<programlisting format="linespecific">
+cd /sys/devices/platform/uio_dummy/
+echo 100 > freq
+</programlisting>
+	<para>
+	Use <function>cat count</function> to see how the interrupt
+	frequency changes.
+	</para>
+</sect1>
+</chapter>
+
 <chapter id="custom_kernel_module" xreflabel="Writing your own kernel module">
 <?dbhtml filename="custom_kernel_module.html"?>
 <title>Writing your own kernel module</title>
 	<para>
-	Please have a look at <filename>uio_cif.c</filename> as an
+	Please have a look at <filename>uio_dummy.c</filename> as an
 	example. The following paragraphs explain the different
 	sections of this file.
 	</para>
@@ -329,8 +354,9 @@ See the description below for details.
 interrupt, it's your modules task to determine the irq number during
 initialization. If you don't have a hardware generated interrupt but
 want to trigger the interrupt handler in some other way, set
-<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>.
-If you had no interrupt at all, you could set
+<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>. The
+uio_dummy module does this as it triggers the event mechanism in a timer
+routine. If you had no interrupt at all, you could set
 <varname>irq</varname> to <varname>UIO_IRQ_NONE</varname>, though this
 rarely makes sense.
 </para></listitem>

diff --git a/trunk/drivers/base/core.c b/trunk/drivers/base/core.c
@@ -770,10 +770,9 @@ int device_add(struct device *dev)
 	error = device_add_attrs(dev);
 	if (error)
 		goto AttrsError;
-	error = dpm_sysfs_add(dev);
+	error = device_pm_add(dev);
 	if (error)
 		goto PMError;
-	device_pm_add(dev);
 	error = bus_add_device(dev);
 	if (error)
 		goto BusError;
@@ -798,7 +797,6 @@ int device_add(struct device *dev)
 	return error;
  BusError:
 	device_pm_remove(dev);
-	dpm_sysfs_remove(dev);
  PMError:
 	if (dev->bus)
 		blocking_notifier_call_chain(&dev->bus->bus_notifier,

diff --git a/trunk/drivers/base/power/Makefile b/trunk/drivers/base/power/Makefile
@@ -1,6 +1,5 @@
 obj-y			:= shutdown.o
-obj-$(CONFIG_PM)	+= sysfs.o
-obj-$(CONFIG_PM_SLEEP)	+= main.o
+obj-$(CONFIG_PM_SLEEP)	+= main.o sysfs.o
 obj-$(CONFIG_PM_TRACE)	+= trace.o
 
 ifeq ($(CONFIG_DEBUG_DRIVER),y)

diff --git a/trunk/drivers/base/power/main.c b/trunk/drivers/base/power/main.c
@@ -38,14 +38,20 @@ static DEFINE_MUTEX(dpm_list_mtx);
 int (*platform_enable_wakeup)(struct device *dev, int is_on);
 
 
-void device_pm_add(struct device *dev)
+int device_pm_add(struct device *dev)
 {
+	int error;
+
 	pr_debug("PM: Adding info for %s:%s\n",
 		 dev->bus ? dev->bus->name : "No Bus",
 		 kobject_name(&dev->kobj));
 	mutex_lock(&dpm_list_mtx);
 	list_add_tail(&dev->power.entry, &dpm_active);
+	error = dpm_sysfs_add(dev);
+	if (error)
+		list_del(&dev->power.entry);
 	mutex_unlock(&dpm_list_mtx);
+	return error;
 }
 
 void device_pm_remove(struct device *dev)

diff --git a/trunk/drivers/base/power/power.h b/trunk/drivers/base/power/power.h
@@ -13,45 +13,31 @@ extern void device_shutdown(void);
 
 extern struct list_head dpm_active;	/* The active device list */
 
-static inline struct device *to_device(struct list_head *entry)
+static inline struct device * to_device(struct list_head * entry)
 {
 	return container_of(entry, struct device, power.entry);
 }
 
-extern void device_pm_add(struct device *);
+extern int device_pm_add(struct device *);
 extern void device_pm_remove(struct device *);
 
-#else /* CONFIG_PM_SLEEP */
-
-
-static inline void device_pm_add(struct device *dev)
-{
-}
-
-static inline void device_pm_remove(struct device *dev)
-{
-}
-
-#endif
-
-#ifdef CONFIG_PM
-
 /*
  * sysfs.c
  */
 
 extern int dpm_sysfs_add(struct device *);
 extern void dpm_sysfs_remove(struct device *);
 
-#else /* CONFIG_PM */
+#else /* CONFIG_PM_SLEEP */
+
 
-static inline int dpm_sysfs_add(struct device *dev)
+static inline int device_pm_add(struct device * dev)
 {
 	return 0;
 }
-
-static inline void dpm_sysfs_remove(struct device *dev)
+static inline void device_pm_remove(struct device * dev)
 {
+
 }
 
 #endif
diff --git a/trunk/drivers/char/Kconfig b/trunk/drivers/char/Kconfig
@@ -457,7 +457,7 @@ config LEGACY_PTYS
 config LEGACY_PTY_COUNT
 	int "Maximum number of legacy PTY in use"
 	depends on LEGACY_PTYS
-	range 0 256
+	range 1 256
 	default "256"
 	---help---
 	  The maximum number of legacy PTYs that can be used at any one time.

diff --git a/trunk/drivers/pci/hotplug/acpiphp.h b/trunk/drivers/pci/hotplug/acpiphp.h
@@ -66,7 +66,7 @@ struct slot {
 	char name[SLOT_NAME_SIZE];
 };
 
-/*
+/**
  * struct acpiphp_bridge - PCI bridge information
  *
  * for each bridge device in ACPI namespace
@@ -97,7 +97,7 @@ struct acpiphp_bridge {
 };
 
 
-/*
+/**
  * struct acpiphp_slot - PCI slot information
  *
  * PCI slot information for each *physical* PCI slot
@@ -118,7 +118,7 @@ struct acpiphp_slot {
 };
 
 
-/*
+/**
  * struct acpiphp_func - PCI function information
  *
  * PCI function information for each object in ACPI namespace
@@ -137,7 +137,7 @@ struct acpiphp_func {
 	u32		flags;		/* see below */
 };
 
-/*
+/**
  * struct acpiphp_attention_info - device specific attention registration
  *
  * ACPI has no generic method of setting/getting attention status

diff --git a/trunk/drivers/pci/hotplug/acpiphp_core.c b/trunk/drivers/pci/hotplug/acpiphp_core.c
@@ -91,10 +91,10 @@ static struct hotplug_slot_ops acpi_hotplug_slot_ops = {
  * acpiphp_register_attention - set attention LED callback
  * @info: must be completely filled with LED callbacks
  *
- * Description: This is used to register a hardware specific ACPI
+ * Description: this is used to register a hardware specific ACPI
  * driver that manipulates the attention LED.  All the fields in
  * info must be set.
- */
+ **/
 int acpiphp_register_attention(struct acpiphp_attention_info *info)
 {
 	int retval = -EINVAL;
@@ -112,10 +112,10 @@ int acpiphp_register_attention(struct acpiphp_attention_info *info)
  * acpiphp_unregister_attention - unset attention LED callback
  * @info: must match the pointer used to register
  *
- * Description: This is used to un-register a hardware specific acpi
+ * Description: this is used to un-register a hardware specific acpi
  * driver that manipulates the attention LED.  The pointer to the 
  * info struct must be the same as the one used to set it.
- */
+ **/
 int acpiphp_unregister_attention(struct acpiphp_attention_info *info)
 {
 	int retval = -EINVAL;
@@ -133,6 +133,7 @@ int acpiphp_unregister_attention(struct acpiphp_attention_info *info)
  * @hotplug_slot: slot to enable
  *
  * Actual tasks are done in acpiphp_enable_slot()
+ *
  */
 static int enable_slot(struct hotplug_slot *hotplug_slot)
 {
@@ -150,6 +151,7 @@ static int enable_slot(struct hotplug_slot *hotplug_slot)
  * @hotplug_slot: slot to disable
  *
  * Actual tasks are done in acpiphp_disable_slot()
+ *
  */
 static int disable_slot(struct hotplug_slot *hotplug_slot)
 {
@@ -166,15 +168,15 @@ static int disable_slot(struct hotplug_slot *hotplug_slot)
 }
 
 
-/**
- * set_attention_status - set attention LED
+ /**
+  * set_attention_status - set attention LED
  * @hotplug_slot: slot to set attention LED on
  * @status: value to set attention LED to (0 or 1)
  *
  * attention status LED, so we use a callback that
  * was registered with us.  This allows hardware specific
  * ACPI implementations to blink the light for us.
- */
+ **/
  static int set_attention_status(struct hotplug_slot *hotplug_slot, u8 status)
  {
 	int retval = -ENODEV;
@@ -197,6 +199,7 @@ static int disable_slot(struct hotplug_slot *hotplug_slot)
  *
  * Some platforms may not implement _STA method properly.
  * In that case, the value returned may not be reliable.
+ *
  */
 static int get_power_status(struct hotplug_slot *hotplug_slot, u8 *value)
 {
@@ -210,16 +213,16 @@ static int get_power_status(struct hotplug_slot *hotplug_slot, u8 *value)
 }
 
 
-/**
+ /**
  * get_attention_status - get attention LED status
  * @hotplug_slot: slot to get status from
  * @value: returns with value of attention LED
  *
  * ACPI doesn't have known method to determine the state
  * of the attention status LED, so we use a callback that
  * was registered with us.  This allows hardware specific
- * ACPI implementations to determine its state.
- */
+ * ACPI implementations to determine its state
+ **/
 static int get_attention_status(struct hotplug_slot *hotplug_slot, u8 *value)
 {
 	int retval = -EINVAL;
@@ -241,7 +244,8 @@ static int get_attention_status(struct hotplug_slot *hotplug_slot, u8 *value)
  * @value: pointer to store status
  *
  * ACPI doesn't provide any formal means to access latch status.
- * Instead, we fake latch status from _STA.
+ * Instead, we fake latch status from _STA
+ *
  */
 static int get_latch_status(struct hotplug_slot *hotplug_slot, u8 *value)
 {
@@ -261,7 +265,8 @@ static int get_latch_status(struct hotplug_slot *hotplug_slot, u8 *value)
  * @value: pointer to store status
  *
  * ACPI doesn't provide any formal means to access adapter status.
- * Instead, we fake adapter status from _STA.
+ * Instead, we fake adapter status from _STA
+ *
  */
 static int get_adapter_status(struct hotplug_slot *hotplug_slot, u8 *value)
 {