---

yaml --- r: 10914 b: refs/heads/master c: a4e2b34 h: refs/heads/master v: v3
git-mirror · Oct 28, 2005 · 887970f · 887970f
1 parent 7d9e5b7
commit 887970f
Show file tree

Hide file tree

Showing 888 changed files with 23,734 additions and 29,086 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 942b6f62164cf8822dd03b1569777f4663d1abd7
+refs/heads/master: a4e2b347848bf626b822599329933887dc90e50f
diff --git a/trunk/CREDITS b/trunk/CREDITS
@@ -2247,12 +2247,6 @@ S: 249 Nichols Avenue
 S: Syracuse, New York 13206
 S: USA
 
-N: Kyle McMartin
-E: kyle@parisc-linux.org
-D: Linux/PARISC hacker
-D: AD1889 sound driver
-S: Ottawa, Canada
-
 N: Dirk Melchers
 E: dirk@merlin.nbg.sub.org
 D: 8 bit XT hard disk driver for OMTI5520

diff --git a/trunk/Documentation/Changes b/trunk/Documentation/Changes
@@ -65,7 +65,7 @@ o  isdn4k-utils           3.1pre1                 # isdnctrl 2>&1|grep version
 o  nfs-utils              1.0.5                   # showmount --version
 o  procps                 3.2.0                   # ps --version
 o  oprofile               0.9                     # oprofiled --version
-o  udev                   071                     # udevinfo -V
+o  udev                   058                     # udevinfo -V
 
 Kernel compilation
 ==================

diff --git a/trunk/Documentation/DocBook/kernel-api.tmpl b/trunk/Documentation/DocBook/kernel-api.tmpl
@@ -286,9 +286,7 @@ X!Edrivers/pci/search.c
  -->
 !Edrivers/pci/msi.c
 !Edrivers/pci/bus.c
-<!-- FIXME: Removed for now since no structured comments in source
-X!Edrivers/pci/hotplug.c
--->
+!Edrivers/pci/hotplug.c
 !Edrivers/pci/probe.c
 !Edrivers/pci/rom.c
      </sect1>

diff --git a/trunk/Documentation/DocBook/usb.tmpl b/trunk/Documentation/DocBook/usb.tmpl
@@ -291,7 +291,7 @@
 
 !Edrivers/usb/core/hcd.c
 !Edrivers/usb/core/hcd-pci.c
-!Idrivers/usb/core/buffer.c
+!Edrivers/usb/core/buffer.c
     </chapter>
 
     <chapter>

diff --git a/trunk/Documentation/DocBook/writing_usb_driver.tmpl b/trunk/Documentation/DocBook/writing_usb_driver.tmpl
@@ -345,7 +345,8 @@ if (!retval) {
   <programlisting>
 static inline void skel_delete (struct usb_skel *dev)
 {
-    kfree (dev->bulk_in_buffer);
+    if (dev->bulk_in_buffer != NULL)
+        kfree (dev->bulk_in_buffer);
     if (dev->bulk_out_buffer != NULL)
         usb_buffer_free (dev->udev, dev->bulk_out_size,
             dev->bulk_out_buffer,

diff --git a/trunk/Documentation/driver-model/driver.txt b/trunk/Documentation/driver-model/driver.txt
@@ -14,8 +14,8 @@ struct device_driver {
         int     (*probe)        (struct device * dev);
         int     (*remove)       (struct device * dev);
 
-        int     (*suspend)      (struct device * dev, pm_message_t state);
-        int     (*resume)       (struct device * dev);
+        int     (*suspend)      (struct device * dev, pm_message_t state, u32 level);
+        int     (*resume)       (struct device * dev, u32 level);
 };
 
 
@@ -194,13 +194,69 @@ device; i.e. anything in the device's driver_data field.
 If the device is still present, it should quiesce the device and place
 it into a supported low-power state.
 
-	int	(*suspend)	(struct device * dev, pm_message_t state);
+	int	(*suspend)	(struct device * dev, pm_message_t state, u32 level);
 
-suspend is called to put the device in a low power state.
+suspend is called to put the device in a low power state. There are
+several stages to successfully suspending a device, which is denoted in
+the @level parameter. Breaking the suspend transition into several
+stages affords the platform flexibility in performing device power
+management based on the requirements of the system and the
+user-defined policy.
 
-	int	(*resume)	(struct device * dev);
+SUSPEND_NOTIFY notifies the device that a suspend transition is about
+to happen. This happens on system power state transitions to verify
+that all devices can successfully suspend.
 
-Resume is used to bring a device back from a low power state.
+A driver may choose to fail on this call, which should cause the
+entire suspend transition to fail. A driver should fail only if it
+knows that the device will not be able to be resumed properly when the
+system wakes up again. It could also fail if it somehow determines it
+is in the middle of an operation too important to stop.
+
+SUSPEND_DISABLE tells the device to stop I/O transactions. When it
+stops transactions, or what it should do with unfinished transactions
+is a policy of the driver. After this call, the driver should not
+accept any other I/O requests.
+
+SUSPEND_SAVE_STATE tells the device to save the context of the
+hardware. This includes any bus-specific hardware state and
+device-specific hardware state. A pointer to this saved state can be
+stored in the device's saved_state field.
+
+SUSPEND_POWER_DOWN tells the driver to place the device in the low
+power state requested. 
+
+Whether suspend is called with a given level is a policy of the
+platform. Some levels may be omitted; drivers must not assume the
+reception of any level. However, all levels must be called in the
+order above; i.e. notification will always come before disabling;
+disabling the device will come before suspending the device.
+
+All calls are made with interrupts enabled, except for the
+SUSPEND_POWER_DOWN level.
+
+	int	(*resume)	(struct device * dev, u32 level);
+
+Resume is used to bring a device back from a low power state. Like the
+suspend transition, it happens in several stages. 
+
+RESUME_POWER_ON tells the driver to set the power state to the state
+before the suspend call (The device could have already been in a low
+power state before the suspend call to put in a lower power state). 
+
+RESUME_RESTORE_STATE tells the driver to restore the state saved by
+the SUSPEND_SAVE_STATE suspend call. 
+
+RESUME_ENABLE tells the driver to start accepting I/O transactions
+again. Depending on driver policy, the device may already have pending
+I/O requests. 
+
+RESUME_POWER_ON is called with interrupts disabled. The other resume
+levels are called with interrupts enabled. 
+
+As with the various suspend stages, the driver must not assume that
+any other resume calls have been or will be made. Each call should be
+self-contained and not dependent on any external state.
 
 
 Attributes

diff --git a/trunk/Documentation/driver-model/porting.txt b/trunk/Documentation/driver-model/porting.txt
@@ -350,7 +350,7 @@ When a driver is registered, the bus's list of devices is iterated
 over. bus->match() is called for each device that is not already
 claimed by a driver. 
 
-When a device is successfully bound to a driver, device->driver is
+When a device is successfully bound to a device, device->driver is
 set, the device is added to a per-driver list of devices, and a
 symlink is created in the driver's sysfs directory that points to the
 device's physical directory:

diff --git a/trunk/Documentation/hwmon/it87 b/trunk/Documentation/hwmon/it87
@@ -4,18 +4,18 @@ Kernel driver it87
 Supported chips:
   * IT8705F
     Prefix: 'it87'
-    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)
     Datasheet: Publicly available at the ITE website
                http://www.ite.com.tw/
   * IT8712F
     Prefix: 'it8712'
     Addresses scanned: I2C 0x28 - 0x2f
-                       from Super I/O config space (8 I/O ports)
+                       from Super I/O config space, or default ISA 0x290 (8 I/O ports)
     Datasheet: Publicly available at the ITE website
                http://www.ite.com.tw/
   * SiS950   [clone of IT8705F]
-    Prefix: 'it87'
-    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Prefix: 'sis950'
+    Addresses scanned: from Super I/O config space, or default ISA 0x290 (8 I/O ports)
     Datasheet: No longer be available
 
 Author: Christophe Gauthron <chrisg@0-in.com>

diff --git a/trunk/Documentation/hwmon/lm90 b/trunk/Documentation/hwmon/lm90
@@ -24,14 +24,14 @@ Supported chips:
                http://www.national.com/pf/LM/LM86.html
   * Analog Devices ADM1032
     Prefix: 'adm1032'
-    Addresses scanned: I2C 0x4c and 0x4d
+    Addresses scanned: I2C 0x4c
     Datasheet: Publicly available at the Analog Devices website
-               http://www.analog.com/en/prod/0,2877,ADM1032,00.html
+               http://products.analog.com/products/info.asp?product=ADM1032
   * Analog Devices ADT7461
     Prefix: 'adt7461'
-    Addresses scanned: I2C 0x4c and 0x4d
+    Addresses scanned: I2C 0x4c
     Datasheet: Publicly available at the Analog Devices website
-               http://www.analog.com/en/prod/0,2877,ADT7461,00.html
+               http://products.analog.com/products/info.asp?product=ADT7461
     Note: Only if in ADM1032 compatibility mode
   * Maxim MAX6657
     Prefix: 'max6657'
@@ -71,8 +71,8 @@ increased resolution of the remote temperature measurement.
 
 The different chipsets of the family are not strictly identical, although
 very similar. This driver doesn't handle any specific feature for now,
-with the exception of SMBus PEC. For reference, here comes a non-exhaustive
-list of specific features:
+but could if there ever was a need for it. For reference, here comes a
+non-exhaustive list of specific features:
 
 LM90:
   * Filter and alert configuration register at 0xBF.
@@ -91,7 +91,6 @@ ADM1032:
   * Conversion averaging.
   * Up to 64 conversions/s.
   * ALERT is triggered by open remote sensor.
-  * SMBus PEC support for Write Byte and Receive Byte transactions.
 
 ADT7461
   * Extended temperature range (breaks compatibility)
@@ -120,37 +119,3 @@ The lm90 driver will not update its values more frequently than every
 other second; reading them more often will do no harm, but will return
 'old' values.
 
-PEC Support
------------
-
-The ADM1032 is the only chip of the family which supports PEC. It does
-not support PEC on all transactions though, so some care must be taken.
-
-When reading a register value, the PEC byte is computed and sent by the
-ADM1032 chip. However, in the case of a combined transaction (SMBus Read
-Byte), the ADM1032 computes the CRC value over only the second half of
-the message rather than its entirety, because it thinks the first half
-of the message belongs to a different transaction. As a result, the CRC
-value differs from what the SMBus master expects, and all reads fail.
-
-For this reason, the lm90 driver will enable PEC for the ADM1032 only if
-the bus supports the SMBus Send Byte and Receive Byte transaction types.
-These transactions will be used to read register values, instead of
-SMBus Read Byte, and PEC will work properly.
-
-Additionally, the ADM1032 doesn't support SMBus Send Byte with PEC.
-Instead, it will try to write the PEC value to the register (because the
-SMBus Send Byte transaction with PEC is similar to a Write Byte transaction
-without PEC), which is not what we want. Thus, PEC is explicitely disabled
-on SMBus Send Byte transactions in the lm90 driver.
-
-PEC on byte data transactions represents a significant increase in bandwidth
-usage (+33% for writes, +25% for reads) in normal conditions. With the need
-to use two SMBus transaction for reads, this overhead jumps to +50%. Worse,
-two transactions will typically mean twice as much delay waiting for
-transaction completion, effectively doubling the register cache refresh time.
-I guess reliability comes at a price, but it's quite expensive this time.
-
-So, as not everyone might enjoy the slowdown, PEC can be disabled through
-sysfs. Just write 0 to the "pec" file and PEC will be disabled. Write 1
-to that file to enable PEC again.
diff --git a/trunk/Documentation/hwmon/smsc47b397 b/trunk/Documentation/hwmon/smsc47b397
@@ -3,7 +3,6 @@ Kernel driver smsc47b397
 
 Supported chips:
   * SMSC LPC47B397-NC
-  * SMSC SCH5307-NS
     Prefix: 'smsc47b397'
     Addresses scanned: none, address read from Super I/O config space
     Datasheet: In this file
@@ -13,14 +12,11 @@ Authors: Mark M. Hoffman <mhoffman@lightlink.com>
 
 November 23, 2004
 
-The following specification describes the SMSC LPC47B397-NC[1] sensor chip
+The following specification describes the SMSC LPC47B397-NC sensor chip
 (for which there is no public datasheet available). This document was
 provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected
 by Mark M. Hoffman <mhoffman@lightlink.com>.
 
-[1] And SMSC SCH5307-NS, which has a different device ID but is otherwise
-compatible.
-
 * * * * *
 
 Methods for detecting the HP SIO and reading the thermal data on a dc7100.
@@ -131,7 +127,7 @@ OUT	DX,AL
 The registers of interest for identifying the SIO on the dc7100 are Device ID
 (0x20) and Device Rev  (0x21).
 
-The Device ID will read 0x6F (for SCH5307-NS, 0x81)
+The Device ID will read 0X6F
 The Device Rev currently reads 0x01
 
 Obtaining the HWM Base Address.

diff --git a/trunk/Documentation/hwmon/smsc47m1 b/trunk/Documentation/hwmon/smsc47m1
@@ -12,10 +12,6 @@ Supported chips:
         http://www.smsc.com/main/datasheets/47m14x.pdf
         http://www.smsc.com/main/tools/discontinued/47m15x.pdf
         http://www.smsc.com/main/datasheets/47m192.pdf
-  * SMSC LPC47M997
-    Addresses scanned: none, address read from Super I/O config space
-    Prefix: 'smsc47m1'
-    Datasheet: none
 
 Authors:
         Mark D. Studebaker <mdsxyz123@yahoo.com>,
@@ -34,9 +30,6 @@ The 47M15x and 47M192 chips contain a full 'hardware monitoring block'
 in addition to the fan monitoring and control. The hardware monitoring
 block is not supported by the driver.
 
-No documentation is available for the 47M997, but it has the same device
-ID as the 47M15x and 47M192 chips and seems to be compatible.
-
 Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
 triggered if the rotation speed has dropped below a programmable limit. Fan
 readings can be divided by a programmable divider (1, 2, 4 or 8) to give

diff --git a/trunk/Documentation/hwmon/sysfs-interface b/trunk/Documentation/hwmon/sysfs-interface
@@ -272,6 +272,3 @@ beep_mask	Bitmask for beep.
 
 eeprom		Raw EEPROM data in binary form.
 		Read only.
-
-pec		Enable or disable PEC (SMBus only)
-		Read/Write
diff --git a/trunk/Documentation/hwmon/via686a b/trunk/Documentation/hwmon/via686a
@@ -18,9 +18,8 @@ Authors:
 Module Parameters
 -----------------
 
-force_addr=0xaddr       Set the I/O base address. Useful for boards that
-                        don't set the address in the BIOS. Look for a BIOS
-                        upgrade before resorting to this. Does not do a
+force_addr=0xaddr       Set the I/O base address. Useful for Asus A7V boards
+                        that don't set the address in the BIOS. Does not do a
                         PCI force; the via686a must still be present in lspci.
                         Don't use this unless the driver complains that the
                         base address is not set.
@@ -64,15 +63,3 @@ miss once-only alarms.
 
 The driver only updates its values each 1.5 seconds; reading it more often
 will do no harm, but will return 'old' values.
-
-Known Issues
-------------
-
-This driver handles sensors integrated in some VIA south bridges. It is
-possible that a motherboard maker used a VT82C686A/B chip as part of a
-product design but was not interested in its hardware monitoring features,
-in which case the sensor inputs will not be wired. This is the case of
-the Asus K7V, A7V and A7V133 motherboards, to name only a few of them.
-So, if you need the force_addr parameter, and end up with values which
-don't seem to make any sense, don't look any further: your chip is simply
-not wired for hardware monitoring.
diff --git a/trunk/Documentation/i2c/busses/i2c-i810 b/trunk/Documentation/i2c/busses/i2c-i810
@@ -2,7 +2,6 @@ Kernel driver i2c-i810
 
 Supported adapters:
   * Intel 82810, 82810-DC100, 82810E, and 82815 (GMCH)
-  * Intel 82845G (GMCH)
 
 Authors: 
 	Frodo Looijaard <frodol@dds.nl>, 

diff --git a/trunk/Documentation/i2c/busses/i2c-viapro b/trunk/Documentation/i2c/busses/i2c-viapro
@@ -4,18 +4,17 @@ Supported adapters:
   * VIA Technologies, Inc. VT82C596A/B
     Datasheet: Sometimes available at the VIA website
 
-  * VIA Technologies, Inc. VT82C686A/B
+  * VIA Technologies, Inc. VT82C686A/B 
     Datasheet: Sometimes available at the VIA website
 
   * VIA Technologies, Inc. VT8231, VT8233, VT8233A, VT8235, VT8237
     Datasheet: available on request from Via
 
 Authors:
-	Frodo Looijaard <frodol@dds.nl>,
-	Philip Edelbrock <phil@netroedge.com>,
-	Ky�sti M�lkki <kmalkki@cc.hut.fi>,
-	Mark D. Studebaker <mdsxyz123@yahoo.com>,
-	Jean Delvare <khali@linux-fr.org>
+	Frodo Looijaard <frodol@dds.nl>,  
+	Philip Edelbrock <phil@netroedge.com>, 
+	Ky�sti M�lkki <kmalkki@cc.hut.fi>, 
+	Mark D. Studebaker <mdsxyz123@yahoo.com> 
 
 Module Parameters
 -----------------
@@ -29,22 +28,20 @@ Description
 -----------
 
 i2c-viapro is a true SMBus host driver for motherboards with one of the
-supported VIA south bridges.
+supported VIA southbridges.
 
 Your lspci -n listing must show one of these :
 
- device 1106:3050   (VT82C596A function 3)
- device 1106:3051   (VT82C596B function 3)
+ device 1106:3050   (VT82C596 function 3)
+ device 1106:3051   (VT82C596 function 3)
  device 1106:3057   (VT82C686 function 4)
  device 1106:3074   (VT8233)
  device 1106:3147   (VT8233A)
- device 1106:8235   (VT8231 function 4)
- device 1106:3177   (VT8235)
- device 1106:3227   (VT8237R)
+ device 1106:8235   (VT8231)
+ devide 1106:3177   (VT8235)
+ devide 1106:3227   (VT8237)
 
 If none of these show up, you should look in the BIOS for settings like
 enable ACPI / SMBus or even USB.
 
-Except for the oldest chips (VT82C596A/B, VT82C686A and most probably
-VT8231), this driver supports I2C block transactions. Such transactions
-are mainly useful to read from and write to EEPROMs.
+