1. 19 Feb, 2009 8 commits
    • Tony Luck's avatar
      [IA64] xen_domu build fix · ec8148de
      Tony Luck authored
      arch/ia64/xen/xen_pv_ops.c:156: error: xen_init_ops causes a section type conflict
      arch/ia64/xen/xen_pv_ops.c:340: error: xen_iosapic_ops causes a section type conflict
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      ec8148de
    • Isaku Yamahata's avatar
      [IA64] fixes configs and add default config for ia64 xen domU · 1d5b20f4
      Isaku Yamahata authored
      This patch fixes xen related Kconfigs and add default config
      file for ia64 xen domU.
      Signed-off-by: default avatarIsaku Yamahata <yamahata@valinux.co.jp>
      Signed-off-by: default avatarTony Luck <aegl@agluck-desktop.(none)>
      1d5b20f4
    • Alex Chiang's avatar
      [IA64] Remove redundant cpu_clear() in __cpu_disable path · c0acdea2
      Alex Chiang authored
      The second call to cpu_clear() is redundant, as we've already removed
      the CPU from cpu_online_map before calling migrate_platform_irqs().
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarTony Luck <aegl@agluck-desktop.(none)>
      c0acdea2
    • Alex Chiang's avatar
      [IA64] Revert "prevent ia64 from invoking irq handlers on offline CPUs" · 66db2e63
      Alex Chiang authored
      This reverts commit e7b14036.
      
      Commit e7b14036 removes the targetted disabled CPU from the
      cpu_online_map after calls to migrate_platform_irqs and fixup_irqs.
      
      Paul McKenney states that the reasoning behind the patch was to
      prevent irq handlers from running on CPUs marked offline because:
      
      	RCU happily ignores CPUs that don't have their bits set in
      	cpu_online_map, so if there are RCU read-side critical sections
      	in the irq handlers being run, RCU will ignore them.  If the
      	other CPUs were running, they might sequence through the RCU
      	state machine, which could result in data structures being
      	yanked out from under those irq handlers, which in turn could
      	result in oopses or worse.
      
      Unfortunately, both ia64 functions above look at cpu_online_map to find
      a new CPU to migrate interrupts onto. This means we can potentially
      migrate an interrupt off ourself back to... ourself. Uh oh.
      
      This causes an oops when we finally try to process pending interrupts on
      the CPU we want to disable. The oops results from calling __do_IRQ with
      a NULL pt_regs:
      
      Unable to handle kernel NULL pointer dereference (address 0000000000000040)
      Call Trace:
       [<a000000100016930>] show_stack+0x50/0xa0
                                      sp=e0000009c922fa00 bsp=e0000009c92214d0
       [<a0000001000171a0>] show_regs+0x820/0x860
                                      sp=e0000009c922fbd0 bsp=e0000009c9221478
       [<a00000010003c700>] die+0x1a0/0x2e0
                                      sp=e0000009c922fbd0 bsp=e0000009c9221438
       [<a0000001006e92f0>] ia64_do_page_fault+0x950/0xa80
                                      sp=e0000009c922fbd0 bsp=e0000009c92213d8
       [<a00000010000c7a0>] ia64_native_leave_kernel+0x0/0x270
                                      sp=e0000009c922fc60 bsp=e0000009c92213d8
       [<a0000001000ecdb0>] profile_tick+0xd0/0x1c0
                                      sp=e0000009c922fe30 bsp=e0000009c9221398
       [<a00000010003bb90>] timer_interrupt+0x170/0x3e0
                                      sp=e0000009c922fe30 bsp=e0000009c9221330
       [<a00000010013a800>] handle_IRQ_event+0x80/0x120
                                      sp=e0000009c922fe30 bsp=e0000009c92212f8
       [<a00000010013aa00>] __do_IRQ+0x160/0x4a0
                                      sp=e0000009c922fe30 bsp=e0000009c9221290
       [<a000000100012290>] ia64_process_pending_intr+0x2b0/0x360
                                      sp=e0000009c922fe30 bsp=e0000009c9221208
       [<a0000001000112d0>] fixup_irqs+0xf0/0x2a0
                                      sp=e0000009c922fe30 bsp=e0000009c92211a8
       [<a00000010005bd80>] __cpu_disable+0x140/0x240
                                      sp=e0000009c922fe30 bsp=e0000009c9221168
       [<a0000001006c5870>] take_cpu_down+0x50/0xa0
                                      sp=e0000009c922fe30 bsp=e0000009c9221148
       [<a000000100122610>] stop_cpu+0xd0/0x200
                                      sp=e0000009c922fe30 bsp=e0000009c92210f0
       [<a0000001000e0440>] kthread+0xc0/0x140
                                      sp=e0000009c922fe30 bsp=e0000009c92210c8
       [<a000000100014ab0>] kernel_thread_helper+0xd0/0x100
                                      sp=e0000009c922fe30 bsp=e0000009c92210a0
       [<a00000010000a4c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000009c922fe30 bsp=e0000009c92210a0
      
      I don't like this revert because it is fragile. ia64 is getting lucky
      because we seem to only ever process timer interrupts in this path, but
      if we ever race with an IPI here, we definitely use RCU and have the
      potential of hitting an oops that Paul describes above.
      
      Patching ia64's timer_interrupt() to check for NULL pt_regs is
      insufficient though, as we still hit the above oops.
      
      As a short term solution, I do think that this revert is the right
      answer. The revert hold up under repeated testing (24+ hour test runs)
      with this setup:
      
      	- 8-way rx6600
      	- randomly toggling CPU online/offline state every 2 seconds
      	- running CPU exercisers, memory hog, disk exercisers, and
      	  network stressors
      	- average system load around ~160
      
      In the long term, we really need to figure out why we set pt_regs = NULL
      in ia64_process_pending_intr(). If it turns out that it is unnecessary
      to do so, then we could safely re-introduce e7b14036 (along with some
      other logic to be smarter about migrating interrupts).
      
      One final note: x86 also removes the disabled CPU from cpu_online_map
      and then re-enables interrupts for 1ms, presumably to handle any pending
      interrupts:
      
      arch/x86/kernel/irq_32.c (and irq_64.c):
      cpu_disable_common:
      	[remove cpu from cpu_online_map]
      
      	fixup_irqs():
      		for_each_irq:
      			[break CPU affinities]
      
      		local_irq_enable();
      		mdelay(1);
      		local_irq_disable();
      
      So they are doing implicitly what ia64 is doing explicitly.
      Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarTony Luck <aegl@agluck-desktop.(none)>
      66db2e63
    • Robin Holt's avatar
      [IA64] bte_copy of BTE_MAX_XFER trips BUG_ON. · 39d481cb
      Robin Holt authored
      BTE_MAX_XFER is wrong.  It is one greater than the number of cache
      lines the BTE is actually able to transfer.  If you request a transfer
      of exactly BTE_MAX_XFER size, you trip a very cryptic BUG_ON() which
      should certainly be made more clear.
      
      This patch fixes that constant and also cleans up the BUG_ON()s in
      arch/ia64/sn/kernel/bte.c to test one condition per line.
      Signed-off-by: default avatarRobin Holt <holt@sgi.com>
      Signed-off-by: default avatarTony Luck <aegl@agluck-desktop.(none)>
      39d481cb
    • Tony Luck's avatar
      [IA64] Build fix for __early_pfn_to_nid() undefined link error · 334f85b6
      Tony Luck authored
      ia64 only defines __early_pfn_to_nid() for SPARSEMEM && NUMA configurations,
      so the recent:
      
      	commit: f2dbcfa7
      	mm: clean up for early_pfn_to_nid()
      
      ends up with some link problems for certain configuration files.
      
      Fix arch/ia64/Kconfig to only define HAVE_ARCH_EARLY_PFN_TO_NID in the
      cases where we do provide this function.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      334f85b6
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block · ba95fd47
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.dk/linux-2.6-block:
        block: fix deadlock in blk_abort_queue() for drivers that readd to timeout list
        block: fix booting from partitioned md array
        block: revert part of 18ce3751
        cciss: PCI power management reset for kexec
        paride/pg.c: xs(): &&/|| confusion
        fs/bio: bio_alloc_bioset: pass right object ptr to mempool_free
        block: fix bad definition of BIO_RW_SYNC
        bsg: Fix sense buffer bug in SG_IO
      ba95fd47
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc · 59af0a0b
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
        omap_hsmmc: Change while(); loops with finite version
        omap_hsmmc: recover from transfer failures
        omap_hsmmc: only MMC1 allows HCTL.SDVS != 1.8V
        omap_hsmmc: card detect irq bugfix
        sdhci: fix led naming
        mmc_test: fix basic read test
        s3cmci: Fix hangup in do_pio_write()
        Revert "sdhci: force high speed capability on some controllers"
        MMC: fix bug - SDHC card capacity not correct
      59af0a0b
  2. 18 Feb, 2009 32 commits
    • Ingo Molnar's avatar
      inotify: fix GFP_KERNEL related deadlock · f04b30de
      Ingo Molnar authored
      Enhanced lockdep coverage of __GFP_NOFS turned up this new lockdep
      assert:
      
      [ 1093.677775]
      [ 1093.677781] =================================
      [ 1093.680031] [ INFO: inconsistent lock state ]
      [ 1093.680031] 2.6.29-rc5-tip-01504-gb49eca1-dirty #1
      [ 1093.680031] ---------------------------------
      [ 1093.680031] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
      [ 1093.680031] kswapd0/308 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [ 1093.680031]  (&inode->inotify_mutex){+.+.?.}, at: [<c0205942>] inotify_inode_is_dead+0x20/0x80
      [ 1093.680031] {RECLAIM_FS-ON-W} state was registered at:
      [ 1093.680031]   [<c01696b9>] mark_held_locks+0x43/0x5b
      [ 1093.680031]   [<c016baa4>] lockdep_trace_alloc+0x6c/0x6e
      [ 1093.680031]   [<c01cf8b0>] kmem_cache_alloc+0x20/0x150
      [ 1093.680031]   [<c040d0ec>] idr_pre_get+0x27/0x6c
      [ 1093.680031]   [<c02056e3>] inotify_handle_get_wd+0x25/0xad
      [ 1093.680031]   [<c0205f43>] inotify_add_watch+0x7a/0x129
      [ 1093.680031]   [<c020679e>] sys_inotify_add_watch+0x20f/0x250
      [ 1093.680031]   [<c010389e>] sysenter_do_call+0x12/0x35
      [ 1093.680031]   [<ffffffff>] 0xffffffff
      [ 1093.680031] irq event stamp: 60417
      [ 1093.680031] hardirqs last  enabled at (60417): [<c018d5f5>] call_rcu+0x53/0x59
      [ 1093.680031] hardirqs last disabled at (60416): [<c018d5b9>] call_rcu+0x17/0x59
      [ 1093.680031] softirqs last  enabled at (59656): [<c0146229>] __do_softirq+0x157/0x16b
      [ 1093.680031] softirqs last disabled at (59651): [<c0106293>] do_softirq+0x74/0x15d
      [ 1093.680031]
      [ 1093.680031] other info that might help us debug this:
      [ 1093.680031] 2 locks held by kswapd0/308:
      [ 1093.680031]  #0:  (shrinker_rwsem){++++..}, at: [<c01b0502>] shrink_slab+0x36/0x189
      [ 1093.680031]  #1:  (&type->s_umount_key#4){+++++.}, at: [<c01e6d77>] shrink_dcache_memory+0x110/0x1fb
      [ 1093.680031]
      [ 1093.680031] stack backtrace:
      [ 1093.680031] Pid: 308, comm: kswapd0 Not tainted 2.6.29-rc5-tip-01504-gb49eca1-dirty #1
      [ 1093.680031] Call Trace:
      [ 1093.680031]  [<c016947a>] valid_state+0x12a/0x13d
      [ 1093.680031]  [<c016954e>] mark_lock+0xc1/0x1e9
      [ 1093.680031]  [<c016a5b4>] ? check_usage_forwards+0x0/0x3f
      [ 1093.680031]  [<c016ab74>] __lock_acquire+0x2c6/0xac8
      [ 1093.680031]  [<c01688d9>] ? register_lock_class+0x17/0x228
      [ 1093.680031]  [<c016b3d3>] lock_acquire+0x5d/0x7a
      [ 1093.680031]  [<c0205942>] ? inotify_inode_is_dead+0x20/0x80
      [ 1093.680031]  [<c08824c4>] __mutex_lock_common+0x3a/0x4cb
      [ 1093.680031]  [<c0205942>] ? inotify_inode_is_dead+0x20/0x80
      [ 1093.680031]  [<c08829ed>] mutex_lock_nested+0x2e/0x36
      [ 1093.680031]  [<c0205942>] ? inotify_inode_is_dead+0x20/0x80
      [ 1093.680031]  [<c0205942>] inotify_inode_is_dead+0x20/0x80
      [ 1093.680031]  [<c01e6672>] dentry_iput+0x90/0xc2
      [ 1093.680031]  [<c01e67a3>] d_kill+0x21/0x45
      [ 1093.680031]  [<c01e6a46>] __shrink_dcache_sb+0x27f/0x355
      [ 1093.680031]  [<c01e6dc5>] shrink_dcache_memory+0x15e/0x1fb
      [ 1093.680031]  [<c01b05ed>] shrink_slab+0x121/0x189
      [ 1093.680031]  [<c01b0d12>] kswapd+0x39f/0x561
      [ 1093.680031]  [<c01ae499>] ? isolate_pages_global+0x0/0x233
      [ 1093.680031]  [<c0157eae>] ? autoremove_wake_function+0x0/0x43
      [ 1093.680031]  [<c01b0973>] ? kswapd+0x0/0x561
      [ 1093.680031]  [<c0157daf>] kthread+0x41/0x82
      [ 1093.680031]  [<c0157d6e>] ? kthread+0x0/0x82
      [ 1093.680031]  [<c01043ab>] kernel_thread_helper+0x7/0x10
      
      inotify_handle_get_wd() does idr_pre_get() which does a
      kmem_cache_alloc() without __GFP_FS - and is hence deadlockable under
      extreme MM pressure.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: MinChan Kim <minchan.kim@gmail.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f04b30de
    • Michael Buesch's avatar
      spi-gpio: sanitize MISO bitvalue · be50344e
      Michael Buesch authored
      gpio_get_value() returns 0 or nonzero, but getmiso() expects 0 or 1.
      Sanitize the value to a 0/1 boolean.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Acked-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      be50344e
    • Bernhard Walle's avatar
      Bernhard has moved · 97bef7dd
      Bernhard Walle authored
      Since I don't work for SUSE any more and the bwalle@suse.de address is
      invalid, correct it in the copyright headers and documentation.
      Signed-off-by: default avatarBernhard Walle <bernhard.walle@gmx.de>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      97bef7dd
    • Randy Dunlap's avatar
      x86: dell-laptop: depends on POWER_SUPPLY · 310d8c93
      Randy Dunlap authored
      Build breaks when DELL_LAPTOP=y and POWER_SUPPLY=m.  DELL_LAPTOP needs to
      depend on POWER_SUPPLY.
      
      dell-laptop.c:(.text+0x1ef3c4): undefined reference to `power_supply_is_system_supplied'
      dell-laptop.c:(.text+0x1ef45e): undefined reference to `power_supply_is_system_supplied'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      310d8c93
    • Bill Nottingham's avatar
      vt: Declare PIO_CMAP/GIO_CMAP as compatbile ioctls. · 2db69a93
      Bill Nottingham authored
      Otherwise, these don't work when called from 32-bit userspace on 64-bit
      kernels.
      
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2db69a93
    • Krzysztof Helt's avatar
      fbdev/drm: fix Kconfig submenu mess in "Graphics support" · a1a5c3b9
      Krzysztof Helt authored
      Submenus of the graphics support "Support for frame buffer devices" and
      "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" are
      broken in half after latest changes for Intel 915 mode setting support.
      
      The DRM subsection is broken because one option is put outside the choice
      section it depends on.
      
      The frame buffers part is broken then due to circular dependency.  Fix
      this by make Intel frame buffers depend on CONFIG_INTEL_AGP.
      
      Kconfigs are broken by d2f59357
      ("drm/i915: select framebuffer support automatically").
      
      This is probably not only way to fix this.
      Signed-off-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a1a5c3b9
    • Philippe De Muyter's avatar
      floppy: request and release only the ports we actually use · 5a74db06
      Philippe De Muyter authored
      The floppy driver requests an I/O port it doesn't need, and sometimes this
      causes a conflict with a motherboard device reported by PNPBIOS.
      
      This patch makes the floppy driver request and release only the ports it
      actually uses.  It also factors out the request/release stuff and the
      io-ports list so they're all in one place now.
      
      The current floppy driver uses only these ports:
      
          0x3f2 (FD_DOR)
          0x3f4 (FD_STATUS)
          0x3f5 (FD_DATA)
          0x3f7 (FD_DCR/FD_DIR)
      
      but it requests 0x3f2-0x3f5 and 0x3f7, which includes the unused port
      0x3f3.
      
      Some BIOSes report 0x3f3 as a motherboard resource.  The PNP system driver
      reserves that, which causes a conflict when the floppy driver requests
      0x3f2-0x3f5 later.
      
      Philippe reported that this conflict broke the floppy driver between
      2.6.11 and 2.6.22.  His PNPBIOS reports these devices:
      
          $ cat 00:07/id 00:07/resources	# motherboard device
          PNP0c02
          state = active
          io 0x80-0x80
          io 0x10-0x1f
          io 0x22-0x3f
          io 0x44-0x5f
          io 0x90-0x9f
          io 0xa2-0xbf
          io 0x3f0-0x3f1
          io 0x3f3-0x3f3
      
          $ cat 00:03/id 00:03/resources	# floppy device
          PNP0700
          state = active
          io 0x3f4-0x3f5
          io 0x3f2-0x3f2
      
      Reference:
          http://lkml.org/lkml/2009/1/31/162Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarPhilippe De Muyter <phdm@macqel.be>
      Reported-by: default avatarPhilippe De Muyter <phdm@macqel.be>
      Tested-by: default avatarPhilippe De Muyter <phdm@macqel.be>
      Cc: Adam M Belay <abelay@mit.edu>
      Cc: Robert Hancock <hancockrwd@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5a74db06
    • Adam Lackorzynski's avatar
      jsm: additional device support · ffa7525c
      Adam Lackorzynski authored
      I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi
      International Digi Neo 8 (rev 05)
      
      that works with the jsm driver after using the following patch.
      Signed-off-by: default avatarAdam Lackorzynski <adam@os.inf.tu-dresden.de>
      Cc: Scott H Kilau <Scott_Kilau@digi.com>
      Cc: Wendy Xiong <wendyx@us.ibm.com>
      Acked-by: default avatarAlan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ffa7525c
    • KAMEZAWA Hiroyuki's avatar
      mm: fix memmap init for handling memory hole · cc2559bc
      KAMEZAWA Hiroyuki authored
      Now, early_pfn_in_nid(PFN, NID) may returns false if PFN is a hole.
      and memmap initialization was not done. This was a trouble for
      sparc boot.
      
      To fix this, the PFN should be initialized and marked as PG_reserved.
      This patch changes early_pfn_in_nid() return true if PFN is a hole.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reported-by: default avatarDavid Miller <davem@davemlloft.net>
      Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cc2559bc
    • KAMEZAWA Hiroyuki's avatar
      mm: clean up for early_pfn_to_nid() · f2dbcfa7
      KAMEZAWA Hiroyuki authored
      What's happening is that the assertion in mm/page_alloc.c:move_freepages()
      is triggering:
      
      	BUG_ON(page_zone(start_page) != page_zone(end_page));
      
      Once I knew this is what was happening, I added some annotations:
      
      	if (unlikely(page_zone(start_page) != page_zone(end_page))) {
      		printk(KERN_ERR "move_freepages: Bogus zones: "
      		       "start_page[%p] end_page[%p] zone[%p]\n",
      		       start_page, end_page, zone);
      		printk(KERN_ERR "move_freepages: "
      		       "start_zone[%p] end_zone[%p]\n",
      		       page_zone(start_page), page_zone(end_page));
      		printk(KERN_ERR "move_freepages: "
      		       "start_pfn[0x%lx] end_pfn[0x%lx]\n",
      		       page_to_pfn(start_page), page_to_pfn(end_page));
      		printk(KERN_ERR "move_freepages: "
      		       "start_nid[%d] end_nid[%d]\n",
      		       page_to_nid(start_page), page_to_nid(end_page));
       ...
      
      And here's what I got:
      
      	move_freepages: Bogus zones: start_page[2207d0000] end_page[2207dffc0] zone[fffff8103effcb00]
      	move_freepages: start_zone[fffff8103effcb00] end_zone[fffff8003fffeb00]
      	move_freepages: start_pfn[0x81f600] end_pfn[0x81f7ff]
      	move_freepages: start_nid[1] end_nid[0]
      
      My memory layout on this box is:
      
      [    0.000000] Zone PFN ranges:
      [    0.000000]   Normal   0x00000000 -> 0x0081ff5d
      [    0.000000] Movable zone start PFN for each node
      [    0.000000] early_node_map[8] active PFN ranges
      [    0.000000]     0: 0x00000000 -> 0x00020000
      [    0.000000]     1: 0x00800000 -> 0x0081f7ff
      [    0.000000]     1: 0x0081f800 -> 0x0081fe50
      [    0.000000]     1: 0x0081fed1 -> 0x0081fed8
      [    0.000000]     1: 0x0081feda -> 0x0081fedb
      [    0.000000]     1: 0x0081fedd -> 0x0081fee5
      [    0.000000]     1: 0x0081fee7 -> 0x0081ff51
      [    0.000000]     1: 0x0081ff59 -> 0x0081ff5d
      
      So it's a block move in that 0x81f600-->0x81f7ff region which triggers
      the problem.
      
      This patch:
      
      Declaration of early_pfn_to_nid() is scattered over per-arch include
      files, and it seems it's complicated to know when the declaration is used.
       I think it makes fix-for-memmap-init not easy.
      
      This patch moves all declaration to include/linux/mm.h
      
      After this,
        if !CONFIG_NODES_POPULATES_NODE_MAP && !CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
           -> Use static definition in include/linux/mm.h
        else if !CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
           -> Use generic definition in mm/page_alloc.c
        else
           -> per-arch back end function will be called.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reported-by: default avatarDavid Miller <davem@davemlloft.net>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f2dbcfa7
    • Peter Zijlstra's avatar
      fs/super.c: add lockdep annotation to s_umount · ada723dc
      Peter Zijlstra authored
      Li Zefan said:
      
      Thread 1:
        for ((; ;))
        {
            mount -t cpuset xxx /mnt > /dev/null 2>&1
            cat /mnt/cpus > /dev/null 2>&1
            umount /mnt > /dev/null 2>&1
        }
      
      Thread 2:
        for ((; ;))
        {
            mount -t cpuset xxx /mnt > /dev/null 2>&1
            umount /mnt > /dev/null 2>&1
        }
      
      (Note: It is irrelevant which cgroup subsys is used.)
      
      After a while a lockdep warning showed up:
      
      =============================================
      [ INFO: possible recursive locking detected ]
      2.6.28 #479
      ---------------------------------------------
      mount/13554 is trying to acquire lock:
       (&type->s_umount_key#19){--..}, at: [<c049d888>] sget+0x5e/0x321
      
      but task is already holding lock:
       (&type->s_umount_key#19){--..}, at: [<c049da0c>] sget+0x1e2/0x321
      
      other info that might help us debug this:
      1 lock held by mount/13554:
       #0:  (&type->s_umount_key#19){--..}, at: [<c049da0c>] sget+0x1e2/0x321
      
      stack backtrace:
      Pid: 13554, comm: mount Not tainted 2.6.28-mc #479
      Call Trace:
       [<c044ad2e>] validate_chain+0x4c6/0xbbd
       [<c044ba9b>] __lock_acquire+0x676/0x700
       [<c044bb82>] lock_acquire+0x5d/0x7a
       [<c049d888>] ? sget+0x5e/0x321
       [<c061b9b8>] down_write+0x34/0x50
       [<c049d888>] ? sget+0x5e/0x321
       [<c049d888>] sget+0x5e/0x321
       [<c045a2e7>] ? cgroup_set_super+0x0/0x3e
       [<c045959f>] ? cgroup_test_super+0x0/0x2f
       [<c045bcea>] cgroup_get_sb+0x98/0x2e7
       [<c045cfb6>] cpuset_get_sb+0x4a/0x5f
       [<c049dfa4>] vfs_kern_mount+0x40/0x7b
       [<c049e02d>] do_kern_mount+0x37/0xbf
       [<c04af4a0>] do_mount+0x5c3/0x61a
       [<c04addd2>] ? copy_mount_options+0x2c/0x111
       [<c04af560>] sys_mount+0x69/0xa0
       [<c0403251>] sysenter_do_call+0x12/0x31
      
      The cause is after alloc_super() and then retry, an old entry in list
      fs_supers is found, so grab_super(old) is called, but both functions hold
      s_umount lock:
      
      struct super_block *sget(...)
      {
      	...
      retry:
      	spin_lock(&sb_lock);
      	if (test) {
      		list_for_each_entry(old, &type->fs_supers, s_instances) {
      			if (!test(old, data))
      				continue;
      			if (!grab_super(old))  <--- 2nd: down_write(&old->s_umount);
      				goto retry;
      			if (s)
      				destroy_super(s);
      			return old;
      		}
      	}
      	if (!s) {
      		spin_unlock(&sb_lock);
      		s = alloc_super(type);   <--- 1th: down_write(&s->s_umount)
      		if (!s)
      			return ERR_PTR(-ENOMEM);
      		goto retry;
      	}
      	...
      }
      
      It seems like a false positive, and seems like VFS but not cgroup needs to
      be fixed.
      
      Peter said:
      
      We can simply put the new s_umount instance in a but lockdep doesn't
      particularly cares about subclass order.
      
      If there's any issue with the callers of sget() assuming the s_umount lock
      being of sublcass 0, then there is another annotation we can use to fix
      that, but lets not bother with that if this is sufficient.
      
      Addresses http://bugzilla.kernel.org/show_bug.cgi?id=12673Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Reported-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Paul Menage <menage@google.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ada723dc
    • Atsushi Nemoto's avatar
      atmel_serial might lose modem status change · 27c0c8e5
      Atsushi Nemoto authored
      I found a problem of handling of modem status of atmel_serial driver.
      
      With the commit 1ecc26 ("atmel_serial: split the interrupt handler"),
      handling of modem status signal was splitted into two parts.  The
      atmel_tasklet_func() compares new status with irq_status_prev, but
      irq_status_prev is not correct if signal status was changed while the port
      is closed.
      
      Here is a sequence to cause problem:
      
      1. Remote side sets CTS (and DSR).
      2. Local side close the port.
      3. Local side clears RTS and DTR.
      4. Remote side clears CTS and DSR.
      5. Local side reopen the port.  hw_stopped becomes 1.
      6. Local side sets RTS and DTR.
      7. Remote side sets CTS and DSR.
      
      Then CTS change interrupt can be received, but since CTS bit in
      irq_status_prev and new status is same, uart_handle_cts_change() will not
      be called (so hw_stopped will not be cleared, i.e.  cannot send any data).
      
      I suppose irq_status_prev should be initialized at somewhere in open
      sequence.
      
      Itai Levi pointed out that we need to initialize atmel_port->irq_status
      as well here. His analysis is as follows:
      
      > Regarding the second part of the patch (which resets irq_status_prev),
      > it turns out that both versions of the patch (mine and Atsushi's)
      > still leave enough room for faulty behavior when opening the port.
      >
      > This is because we are not resetting both irq_status_prev and
      > irq_status in atmel_startup() to CSR, which leads faulty behavior in
      > the following sequences:
      >
      > First case:
      > 1. closing the port while CTS line = 1 (TX not allowed)
      > 2. setting CTS line = 0 (TX allowed)
      > 3. opening the port
      > 4. transmitting one char
      > 5. Cannot transmit more chars, although CTS line is 0
      >
      > Second case:
      > 1. closing the port while CTS line = 0 (TX allowed)
      > 2. setting CTS line = 1 (TX not allowed)
      > 3. opening the port
      > 4. receiving some chars
      > 5. Now we can transmit, although CTS line is 1
      >
      > This reason for this is that the tasklet is scheduled as a result of
      > TX or RX interrupts (not a status change!), in steps 4 above. Inside
      > the tasklet, the atmel_port->irq_status (which holds the value from
      > the previous session) is compared to atmel_port->irq_status_prev.
      > Hence, a status-change of the CTS line is faultily detected.
      >
      > Both cases were verified on 9260 hardware.
      
      [haavard.skinnemoen@atmel.com: folded with patch from Itai Levi]
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Cc: Remy Bohmer <linux@bohmer.net>
      Cc: Marc Pignat <marc.pignat@hevs.ch>
      Cc: Itai Levi <itai.levi.devel@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      27c0c8e5
    • Dan Williams's avatar
      atmel-mci: fix initialization of dma slave data · 287d8592
      Dan Williams authored
      The conversion of atmel-mci to dma_request_channel missed the
      initialization of the channel dma_slave information.  The filter_fn passed
      to dma_request_channel is responsible for initializing the channel's
      private data.  This implementation has the additional benefit of enabling
      a generic client-channel data passing mechanism.
      Reviewed-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-by: default avatarHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      287d8592
    • Giuseppe Bilotta's avatar
      lis3lv02d: add axes knowledge of HP Pavilion dv5 models · 9ccf3b5e
      Giuseppe Bilotta authored
      Add support for HP Pavilion dv5.
      
      Since Intel-based models have an inverted x axis, while AMD-based models
      have an inverted y axis, we introduce a new macro that special-cases axis
      orientation based on two DMI entries: HP dv5 axis configuration is then
      based on both the PRODUCT and BOARD name.
      Signed-off-by: default avatarGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Cc: Eric Piel <Eric.Piel@tremplin-utc.net>
      Cc: Pavel Machek <pavel@suse.cz>
      Tested-by: default avatarPalatis Tseng <palatis@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9ccf3b5e
    • Giuseppe Bilotta's avatar
      lis3lv02d: support both one- and two-byte sensors · 137bad32
      Giuseppe Bilotta authored
      Sensors responding with 0x3B to WHO_AM_I only have one data register per
      direction, thus returning a signed byte from the position which is
      occupied by the MSB in sensors responding with 0x3A.
      
      Since multiple sensors share the reply to WHO_AM_I, we rename the defines
      to better indicate what they identify (family of single and double
      precision sensors).
      
      We support both kind of sensors by checking for the sensor type on init
      and defining appropriate data-access routines and sensor limits (for the
      joystick) depending on what we find.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Acked-by: default avatarEric Piel <Eric.Piel@tremplin-utc.net>
      Cc: Pavel Machek <pavel@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      137bad32
    • Pavel Machek's avatar
      hp accelerometer: add freefall detection · ef2cfc79
      Pavel Machek authored
      This adds freefall handling to hp_accel driver.  According to HP, it
      should just work, without us having to set the chip up by hand.
      
      hpfall.c is example .c program that parks the disk when accelerometer
      detects free fall.  It should work; for now, it uses fixed 20seconds
      protection period.
      Signed-off-by: default avatarPavel Machek <pavel@suse.cz>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Éric Piel <eric.piel@tremplin-utc.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef2cfc79
    • Alexey Dobriyan's avatar
      eeepc: should depend on INPUT · 3a5093ee
      Alexey Dobriyan authored
      Otherwise with INPUT=m, EEEPC_LAPTOP=y one gets
      
      drivers/built-in.o: In function `input_sync':
      eeepc-laptop.c:(.text+0x18ce51): undefined reference to `input_event'
      drivers/built-in.o: In function `input_report_key':
      eeepc-laptop.c:(.text+0x18ce73): undefined reference to `input_event'
      drivers/built-in.o: In function `eeepc_hotk_check':
      eeepc-laptop.c:(.text+0x18d05f): undefined reference to `input_allocate_device'
      eeepc-laptop.c:(.text+0x18d10f): undefined reference to `input_register_device'
      eeepc-laptop.c:(.text+0x18d131): undefined reference to `input_free_device'
      drivers/built-in.o: In function `eeepc_backlight_exit':
      eeepc-laptop.c:(.text+0x18d546): undefined reference to `input_unregister_device'
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3a5093ee
    • Rafael J. Wysocki's avatar
      pm: fix build for CONFIG_PM unset · 42f5e039
      Rafael J. Wysocki authored
      Compilation of kprobes.c with CONFIG_PM unset is broken due to some broken
      config dependncies.  Fix that.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Reported-by: default avatarIngo Molnar <mingo@elte.hu>
      Tested-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Len Brown <lenb@kernel.org>
      Acked-by: default avatarPavel Machek <pavel@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      42f5e039
    • Li Zefan's avatar
      cgroups: fix possible use after free · 67e055d1
      Li Zefan authored
      In cgroup_kill_sb(), root is freed before sb is detached from the list, so
      another sget() may find this sb and call cgroup_test_super(), which will
      access the root that has been freed.
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarPaul Menage <menage@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      67e055d1
    • Nick Piggin's avatar
      mm: task dirty accounting fix · 1cf6e7d8
      Nick Piggin authored
      YAMAMOTO-san noticed that task_dirty_inc doesn't seem to be called properly for
      cases where set_page_dirty is not used to dirty a page (eg. mark_buffer_dirty).
      
      Additionally, there is some inconsistency about when task_dirty_inc is
      called.  It is used for dirty balancing, however it even gets called for
      __set_page_dirty_no_writeback.
      
      So rather than increment it in a set_page_dirty wrapper, move it down to
      exactly where the dirty page accounting stats are incremented.
      
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1cf6e7d8
    • Davide Libenzi's avatar
      timerfd: add flags check · 610d18f4
      Davide Libenzi authored
      As requested by Michael, add a missing check for valid flags in
      timerfd_settime(), and make it return EINVAL in case some extra bits are
      set.
      
      Michael said:
      If this is to be any use to userland apps that want to check flag
      support (perhaps it is too late already), then the sooner we get it
      into the kernel the better: 2.6.29 would be good; earlier stables as
      well would be even better.
      
      [akpm@linux-foundation.org: remove unused TFD_FLAGS_SET]
      Acked-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
      Signed-off-by: default avatarDavide Libenzi <davidel@xmailserver.org>
      Cc: <stable@kernel.org>		[2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      610d18f4
    • Pavel Machek's avatar
      Pavel has moved · ef35ce23
      Pavel Machek authored
      My @suse.cz address will stop working some day, so put working one into
      MAINTAINERS/CREDITS.  It would be cool to get this to 2.6.29...  it should
      not really break anything.
      Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ef35ce23
    • Eric Biederman's avatar
      seq_file: properly cope with pread · 8f19d472
      Eric Biederman authored
      Currently seq_read assumes that the offset passed to it is always the
      offset it passed to user space.  In the case pread this assumption is
      broken and we do the wrong thing when presented with pread.
      
      To solve this I introduce an offset cache inside of struct seq_file so we
      know where our logical file position is.  Then in seq_read if we try to
      read from another offset we reset our data structures and attempt to go to
      the offset user space wanted.
      
      [akpm@linux-foundation.org: restore FMODE_PWRITE]
      [pjt@google.com: seq_open needs its fmode opened up to take advantage of this]
      Signed-off-by: default avatarEric Biederman <ebiederm@xmission.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Paul Turner <pjt@google.com>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f19d472
    • Paul Turner's avatar
      vfs: separate FMODE_PREAD/FMODE_PWRITE into separate flags · 55ec8217
      Paul Turner authored
      Separate FMODE_PREAD and FMODE_PWRITE into separate flags to reflect the
      reality that the read and write paths may have independent restrictions.
      
      A git grep verifies that these flags are always cleared together so this
      new behavior will only apply to interfaces that change to clear flags
      individually.
      
      This is required for "seq_file: properly cope with pread", a post-2.6.25
      regression fix.
      
      [akpm@linux-foundation.org: add comment]
      Signed-off-by: default avatarPaul Turner <pjt@google.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc:  Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x, 2.6.27.x, 2.6.28.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      55ec8217
    • Li Zefan's avatar
      cgroups: update documentation about css_set hash table · b851ee79
      Li Zefan authored
      The css_set hash table was introduced in 2.6.26, so update the
      documentation accordingly.
      Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: default avatarPaul Menage <menage@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b851ee79
    • Ed Cashin's avatar
      aoe: ignore vendor extension AoE responses · b6d6c517
      Ed Cashin authored
      The Welland ME-747K-SI AoE target generates unsolicited AoE responses that
      are marked as vendor extensions.  Instead of ignoring these packets, the
      aoe driver was generating kernel messages for each unrecognized response
      received.  This patch corrects the behavior.
      Signed-off-by: default avatarEd Cashin <ecashin@coraid.com>
      Reported-by: <karaluh@karaluh.pl>
      Tested-by: <karaluh@karaluh.pl>
      Cc: <stable@kernel.org>
      Cc: Alex Buell <alex.buell@munted.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b6d6c517
    • Benjamin Herrenschmidt's avatar
      vmalloc: add __get_vm_area_caller() · c2968612
      Benjamin Herrenschmidt authored
      We have get_vm_area_caller() and __get_vm_area() but not
      __get_vm_area_caller()
      
      On powerpc, I use __get_vm_area() to separate the ranges of addresses
      given to vmalloc vs.  ioremap (various good reasons for that) so in order
      to be able to implement the new caller tracking in /proc/vmallocinfo, I
      need a "_caller" variant of it.
      
      (akpm: needed for ongoing powerpc development, so merge it early)
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c2968612
    • Jean Pihet's avatar
      omap_hsmmc: Change while(); loops with finite version · 3ebf74b1
      Jean Pihet authored
      Replace the infinite 'while() ;' loops
      with a finite loop version.
      Signed-off-by: default avatarJean Pihet <jpihet@mvista.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      3ebf74b1
    • Jean Pihet's avatar
      omap_hsmmc: recover from transfer failures · c232f457
      Jean Pihet authored
      Timeouts during a command that has a data phase can result in the next
      command issued after the command that failed not being processed, i.e.  no
      interrupt ever occurs to indicate the command has completed.  This failure
      can result in a deadlock.
      
      This patch resets the data state machine to clear the error in case of a
      command timeout.
      
      Tested on OMAP3430 chip and intensive MMC/SD device removal while
      transferring data.
      Signed-off-by: default avatarAndy Lowe <alowe@mvista.com>
      Signed-off-by: default avatarJean Pihet <jpihet@mvista.com>
      Signed-off-by: default avatarAdrian Hunter <ext-adrian.hunter@nokia.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      c232f457
    • David Brownell's avatar
      omap_hsmmc: only MMC1 allows HCTL.SDVS != 1.8V · eb250826
      David Brownell authored
      Based on a patch from Tony Lindgren ... after initialization,
      never change HCTL.SDVS except for MMC1.  The other controller
      instances only support 1.8V in that field, although they can
      suport other card/SDIO/eMMC/... voltages with level shifting
      solutions such as external transceivers.
      
      MMC2 behavior sanity tested on Overo/WLAN, OMAP3430 SDP, and
      custom hardware.  MMC1 also sanity tested on those platforms
      plus Beagle.  This also fixes a bug preventing MMC2 (and also
      presumably MMC3) from powering down when requested.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      eb250826
    • David Brownell's avatar
      omap_hsmmc: card detect irq bugfix · 249d0fa9
      David Brownell authored
      Work around lockdep issue when card detect IRQ handlers run in
      thread context ... it forces IRQF_DISABLED, which prevents all
      access to twl4030 card detect signals.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      249d0fa9
    • Helmut Schaa's avatar
      sdhci: fix led naming · 5dbace0c
      Helmut Schaa authored
      Fix the led device naming for the sdhci driver.
      
      The led class documentation defines the led name to have the
      form "devicename:colour:function" while not applicable sections
      should be left blank.
      
      To comply with the documentation the led device name is changed
      from "mmc*" to "mmc*::".
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarPierre Ossman <drzeus@drzeus.cx>
      5dbace0c