5 files changed, 31 insertions, 203 deletions

diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt
index a8686e5a685..c6cd4956047 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/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 3be84aa38df..29d839ce732 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt
         - MPC5200 Device Tree Bindings
 ppc_htab.txt
         - info about the Linux/PPC /proc/ppc_htab entry
-SBC8260_memory_mapping.txt
-        - EST SBC8260 board info
 smp.txt
         - use and state info about Linux/PPC on MP machines
 sound.txt
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt
deleted file mode 100644
index e6e9ee0506c..00000000000
--- a/Documentation/powerpc/SBC8260_memory_mapping.txt
+++ /dev/null
@@ -1,197 +0,0 @@
-Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
-if you have questions, comments or corrections.
-
-        * EST SBC8260 Linux memory mapping rules
-
-        http://www.estc.com/ 
-        http://www.estc.com/products/boards/SBC8260-8240_ds.html
-
-        Initial conditions:
-        -------------------
-        
-        Tasks that need to be perform by the boot ROM before control is
-        transferred to zImage (compressed Linux kernel):
-
-        - Define the IMMR to 0xf0000000
-
-        - Initialize the memory controller so that RAM is available at
-          physical address 0x00000000.  On the SBC8260 is this 16M (64M)
-          SDRAM.
-
-        - The boot ROM should only clear the RAM that it is using.
-
-          The reason for doing this is to enhances the chances of a
-          successful post mortem on a Linux panic.  One of the first
-          items to examine is the 16k (LOG_BUF_LEN) circular console
-          buffer called log_buf which is defined in kernel/printk.c.
-
-        - To enhance boot ROM performance, the I-cache can be enabled.
-
-          Date: Mon, 22 May 2000 14:21:10 -0700
-          From: Neil Russell <caret@c-side.com>
-
-          LiMon (LInux MONitor) runs with and starts Linux with MMU
-          off, I-cache enabled, D-cache disabled.  The I-cache doesn't
-          need hints from the MMU to work correctly as the D-cache
-          does.  No D-cache means no special code to handle devices in
-          the presence of cache (no snooping, etc). The use of the
-          I-cache means that the monitor can run acceptably fast
-          directly from ROM, rather than having to copy it to RAM.
-
-        - Build the board information structure (see 
-          include/asm-ppc/est8260.h for its definition)
-
-        - The compressed Linux kernel (zImage) contains a bootstrap loader 
-          that is position independent; you can load it into any RAM, 
-          ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
-          at its link address of 0x00400000 (4 MB).
-
-          Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
-                then zImage will skip the step of moving itself to 
-                its link address.
-
-        - Load R3 with the address of the board information structure
-
-        - Transfer control to zImage
-
-        - The Linux console port is SMC1, and the baud rate is controlled
-          from the bi_baudrate field of the board information structure.
-          On thing to keep in mind when picking the baud rate, is that
-          there is no flow control on the SMC ports.  I would stick
-          with something safe and standard like 19200.
-
-          On the EST SBC8260, the SMC1 port is on the COM1 connector of
-          the board.
-
-        
-        EST SBC8260 defaults:
-        ---------------------
-
-                                Chip
-        Memory                  Sel  Bus   Use
-        ---------------------   ---  ---   ----------------------------------
-        0x00000000-0x03FFFFFF   CS2  60x   (16M or 64M)/64M SDRAM
-        0x04000000-0x04FFFFFF   CS4  local  4M/16M SDRAM (soldered to the board)
-        0x21000000-0x21000000   CS7  60x    1B/64K Flash present detect (from the flash SIMM)
-        0x21000001-0x21000001   CS7  60x    1B/64K Switches (read) and LEDs (write)
-        0x22000000-0x2200FFFF   CS5  60x    8K/64K EEPROM
-        0xFC000000-0xFCFFFFFF   CS6  60x    2M/16M flash (8 bits wide, soldered to the board)
-        0xFE000000-0xFFFFFFFF   CS0  60x    4M/16M flash (SIMM)
-
-        Notes:
-        ------
-
-        - The chip selects can map 32K blocks and up (powers of 2)
-
-        - The SDRAM machine can handled up to 128Mbytes per chip select
-
-        - Linux uses the 60x bus memory (the SDRAM DIMM) for the 
-          communications buffers.
-
-        - BATs can map 128K-256Mbytes each.  There are four data BATs and
-          four instruction BATs.  Generally the data and instruction BATs
-          are mapped the same.
-
-        - The IMMR must be set above the kernel virtual memory addresses,
-          which start at 0xC0000000.  Otherwise, the kernel may crash as
-          soon as you start any threads or processes due to VM collisions 
-          in the kernel or user process space.
-
-
-          Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
-
-          The user application virtual space consumes the first 2 Gbytes
-          (0x00000000 to 0x7FFFFFFF).  The kernel virtual text starts at
-          0xC0000000, with data following.  There is a "protection hole"
-          between the end of kernel data and the start of the kernel
-          dynamically allocated space, but this space is still within
-          0xCxxxxxxx.
-
-          Obviously the kernel can't map any physical addresses 1:1 in
-          these ranges.
-
-
-          Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
-
-          During the early kernel initialization, the kernel virtual
-          memory allocator is not operational.  Prior to this KVM
-          initialization, we choose to map virtual to physical addresses
-          1:1.  That is, the kernel virtual address exactly matches the
-          physical address on the bus.  These mappings are typically done
-          in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only
-          absolutely necessary mappings should be done at this time, for
-          example board control registers or a serial uart.  Normal device
-          driver initialization should map resources later when necessary.
-
-          Although platform dependent, and certainly the case for embedded
-          8xx, traditionally memory is mapped at physical address zero,
-          and I/O devices above physical address 0x80000000.  The lowest
-          and highest (above 0xf0000000) I/O addresses are traditionally 
-          used for devices or registers we need to map during kernel 
-          initialization and prior to KVM operation.  For this reason, 
-          and since it followed prior PowerPC platform examples, I chose 
-          to map the embedded 8xx kernel to the 0xc0000000 virtual address.
-          This way, we can enable the MMU to map the kernel for proper 
-          operation, and still map a few windows before the KVM is operational.
-
-          On some systems, you could possibly run the kernel at the 
-          0x80000000 or any other virtual address.  It just depends upon 
-          mapping that must be done prior to KVM operational.  You can never 
-          map devices or kernel spaces that overlap with the user virtual 
-          space.  This is why default IMMR mapping used by most BDM tools 
-          won't work.  They put the IMMR at something like 0x10000000 or 
-          0x02000000 for example.  You simply can't map these addresses early
-          in the kernel, and continue proper system operation.
-
-          The embedded 8xx/82xx kernel is mature enough that all you should 
-          need to do is map the IMMR someplace at or above 0xf0000000 and it 
-          should boot far enough to get serial console messages and KGDB 
-          connected on any platform.  There are lots of other subtle memory 
-          management design features that you simply don't need to worry 
-          about.  If you are changing functions related to MMU initialization,
-          you are likely breaking things that are known to work and are 
-          heading down a path of disaster and frustration.  Your changes 
-          should be to make the flexibility of the processor fit Linux, 
-          not force arbitrary and non-workable memory mappings into Linux.
-
-        - You don't want to change KERNELLOAD or KERNELBASE, otherwise the
-          virtual memory and MMU code will get confused.
-        
-          arch/ppc/Makefile:KERNELLOAD = 0xc0000000
-
-          include/asm-ppc/page.h:#define PAGE_OFFSET    0xc0000000
-          include/asm-ppc/page.h:#define KERNELBASE     PAGE_OFFSET
-
-        - RAM is at physical address 0x00000000, and gets mapped to 
-          virtual address 0xC0000000 for the kernel.
-
-
-        Physical addresses used by the Linux kernel:
-        --------------------------------------------
-
-        0x00000000-0x3FFFFFFF   1GB reserved for RAM
-        0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
-                                 64K for 8260 registers
-
-        
-        Logical addresses used by the Linux kernel:
-        -------------------------------------------
-
-        0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
-        0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
-        0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
-        0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)
-
-
-        EST SBC8260 Linux mapping:
-        --------------------------
-
-        DBAT0, IBAT0, cache inhibited:
-
-                                Chip
-        Memory                  Sel  Use
-        ---------------------   ---  ---------------------------------
-        0xF0000000-0xF001FFFF   n/a  IMMR: dual port RAM, registers
-
-        DBAT1, IBAT1, cache inhibited:
-
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt
index b35f3482e3e..2ea76d9d137 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt
@@ -7,6 +7,15 @@ Currently defined compatibles:
 - fsl,cpm2-scc-uart
 - fsl,qe-uart
 
+Modem control lines connected to GPIO controllers are listed in the gpios
+property as described in booting-without-of.txt, section IX.1 in the following
+order:
+
+CTS, RTS, DCD, DSR, DTR, and RI.
+
+The gpios property is optional and can be left out when control lines are
+not used.
+
 Example:
 
         serial@11a00 {
@@ -18,4 +27,6 @@ Example:
                 interrupt-parent = <&PIC>;
                 fsl,cpm-brg = <1>;
                 fsl,cpm-command = <00800000>;
+                gpios = <&gpio_c 15 0
+                         &gpio_d 29 0>;
         };
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 0843ed0163a..28b6ec87c64 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -390,9 +390,10 @@ rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft
 rfkill input line is active.  Only if none of the rfkill input lines are
 active, will it return RFKILL_STATE_UNBLOCKED.
 
-If it doesn't implement the get_state() hook, it must make sure that its calls
-to rfkill_force_state() are enough to keep the status always up-to-date, and it
-must do a rfkill_force_state() on resume from sleep.
+Since the device has a hardware rfkill line, it IS subject to state changes
+external to rfkill.  Therefore, the driver must make sure that it calls
+rfkill_force_state() to keep the status always up-to-date, and it must do a
+rfkill_force_state() on resume from sleep.
 
 Every time the driver gets a notification from the card that one of its rfkill
 lines changed state (polling might be needed on badly designed cards that don't
@@ -422,13 +423,24 @@ of the hardware is unknown), or read-write (where the hardware can be queried
 about its current state).
 
 The rfkill class will call the get_state hook of a device every time it needs
-to know the *real* current state of the hardware.  This can happen often.
+to know the *real* current state of the hardware.  This can happen often, but
+it does not do any polling, so it is not enough on hardware that is subject
+to state changes outside of the rfkill subsystem.
+
+Therefore, calling rfkill_force_state() when a state change happens is
+mandatory when the device has a hardware rfkill line, or when something else
+like the firmware could cause its state to be changed without going through the
+rfkill class.
 
 Some hardware provides events when its status changes.  In these cases, it is
 best for the driver to not provide a get_state hook, and instead register the
 rfkill class *already* with the correct status, and keep it updated using
 rfkill_force_state() when it gets an event from the hardware.
 
+rfkill_force_state() must be used on the device resume handlers to update the
+rfkill status, should there be any chance of the device status changing during
+the sleep.
+
 There is no provision for a statically-allocated rfkill struct.  You must
 use rfkill_allocate() to allocate one.