This patch fixes 21 errors and 6 warnings reported by checkpatch.pl.
Signed-off-by: NAmeya Palande <2ameya@gmail.com>
Reviewed-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

The wl12xx device supports disconnecting the pull-up resistor on
CD/DAT[3] (pin 1) of the card.

Tell SDIO core to disconnect that resistor during card init,
since we don't need it at that point (and anyway all
hosts shall provide pull-up resistors on all data lines DAT[3:0]
as described in section 6 of the SD physical specification).

As a result, this may save some power, but it's also generally healthy
since it prevents both ends from pulling up that pin, which
results in undesirable asymmetric physical bus.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

006ebd5d introduced sdio_disable_cd(), which disconnects the pull-up
resistor on CD/DAT[3] (pin 1) of the card.

Make it possible to start using sdio_disable_cd() by introducing
MMC_QUIRK_DISABLE_CD.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Tell SDIO core to ignore the standard SDIO function interface
codes indicated by the wl1271. This is required because the
wl1271 erroneously indicates its first function as a standard
Bluetooth SDIO interface, and that drives btsdio mad.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Introduce MMC_QUIRK_NONSTD_FUNC_IF to ignore the "SDIO Standard Function
interface code" as indicated by the card's FBR, and instead treat all
functions as non-standard interfaces.

This is required to prevent standard drivers from facing
errors when trying to communicate with SDIO cards that erroneously
indicate standard function interface codes.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

6b5eda36 followed SDIO spec part E1 section 8, which states that
in case SDIO interrupts are being used to wake up a suspended host,
then it is required to switch to 1-bit mode before stopping the clock.

Before switching to 1-bit mode (or back to 4-bit mode on resume),
make sure that SDIO interrupts are really being used to wake the host.

This is helpful for devices which have an external irq line (e.g.
wl1271), and do not use SDIO interrupts to wake up the host.

In this case, switching to 1-bit mode (and back to 4-bit mode on resume)
is not necessary.
Reported-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

mmc_card_is_powered_resumed is a mouthful; instead, simply use
mmc_card_keep_power, which also better explains the purpose of
the macro.

Employ mmc_card_keep_power() where possible.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Allows reliable writes to be used for MMC writes. Reliable writes are used
to service write REQ_FUA/REQ_META requests. Handles both the legacy and
the enhanced reliable write support in MMC cards.
Signed-off-by: NAndrei Warkentin <andreiw@motorola.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

This config option is used to decide whether tegra sdhci support
should be build into the sdhci-platform module.  So setting it 'm'
is nonsense, since we can't build part of an module as a module.
The effect for 'm' will probably be the same as for 'n'.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.

This patch allows the mach-tegra support to tell the tegra MMC host
controller to NOT turn off power for the MMC controller the WIFI part
lives behind.  Thus bcm4329 firmware doesn't need to be reloaded.
Signed-off-by: NVenkat Rao <vrao@broadcom.com>
Tested-by: NGrant Grundler <grundler@chromium.org>
Reviewed-by: NOlof Johansson <olof@lixom.net>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NChris Ball <cjb@laptop.org>

There is no need to disable irq's when using the sg_copy_*_buffer()
functions because those functions do that already. There are also
no races for the mm_queue struct here that would require the irq's
to be disabled before calling sg_copy_*_buffer().
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

uBoot sometimes leaves eMMC pointing to the private boot partition.
Ensure we always start looking at the user partition.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NBruce Clemens <bpclemens@marvell.com>
Signed-off-by: NMark F. Brown <markb@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.

Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:

[   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[   17.772458] Hardware name: Latitude E6400
[   17.772460] Modules linked in: ....
[   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
[   17.772584] Call Trace:
[   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
[   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: NFrederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

My Q67 / i7-2600 box has rev09 Sandy Bridge graphics.  It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work.  Setting i915.semaphore=0 fixes it.

Semaphores were disabled in a1656b90
in 2.6.38 and were re-enabled by

commit 47ae63e0
Merge: c59a333f 467cffba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 7 12:32:44 2011 +0000

    Merge branch 'drm-intel-fixes' into drm-intel-next

    Apply the trivial conflicting regression fixes, but keep GPU semaphores
    enabled.

    Conflicts:
        drivers/gpu/drm/i915/i915_drv.h
        drivers/gpu/drm/i915/i915_gem_execbuffer.c

(It's worth noting that the offending change is i915_drv.c,
 which is not a conflict.)
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Acked-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the requested device is already active, ignore the request.

This restores the original behaviour of the interface. The change was
probably an unintended side effect of

commit 66b37c67 vga_switcheroo: split switching into two stages

which did not take into account to duplicate the !active check in the split-off
stage2.

Fix this by factoring that check out of stage1 into the debugfs_write routine.

References: https://bugzilla.kernel.org/show_bug.cgi?id=34252Reported-by: NIgor Murzov <e-mail@date.by>
Tested-by: NIgor Murzov <e-mail@date.by>
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

ae01b249 (libata: Implement ATA_FLAG_NO_DIPM and apply it to mcp65)
added ATA_FLAG_NO_DIPM and made ata_eh_set_lpm() check the flag.
However, @ap is NULL if @link points to a PMP link and thus the
unconditional @ap->flags dereference leads to the following oops.

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
  IP: [<ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
  ...
  Pid: 295, comm: scsi_eh_4 Tainted: P            2.6.38.5-core2 #1 System76, Inc. Serval Professional/Serval Professional
  RIP: 0010:[<ffffffff813f98e1>]  [<ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
  RSP: 0018:ffff880132defbf0  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff880132f40000 RCX: 0000000000000000
  RDX: ffff88013377c000 RSI: ffff880132f40000 RDI: 0000000000000000
  RBP: ffff880132defce0 R08: ffff88013377dc58 R09: ffff880132defd98
  R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000
  R13: 0000000000000000 R14: ffff88013377c000 R15: 0000000000000000
  FS:  0000000000000000(0000) GS:ffff8800bf700000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 0000000000000018 CR3: 0000000001a03000 CR4: 00000000000406e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process scsi_eh_4 (pid: 295, threadinfo ffff880132dee000, task ffff880133b416c0)
  Stack:
   0000000000000000 ffff880132defcc0 0000000000000000 ffff880132f42738
   ffffffff813ee8f0 ffffffff813eefe0 ffff880132defd98 ffff88013377f190
   ffffffffa00b3e30 ffffffff813ef030 0000000032defc60 ffff880100000000
  Call Trace:
   [<ffffffff81400867>] sata_pmp_error_handler+0x607/0xc30
   [<ffffffffa00b273f>] ahci_error_handler+0x1f/0x70 [libahci]
   [<ffffffff813faade>] ata_scsi_error+0x5be/0x900
   [<ffffffff813cf724>] scsi_error_handler+0x124/0x650
   [<ffffffff810834b6>] kthread+0x96/0xa0
   [<ffffffff8100cd64>] kernel_thread_helper+0x4/0x10
  Code: 8b 95 70 ff ff ff b8 00 00 00 00 48 3b 9a 10 2e 00 00 48 0f 44 c2 48 89 85 70 ff ff ff 48 8b 8d 70 ff ff ff f6 83 69 02 00 00 01 <48> 8b 41 18 0f 85 48 01 00 00 48 85 c9 74 12 48 8b 51 08 48 83
  RIP  [<ffffffff813f98e1>] ata_eh_recover+0x9a1/0x1510
   RSP <ffff880132defbf0>
  CR2: 0000000000000018

Fix it by testing @link->ap->flags instead.

stable: ATA_FLAG_NO_DIPM was added during 2.6.39 cycle but was
        backported to 2.6.37 and 38.  This is a fix for that and thus
        also applicable to 2.6.37 and 38.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: N"Nathan A. Mourey II" <nmoureyii@ne.rr.com>
LKML-Reference: <1304555277.2059.2.camel@localhost.localdomain>
Cc: Connor H <cmdkhh@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

This reverts commit 270dac35.

The commits causes command timeouts on AC plug/unplug.  It isn't yet
clear why.  As the commit was for a single rather obscure controller,
revert the change for now.

The problem was reported and bisected by Gu Rui in bug#34692.

 https://bugzilla.kernel.org/show_bug.cgi?id=34692

Also, reported by Rafael and Michael in the following thread.

 http://thread.gmane.org/gmane.linux.kernel/1138771Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NGu Rui <chaos.proton@gmail.com>
Reported-by: NRafael J. Wysocki <rjw@sisk.pl>
Reported-by: NMichael Leun <lkml20100708@newton.leun.net>
Cc: Jian Peng <jipeng2005@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This moves the

    if (num_registered_fb == FB_MAX)
            return -ENXIO;

check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
would (now in a safe way) allow a native driver to replace the
conflicting one even if all slots in registered_fb[] are taken.

This also prevents unregistering a framebuffer that is no longer
registered (vga16f will unregister at module unload time even if the
frame buffer had been unregistered earlier due to being found
conflicting).
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation.  And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.

In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.

So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.

It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The rbd driver currently splits bios when they span an object boundary.
However, the blk_end_request expects the completions to roll up the results
in block device order, and the split rbd/ceph ops can complete in any
order.  This patch adds a struct rbd_req_coll to track completion of split
requests and ensures that the results are passed back up to the block layer
in order.

This fixes errors where the file system gets completion of a read operation
that spans an object boundary before the data has actually arrived.  The
bug is easily reproduced with iozone with a working set larger than
available RAM.
Reported-by: NFyodor Ustinov <ufm@ufm.su>
Signed-off-by: NYehuda Sadeh <yehuda@hq.newdream.net>
Signed-off-by: NSage Weil <sage@newdream.net>

My Q67 / i7-2600 box has rev09 Sandy Bridge graphics.  It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work.  Setting i915.semaphore=0 fixes it.

Semaphores were disabled in a1656b90 ("drm/i915: Disable GPU
semaphores by default") in 2.6.38 but were then re-enabled (by mistake?)
by the merge 47ae63e0 ("Merge branch 'drm-intel-fixes' into
drm-intel-next").

(It's worth noting that the offending change is i915_drv.c, which was
not marked as a conflict - although a 'git show --cc' on the merge does
show that neither parent had it set to 1)
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With some combinations of arch/compiler (e.g. arm-linux-gcc) the sizeof
operator on structure returns value greater than expected. In cases when the
structure is used for mapping PDU fields it may lead to unexpected results
(such as holes and alignment problems in skb data). __packed prevents this
undesired behavior.
Signed-off-by: NVitalii Demianets <vitas@nppfactor.kiev.ua>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

need to programmed from the userspace drivers.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On rev <= 1.1 tables, the offset is absolute,
on newer tables, it's relative.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=700326Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

The location of MC_ARB_RAMCFG changed on fusion.
I've diffed all the other regs in evergreend.h and this
is the only other reg that changed.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The ops vector must be freed by the rbd_do_request caller.
Signed-off-by: NSage Weil <sage@newdream.net>

alg_data is already a pointer which must be passed directly.
Reported-by: NDieter Ripp <ripp@systecnet.com>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ben Dooks <ben-i2c@fluff.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Changeset dcd39c90 ("ne-h8300: convert to
net_device_ops") broke ne-h8300 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in ne-h8300.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.

Fix based on commits 217cbfa8 ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa ("mac8390: fix build with
NET_POLL_CONTROLLER").
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Changeset 5618f0d1 ("hydra: convert to
net_device_ops") broke hydra by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in hydra.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.

Fix based on commits 217cbfa8 ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa ("mac8390: fix build with
NET_POLL_CONTROLLER").
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Changeset b6114794 ("zorro8390: convert to
net_device_ops") broke zorro8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in zorro8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.

Fix based on commits 217cbfa8 ("mac8390:
fix regression caused during net_device_ops conversion") and
4e0168fa ("mac8390: fix build with
NET_POLL_CONTROLLER").
Reported-by: NChristian T. Steigies <cts@debian.org>
Suggested-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Tested-by: NChristian T. Steigies <cts@debian.org>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 49183b28.

Quoth Franz Melchior:

  "This patch introduces a bug on my infamous "Acer Travelmate
   5735Z-452G32Mnss": when KMS takes over, the frame buffer contents get
   completely garbled up on screen, with colored stripes and unreadable
   text (photo on request).  Only when X11 is started, the screen gets
   restored again.  Closing and re-opening the lid partly cures the
   mess, too: it makes the font readable, though horizontally stretched."
Acked-by: NKeith Packard <keithp@keithp.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

read/write/ioctl on a fbcon file descriptor has traditionally used the
fbcon not when it was opened, but as it was at the time of the call.
That makes no sense, but the lack of sense is much more obvious now that
we properly ref-count the usage - it means that the ref-counting doesn't
actually protect operations we do on the frame buffer.

This changes it to look at the fb_info that we got at open time, but in
order to avoid using a frame buffer long after it has been unregistered,
we do verify that it is still current, and return -ENODEV if not.
Acked-by: NTim Gardner <tim.gardner@canonical.com>
Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This just adds the refcount and the new registration lock logic.  It
does not (for example) actually change the read/write/ioctl routines to
actually use the frame buffer that was opened: those function still end
up alway susing whatever the current frame buffer is at the time of the
call.

Without this, if something holds the frame buffer open over a
framebuffer switch, the close() operation after the switch will access a
fb_info that has been free'd by the unregistering of the old frame
buffer.

(The read/write/ioctl operations will normally not cause problems,
because they will - illogically - pick up the new fbcon instead.  But a
switch that happens just as one of those is going on might see problems
too, the window is just much smaller: one individual op rather than the
whole open-close sequence.)

This use-after-free is apparently fairly easily triggered by the Ubuntu
11.04 boot sequence.
Acked-by: NTim Gardner <tim.gardner@canonical.com>
Tested-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Tested-by: NAnca Emanuel <anca.emanuel@gmail.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We enabled write-combining for memory-mapped registers in commit
65f0b417, but inhibited it for the
MCDI shared memory where this is not supported.  However,
write-combining mappings also allow read-reordering, which may also
be a problem.

I found that when an SFC9000-family controller is connected to an
Intel 3000 chipset, and write-combining is enabled, the controller
stops responding to PCIe read requests during driver initialisation
while the driver is polling for completion of an MCDI command.  This
results in an NMI and system hang.  Adding read memory barriers
between all reads to the shared memory area appears to reduce but not
eliminate the probability of this.

We have not yet established whether this is a bug in our BIU or in the
PCIe bridge.  For now, work around by mapping the shared memory area
separately.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>

The ehea driver oopses during memory hotplug if the ports are not
up. A simple testcase:

# ifconfig ethX down
# echo offline > /sys/devices/system/memory/memory32/state

Oops: Kernel access of bad area, sig: 11 [#1]
last sysfs file: /sys/devices/system/memory/memory32/state
REGS: c000000709393110 TRAP: 0300   Not tainted  (2.6.39-rc2-01385-g7ef73bca-dirty)
DAR: 0000000000000000, DSISR: 40000000
...
NIP [c000000000067c98] .__wake_up_common+0x48/0xf0
LR [c00000000006d034] .__wake_up+0x54/0x90
Call Trace:
[c00000000006d034] .__wake_up+0x54/0x90
[d000000006bb6270] .ehea_rereg_mrs+0x140/0x730 [ehea]
[d000000006bb69c4] .ehea_mem_notifier+0x164/0x170 [ehea]
[c0000000006fc8a8] .notifier_call_chain+0x78/0xf0
[c0000000000b3d70] .__blocking_notifier_call_chain+0x70/0xb0
[c000000000458d78] .memory_notify+0x28/0x40
[c0000000001871d8] .remove_memory+0x208/0x6d0
[c000000000458264] .memory_section_action+0x94/0x140
[c0000000004583ec] .memory_block_change_state+0xdc/0x1d0
[c0000000004585cc] .store_mem_state+0xec/0x160
[c00000000044768c] .sysdev_store+0x3c/0x50
[c00000000020b48c] .sysfs_write_file+0xec/0x1f0
[c00000000018f86c] .vfs_write+0xec/0x1e0
[c00000000018fa88] .SyS_write+0x58/0xd0

To fix this, initialise the waitqueues during port probe instead
of port open.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: stable@kernel.org
Acked-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The driver is not balancing set_irq and disable_irq_wake() calls, so
ensure that it keeps track of whether the wake is enabled.

The fixes the following error on S3C6410 devices:

  WARNING: at kernel/irq/manage.c:382 set_irq_wake+0x84/0xec()
  Unbalanced IRQ 92 wake disable
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Only configure sleep script when the flag is TWL4030_SLEEP_SCRIPT.

Adding the missing brackets for fixing the issue.
Signed-off-by: NLesly A M <leslyam@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: David Derrick <dderrick@ti.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Fix below compile error:

  CC      drivers/mfd/asic3.o
drivers/mfd/asic3.c: In function 'asic3_irq_demux':
drivers/mfd/asic3.c:147: error: 'irq_data' undeclared (first use in this function)
drivers/mfd/asic3.c:147: error: (Each undeclared identifier is reported only once
drivers/mfd/asic3.c:147: error: for each function it appears in.)
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

With commit 19403165 a main part of ehci-omap.c moved to
drivers/mfd/omap-usb-host.c created by commit 17cdd29d.
Due to this reorganisation the polarity used to reset the
external USB phy changed and USB host doesn't recognize
any devices.
Signed-off-by: NJuergen Kilb <J.Kilb@phytec.de>
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The Xen changes were using DMA_ERROR_CODE which isn't defined on a few
platforms, however we reverted the Xen patch that caused use to try and
use this code path earlier in 2.6.39 cycle, so for now lets just force
the code to never take this path and allow it to build again on alpha.

The proper long term answer is probably to store if the dma_addr has
been assigned to alongside the dma_addr in the higher level code,
though I think Thomas wanted to rewrite most of this anyways properly.
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>