1. 23 Mar, 2012 1 commit
    • Kim, Milo's avatar
      backlight: new backlight driver for LP855x devices · 7be865ab
      Kim, Milo authored
      THis driver supports TI LP8550/LP8551/LP8552/LP8553/LP8556 backlight
      devices.
      
      The brightness can be controlled by the I2C or PWM input.  The lp855x
      driver provides both modes.  For the PWM control, pwm-specific functions
      can be defined in the platform data.  And some information can be read
      via the sysfs(lp855x device attributes).
      
      For details, please refer to Documentation/backlight/lp855x-driver.txt.
      
      [axel.lin@gmail.com: add missing mutex_unlock in lp855x_read_byte() error path]
      [axel.lin@gmail.com: check platform data in lp855x_probe()]
      [axel.lin@gmail.com: small cleanups]
      [dan.carpenter@oracle.com: silence a compiler warning]
      [axel.lin@gmail.com: use id->driver_data to differentiate lp855x chips]
      [akpm@linux-foundation.org: simplify boolean return expression]
      Signed-off-by: default avatarMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7be865ab
  2. 22 Mar, 2012 4 commits
    • Jason Wessel's avatar
      kgdb,debug_core: add the ability to control the reboot notifier · bec4d62e
      Jason Wessel authored
      Sometimes it is desirable to stop the kernel debugger before allowing
      a system to reboot either with kdb or kgdb.  This patch adds the
      ability to turn the reboot notifier on and off or enter the debugger
      and stop kernel execution before rebooting.
      
      It is possible to change the setting after booting the kernel with the
      following:
      
      echo 1 > /sys/module/debug_core/parameters/kgdbreboot
      
      It is also possible to change this setting using kdb / kgdb to
      manipulate the variable directly.
      
      Using KDB:
         mm kgdbreboot 1
      
      Using gdb:
         set kgdbreboot=1
      Reported-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      bec4d62e
    • Siddhesh Poyarekar's avatar
      procfs: mark thread stack correctly in proc/<pid>/maps · b7643757
      Siddhesh Poyarekar authored
      Stack for a new thread is mapped by userspace code and passed via
      sys_clone.  This memory is currently seen as anonymous in
      /proc/<pid>/maps, which makes it difficult to ascertain which mappings
      are being used for thread stacks.  This patch uses the individual task
      stack pointers to determine which vmas are actually thread stacks.
      
      For a multithreaded program like the following:
      
      	#include <pthread.h>
      
      	void *thread_main(void *foo)
      	{
      		while(1);
      	}
      
      	int main()
      	{
      		pthread_t t;
      		pthread_create(&t, NULL, thread_main, NULL);
      		pthread_join(t, NULL);
      	}
      
      proc/PID/maps looks like the following:
      
          00400000-00401000 r-xp 00000000 fd:0a 3671804                            /home/siddhesh/a.out
          00600000-00601000 rw-p 00000000 fd:0a 3671804                            /home/siddhesh/a.out
          019ef000-01a10000 rw-p 00000000 00:00 0                                  [heap]
          7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
          7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0
          7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
          7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
          7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
          7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
          7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
          7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0                          [stack]
          7fff627ff000-7fff62800000 r-xp 00000000 00:00 0                          [vdso]
          ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
      
      Here, one could guess that 7f8a44492000-7f8a44c92000 is a stack since
      the earlier vma that has no permissions (7f8a44e3d000-7f8a4503d000) but
      that is not always a reliable way to find out which vma is a thread
      stack.  Also, /proc/PID/maps and /proc/PID/task/TID/maps has the same
      content.
      
      With this patch in place, /proc/PID/task/TID/maps are treated as 'maps
      as the task would see it' and hence, only the vma that that task uses as
      stack is marked as [stack].  All other 'stack' vmas are marked as
      anonymous memory.  /proc/PID/maps acts as a thread group level view,
      where all thread stack vmas are marked as [stack:TID] where TID is the
      process ID of the task that uses that vma as stack, while the process
      stack is marked as [stack].
      
      So /proc/PID/maps will look like this:
      
          00400000-00401000 r-xp 00000000 fd:0a 3671804                            /home/siddhesh/a.out
          00600000-00601000 rw-p 00000000 fd:0a 3671804                            /home/siddhesh/a.out
          019ef000-01a10000 rw-p 00000000 00:00 0                                  [heap]
          7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
          7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0                          [stack:1442]
          7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
          7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
          7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
          7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
          7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
          7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0                          [stack]
          7fff627ff000-7fff62800000 r-xp 00000000 00:00 0                          [vdso]
          ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
      
      Thus marking all vmas that are used as stacks by the threads in the
      thread group along with the process stack.  The task level maps will
      however like this:
      
          00400000-00401000 r-xp 00000000 fd:0a 3671804                            /home/siddhesh/a.out
          00600000-00601000 rw-p 00000000 fd:0a 3671804                            /home/siddhesh/a.out
          019ef000-01a10000 rw-p 00000000 00:00 0                                  [heap]
          7f8a44491000-7f8a44492000 ---p 00000000 00:00 0
          7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0                          [stack]
          7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482                    /lib64/libc-2.14.90.so
          7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0
          7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938                    /lib64/libpthread-2.14.90.so
          7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0
          7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0
          7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0
          7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348                    /lib64/ld-2.14.90.so
          7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0
          7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0
          7fff627ff000-7fff62800000 r-xp 00000000 00:00 0                          [vdso]
          ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
      
      where only the vma that is being used as a stack by *that* task is
      marked as [stack].
      
      Analogous changes have been made to /proc/PID/smaps,
      /proc/PID/numa_maps, /proc/PID/task/TID/smaps and
      /proc/PID/task/TID/numa_maps. Relevant snippets from smaps and
      numa_maps:
      
          [siddhesh@localhost ~ ]$ pgrep a.out
          1441
          [siddhesh@localhost ~ ]$ cat /proc/1441/smaps | grep "\[stack"
          7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0                          [stack:1442]
          7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0                          [stack]
          [siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/smaps | grep "\[stack"
          7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0                          [stack]
          [siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/smaps | grep "\[stack"
          7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0                          [stack]
          [siddhesh@localhost ~ ]$ cat /proc/1441/numa_maps | grep "stack"
          7f8a44492000 default stack:1442 anon=2 dirty=2 N0=2
          7fff6273a000 default stack anon=3 dirty=3 N0=3
          [siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/numa_maps | grep "stack"
          7f8a44492000 default stack anon=2 dirty=2 N0=2
          [siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/numa_maps | grep "stack"
          7fff6273a000 default stack anon=3 dirty=3 N0=3
      
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: default avatarSiddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Jamie Lokier <jamie@shareable.org>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b7643757
    • Jiri Kosina's avatar
      thp: documentation: 'transparent_hugepage=' can also be specified on cmdline · fcf4d821
      Jiri Kosina authored
      The behavior of THP can either be toggled through sysfs in runtime or
      using a kernel cmdline parameter 'transparent_hugepage='.  Document the
      latter in kernel-parameters.txt
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fcf4d821
    • Naoya Horiguchi's avatar
      pagemap: document KPF_THP and make page-types aware of it · 807f0ccf
      Naoya Horiguchi authored
      page-types, which is a common user of pagemap, gets aware of thp with this
      patch.  This helps system admins and kernel hackers know about how thp
      works.  Here is a sample output of page-types over a thp:
      
        $ page-types -p <pid> --raw --list
      
        voffset offset  len     flags
        ...
        7f9d40200       3f8400  1       ___U_lA____Ma_bH______t____________
        7f9d40201       3f8401  1ff     ________________T_____t____________
      
                     flags      page-count       MB  symbolic-flags                     long-symbolic-flags
        0x0000000000410000             511        1  ________________T_____t____________        compound_tail,thp
        0x000000000040d868               1        0  ___U_lA____Ma_bH______t____________        uptodate,lru,active,mmap,anonymous,swapbacked,compound_head,thp
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Reviewed-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      807f0ccf
  3. 21 Mar, 2012 5 commits
    • Sachin Bhamare's avatar
      pnfs-obj: autologin: Add support for protocol autologin · 18d98f6c
      Sachin Bhamare authored
      The pnfs-objects protocol mandates that we autologin into devices not
      present in the system, according to information specified in the
      get_device_info returned from the server.
      
      The Protocol specifies two login hints.
      1. An IP address:port combination
      2. A string URI which is constructed as a URL with a protocol prefix
         followed by :// and a string as address. For each  protocol prefix
         the string-address format might be different.
      
      We only support the second option. The first option is just redundant
      to the second one.
      NOTE: The Kernel part of autologin does not parse the URI string. It
      just channels it to a user-mode script. So any new login protocols should
      only update the user-mode script which is a part of the nfs-utils package,
      but the Kernel need not change.
      
      We implement the autologin by using the call_usermodehelper() API.
      (Thanks to Steve Dickson <steved@redhat.com> for pointing it out)
      So there is no running daemon needed, and/or special setup.
      
      We Add the osd_login_prog Kernel module parameters which defaults to:
      	/sbin/osd_login
      
      Kernel try's to upcall the program specified in osd_login_prog. If the file is
      not found or the execution fails Kernel will disable any farther upcalls, by
      zeroing out  osd_login_prog, Until Admin re-enables it by setting the
      osd_login_prog parameter to a proper program.
      
      Also add text about the osd_login program command line API to:
      	Documentation/filesystems/nfs/pnfs.txt
      and documentation of the new  osd_login_prog  module parameter to:
      	Documentation/kernel-parameters.txt
      
      TODO: Add timeout option in the case osd_login program gets
                    stuck
      Signed-off-by: default avatarSachin Bhamare <sbhamare@panasas.com>
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      18d98f6c
    • Al Viro's avatar
      debugfs-related mode_t whack-a-mole · 88187398
      Al Viro authored
      all of those should be umode_t...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      88187398
    • Matthew Garrett's avatar
      hfsplus: add an ioctl to bless files · a051f71c
      Matthew Garrett authored
      Making an hfsplus partition bootable requires the ability to "bless" a
      file by putting its inode number in the volume header. Doing this from
      userspace on a mounted filesystem is impractical since the kernel will
      write back the original values on unmount. Add an ioctl to allow userspace
      to update the volume header information based on the target file.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      a051f71c
    • Kai Bankett's avatar
      fs: initial qnx6fs addition · 5d026c72
      Kai Bankett authored
      Adds support for qnx6fs readonly support to the linux kernel.
      
      * Mount option
        The option mmi_fs can be used to mount Harman Becker/Audi MMI 3G
        HDD qnx6fs filesystems.
      
      * Documentation
        A high level filesystem stucture description can be found in the
        Documentation/filesystems directory. (qnx6.txt)
      
      * Additional features
        - Active (stable) superblock selection
        - Superblock checksum check (enforced)
        - Supports mount of qnx6 filesystems with to host different endianess
        - Automatic endianess detection
        - Longfilename support (with non-enfocing crc check)
        - All blocksizes (512, 1024, 2048 and 4096 supported)
      Signed-off-by: default avatarKai Bankett <chaosman@ontika.net>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      5d026c72
    • Al Viro's avatar
      vfs: d_alloc_root() gone · 32991ab3
      Al Viro authored
      all callers converted to d_make_root() by now
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      32991ab3
  4. 20 Mar, 2012 3 commits
    • Cong Wang's avatar
    • Hans de Goede's avatar
      hwmon: (sch56xx) Add support for the integrated watchdog (v2) · 312869ec
      Hans de Goede authored
      Add support for the watchdog integrated into the SMSC SCH5627 and
      SCH5636 superio-s. Since the watchdog is part of the hwmon logical device
      and thus shares ioports with it, the watchdog driver is integrated into the
      existing hwmon drivers for these.
      
      Note that this version of the watchdog support for sch56xx superio-s
      implements the watchdog chardev interface itself, rather then relying on
      the recently added watchdog core / watchdog_dev. This is done because
      currently some needed functionality is missing from watchdog_dev, as soon
      as this functionality is added (which is being discussed on the
      linux-watchdog mailinglist), I'll convert this driver over to using
      watchdog_dev.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      [guenter.roeck@ericsson.com: Added missing linux/slab.h include]
      Signed-off-by: default avatarGuenter Roeck <guenter.roeck@ericsson.com>
      312869ec
    • Carsten Emde's avatar
      drm: allow loading an EDID as firmware to override broken monitor · da0df92b
      Carsten Emde authored
      Broken monitors and/or broken graphic boards may send erroneous or no
      EDID data. This also applies to broken KVM devices that are unable to
      correctly forward the EDID data of the connected monitor but invent
      their own fantasy data.
      
      This patch allows to specify an EDID data set to be used instead of
      probing the monitor for it. It contains built-in data sets of frequently
      used screen resolutions. In addition, a particular EDID data set may be
      provided in the /lib/firmware directory and loaded via the firmware
      interface. The name is passed to the kernel as module parameter of the
      drm_kms_helper module either when loaded
        options drm_kms_helper edid_firmware=edid/1280x1024.bin
      or as kernel commandline parameter
        drm_kms_helper.edid_firmware=edid/1280x1024.bin
      
      It is also possible to restrict the usage of a specified EDID data set
      to a particular connector. This is done by prepending the name of the
      connector to the name of the EDID data set using the syntax
        edid_firmware=[<connector>:]<edid>
      such as, for example,
        edid_firmware=DVI-I-1:edid/1920x1080.bin
      in which case no other connector will be affected.
      
      The built-in data sets are
      Resolution    Name
      --------------------------------
      1024x768      edid/1024x768.bin
      1280x1024     edid/1280x1024.bin
      1680x1050     edid/1680x1050.bin
      1920x1080     edid/1920x1080.bin
      
      They are ignored, if a file with the same name is available in the
      /lib/firmware directory.
      
      The built-in EDID data sets are based on standard timings that may not
      apply to a particular monitor and even crash it. Ideally, EDID data of
      the connected monitor should be used. They may be obtained through the
      drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
      of a correctly working graphics adapter.
      
      It is even possible to specify the name of an EDID data set on-the-fly
      via the /sys/module interface, e.g.
      echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
      The new screen mode is considered when the related kernel function is
      called for the first time after the change. Such calls are made when the
      X server is started or when the display settings dialog is opened in an
      already running X server.
      Signed-off-by: default avatarCarsten Emde <C.Emde@osadl.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      da0df92b
  5. 19 Mar, 2012 8 commits
  6. 18 Mar, 2012 1 commit
  7. 17 Mar, 2012 1 commit
  8. 16 Mar, 2012 3 commits
  9. 14 Mar, 2012 3 commits
  10. 13 Mar, 2012 5 commits
  11. 12 Mar, 2012 1 commit
  12. 11 Mar, 2012 2 commits
  13. 08 Mar, 2012 1 commit
    • Linus Walleij's avatar
      spi: create a message queueing infrastructure · ffbbdd21
      Linus Walleij authored
      This rips the message queue in the PL022 driver out and pushes
      it into (optional) common infrastructure. Drivers that want to
      use the message pumping thread will need to define the new
      per-messags transfer methods and leave the deprecated transfer()
      method as NULL.
      
      Most of the design is described in the documentation changes that
      are included in this patch.
      
      Since there is a queue that need to be stopped when the system
      is suspending/resuming, two new calls are implemented for the
      device drivers to call in their suspend()/resume() functions:
      spi_master_suspend() and spi_master_resume().
      
      ChangeLog v1->v2:
      - Remove Kconfig entry and do not make the queue support optional
        at all, instead be more agressive and have it as part of the
        compulsory infrastructure.
      - If the .transfer() method is implemented, delete print a small
        deprecation notice and do not start the transfer pump.
      - Fix a bitrotted comment.
      ChangeLog v2->v3:
      - Fix up a problematic sequence courtesy of Chris Blair.
      - Stop rather than destroy the queue on suspend() courtesy of
        Chris Blair.
      Signed-off-by: default avatarChris Blair <chris.blair@stericsson.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Tested-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      ffbbdd21
  14. 07 Mar, 2012 2 commits