If the driver didn't set this parameter on the ETHER, the CPU will
encounter the "data address error" exception.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When link was down, the bit of DM in ECMR was always set.
So, we could not use half-duplex mode on the controller.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the rx ring is completely empty, then the device may never fire an rx
interrupt. Unfortunately, the rx interrupt is what triggers populating the
rx ring with fresh buffers, so this will cause networking to lock up.

This patch replenishes the skb in recv descriptor as soon as it is
peeled off while processing rx completions. If the skb/buffer
allocation fails, existing one is recycled and the packet in hand is
dropped. This way none of the RX desc is ever left empty, thus avoiding
starvation
Signed-off-by: NScott J. Goldman <scottjg@vmware.com>
Signed-off-by: NShreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MAC address was set using the signed char sockaddr->sa_addr
field and thus the address could be corrupted through sign extension.
Signed-off-by: NKristoffer Glembo <kristoffer@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This silences dma-debug warnings:

https://lkml.org/lkml/2011/6/30/341

------------[ cut here ]------------
WARNING: at /home/jimc/projects/lx/linux-2.6/lib/dma-debug.c:820
check_unmap+0x1fe/0x56a()
natsemi 0000:00:06.0: DMA-API: device driver frees DMA memory with
different size [device address=0x0000000006ef0040] [map size=1538
bytes] [unmap size=1522 bytes]
Modules linked in: pc8736x_gpio pc87360 hwmon_vid scx200_gpio nsc_gpio
scx200_hrt scx200_acb i2c_core arc4 rtl8180 mac80211 eeprom_93cx6
cfg80211 pcspkr rfkill scx200 ide_gd_mod ide_pci_generic ohci_hcd
usbcore sc1200 ide_core
Pid: 870, comm: collector Not tainted 3.0.0-rc5-sk-00080-gca56a95e #1
Call Trace:
 [<c011a556>] warn_slowpath_common+0x4a/0x5f
 [<c02565cb>] ? check_unmap+0x1fe/0x56a
 [<c011a5cf>] warn_slowpath_fmt+0x26/0x2a
 [<c02565cb>] check_unmap+0x1fe/0x56a
 [<c0256aaa>] debug_dma_unmap_page+0x53/0x5b
 [<c029d6cd>] pci_unmap_single+0x4d/0x57
 [<c029ea0a>] natsemi_poll+0x343/0x5ca
 [<c0116f41>] ? try_to_wake_up+0xea/0xfc
 [<c0122416>] ? spin_unlock_irq.clone.28+0x18/0x23
 [<c02d4667>] net_rx_action+0x3f/0xe5
 [<c011e35e>] __do_softirq+0x5b/0xd1
 [<c011e303>] ? local_bh_enable+0xa/0xa
 <IRQ>  [<c011e54b>] ? irq_exit+0x34/0x75
 [<c01034b9>] ? do_IRQ+0x66/0x79
 [<c034e869>] ? common_interrupt+0x29/0x30
 [<c0115ed0>] ? finish_task_switch.clone.118+0x31/0x72
 [<c034cb92>] ? schedule+0x3b2/0x3f1
 [<c012f4b0>] ? hrtimer_start_range_ns+0x10/0x12
 [<c012f4ce>] ? hrtimer_start_expires+0x1c/0x24
 [<c034d5aa>] ? schedule_hrtimeout_range_clock+0x8e/0xb4
 [<c012ed27>] ? update_rmtp+0x68/0x68
 [<c034d5da>] ? schedule_hrtimeout_range+0xa/0xc
 [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
 [<c017b051>] ? do_select+0x488/0x4cd
 [<c0115ee2>] ? finish_task_switch.clone.118+0x43/0x72
 [<c01157ad>] ? need_resched+0x14/0x1e
 [<c017a99e>] ? poll_freewait+0x74/0x74
 [<c01157ad>] ? need_resched+0x14/0x1e
 [<c034cbc1>] ? schedule+0x3e1/0x3f1
 [<c011e55e>] ? irq_exit+0x47/0x75
 [<c01157ad>] ? need_resched+0x14/0x1e
 [<c034cf8a>] ? preempt_schedule_irq+0x44/0x4a
 [<c034dd1e>] ? need_resched+0x17/0x19
 [<c024bc12>] ? put_dec_full+0x7b/0xaa
 [<c0240060>] ? blkdev_ioctl+0x434/0x618
 [<c024bc70>] ? put_dec+0x2f/0x6d
 [<c024c6a5>] ? number.clone.1+0x10b/0x1d0
 [<c034cf8a>] ? preempt_schedule_irq+0x44/0x4a
 [<c034dd1e>] ? need_resched+0x17/0x19
 [<c024d046>] ? vsnprintf+0x225/0x264
 [<c024cea0>] ? vsnprintf+0x7f/0x264
 [<c018346f>] ? seq_printf+0x22/0x40
 [<c01a2fcc>] ? do_task_stat+0x582/0x5a3
 [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
 [<c017b1b5>] ? core_sys_select+0x11f/0x1a3
 [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
 [<c01a34a1>] ? proc_tgid_stat+0xd/0xf
 [<c012357c>] ? recalc_sigpending+0x32/0x35
 [<c0123b9c>] ? __set_task_blocked+0x64/0x6a
 [<c011dfb0>] ? timespec_add_safe+0x24/0x48
 [<c0123449>] ? spin_unlock_irq.clone.16+0x18/0x23
 [<c017b3a1>] ? sys_pselect6+0xe5/0x13e
 [<c034dd65>] ? syscall_call+0x7/0xb
 [<c0340000>] ? rpc_clntdir_depopulate+0x26/0x30
---[ end trace 180dcac41a50938b ]---
Reported-by: NJim Cromie <jim.cromie@gmail.com>
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Tested-by: NJim Cromie <jim.cromie@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Offload setting of vlan device requires
vlan_features to be initialized.
Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

request_threaded irq will call kzalloc that can sleep. Initializing the flags variable outside of spin_lock_irqsave/restore in bnad_mbox_irq_alloc will avoid call traces like below.

Jun 27 08:15:24 home-t710 kernel: [11735.634550] Brocade 10G Ethernet driver
Jun 27 08:15:24 home-t710 kernel: [11735.634590] bnad_pci_probe : (0xffff880427f3d000, 0xffffffffa020f3e0) PCI Func : (2)
Jun 27 08:15:24 home-t710 kernel: [11735.637677] bna 0000:82:00.2: PCI INT A -> GSI 66 (level, low) -> IRQ 66
Jun 27 08:15:24 home-t710 kernel: [11735.638290] bar0 mapped to ffffc90014980000, len 262144
Jun 27 08:15:24 home-t710 kernel: [11735.638732] BUG: sleeping function called from invalid context at mm/slub.c:847
Jun 27 08:15:24 home-t710 kernel: [11735.638736] in_atomic(): 0, irqs_disabled(): 1, pid: 11243, name: insmod
Jun 27 08:15:24 home-t710 kernel: [11735.638740] Pid: 11243, comm: insmod Not tainted 3.0.0-rc4+ #6
Jun 27 08:15:24 home-t710 kernel: [11735.638743] Call Trace:
Jun 27 08:15:24 home-t710 kernel: [11735.638755]  [<ffffffff81046427>] __might_sleep+0xeb/0xf0
Jun 27 08:15:24 home-t710 kernel: [11735.638766]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638773]  [<ffffffff8111201c>] kmem_cache_alloc_trace+0x43/0xd8
Jun 27 08:15:24 home-t710 kernel: [11735.638782]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638787]  [<ffffffff810ab791>] request_threaded_irq+0xa1/0x113
Jun 27 08:15:24 home-t710 kernel: [11735.638798]  [<ffffffffa020f0c0>] bnad_pci_probe+0x612/0x8e5 [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638807]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638816]  [<ffffffff81482ef4>] ? _raw_spin_unlock_irqrestore+0x17/0x19
Jun 27 08:15:24 home-t710 kernel: [11735.638822]  [<ffffffff8124d17a>] local_pci_probe+0x44/0x75
Jun 27 08:15:24 home-t710 kernel: [11735.638826]  [<ffffffff8124dc06>] pci_device_probe+0xd0/0xff
Jun 27 08:15:24 home-t710 kernel: [11735.638832]  [<ffffffff812ef8ab>] driver_probe_device+0x131/0x213
Jun 27 08:15:24 home-t710 kernel: [11735.638836]  [<ffffffff812ef9e7>] __driver_attach+0x5a/0x7e
Jun 27 08:15:24 home-t710 kernel: [11735.638840]  [<ffffffff812ef98d>] ? driver_probe_device+0x213/0x213
Jun 27 08:15:24 home-t710 kernel: [11735.638844]  [<ffffffff812ee933>] bus_for_each_dev+0x53/0x89
Jun 27 08:15:24 home-t710 kernel: [11735.638848]  [<ffffffff812ef48a>] driver_attach+0x1e/0x20
Jun 27 08:15:24 home-t710 kernel: [11735.638852]  [<ffffffff812ef0ae>] bus_add_driver+0xd1/0x224
Jun 27 08:15:24 home-t710 kernel: [11735.638858]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
Jun 27 08:15:24 home-t710 kernel: [11735.638862]  [<ffffffff812efe57>] driver_register+0x98/0x105
Jun 27 08:15:24 home-t710 kernel: [11735.638866]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
Jun 27 08:15:24 home-t710 kernel: [11735.638871]  [<ffffffff8124e4c9>] __pci_register_driver+0x56/0xc1
Jun 27 08:15:24 home-t710 kernel: [11735.638875]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
Jun 27 08:15:24 home-t710 kernel: [11735.638884]  [<ffffffffa01b8040>] bnad_module_init+0x40/0x60 [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638892]  [<ffffffff81002099>] do_one_initcall+0x7f/0x136
Jun 27 08:15:24 home-t710 kernel: [11735.638899]  [<ffffffff8108608b>] sys_init_module+0x88/0x1d0
Jun 27 08:15:24 home-t710 kernel: [11735.638906]  [<ffffffff81489682>] system_call_fastpath+0x16/0x1b
Jun 27 08:15:24 home-t710 kernel: [11735.639642] bnad_pci_probe : (0xffff880427f3e000, 0xffffffffa020f3e0) PCI Func : (3)
Jun 27 08:15:24 home-t710 kernel: [11735.639665] bna 0000:82:00.3: PCI INT A -> GSI 66 (level, low) -> IRQ 66
Jun 27 08:15:24 home-t710 kernel: [11735.639735] bar0 mapped to ffffc90014400000, len 262144
Signed-off-by: NShyam Iyer <shyam_iyer@dell.com>
Acked-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Precedence of the printk should be at higher level so chip fatal
errors are always reported.
Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When we are in a recover process from a chip fatal error,
	driver should skip over execution of mailbox commands during
	resetting chip.
Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Lockdep found a locking inconsistency in the mkiss_close function:

> kernel: [ INFO: inconsistent lock state ]
> kernel: 2.6.39.1 #3
> kernel: ---------------------------------
> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> kernel: {IN-SOFTIRQ-R} state was registered at:

The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock. 
The same problem is present in the 6pack driver, this patch fixes both
by using write_lock_bh instead of write_lock.
Reported-by: NBernard F6BVP <f6bvp@free.fr>
Tested-by: NBernard F6BVP <f6bvp@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: Ralf Baechle<ralf@linux-mips.org>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The vbios rom is >64k on a lot of modern asics.  Increase
the fetch size for atrm to make sure we don't miss part
of a larger rom.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

setkey allocates 16 bytes (CAAM_CMD_SZ *
DESC_AEAD_SHARED_TEXT_LEN) shy of what is needed to
store the shared descriptor, resulting in memory
corruption.  Fix this.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We would free the proper number of curves, but in the wrong
slots, due to a missing level of indirection through
the pdgain_idx table.

It's simpler just to try to free all four slots, so do that.

Cc: stable@kernel.org
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It's not so much an error as a warning about normal Marvell crazines.
So don't use KERN_ERR that ends up spamming the console even in quiet
mode, it's not _that_ critical.

Explained by Jeff:

 "Long explanation, it's a mess:

  Marvell took standard AHCI, and bastardized it to include a weird mode
  whereby PATA devices appear inside the AHCI DMA and interrupt
  infrastructure you're familiar with.

  So, PATA devices appear via pata_marvell driver, using basic legacy
  IDE programming interface.  But SATA devices, which might also be
  attached to this chip, either work in under-performing mode or
  simply don't work at all (e.g.  newer 6 Gbps devices or port
  multiplier attachments, NCQ, ...)

  On the other hand, 'ahci' driver loads and works with the chip's
  attached SATA devices quite beautifully, but is completely unable to
  drive any attached PATA devices, due to the Marvell-specific
  PATA-under-AHCI interface.

  The "masking port_map 0x7 -> 0x3" message is the ahci driver "hiding"
  the PATA port(s) from itself, making sure it will only drive the SATA
  ports it knows how to drive."
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This module and a bunch of dependancies are getting loaded on several
of laptops I have (probably picking up the mobile broadband device),
that have nothing to do with zaurus. Matching by class without
any vendor/device pair isn't the right thing to do here, as it
will prevent any other driver from correctly binding to it.
(Or in the absense of a driver, will just waste time & memory by
 unnecessarily loading modules)
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The two options "CAN bit-timing calculation" and
"Platform CAN drivers with Netlink support" have a "default Y". In order to
activate them by default, change to "default y".
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function rionet_remove initializes local variable 'ndev' to NULL
and do nothing changes before the call to unregister_netdev(ndev),
this could cause a NULL pointer dereference.
Reported-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NYinglin Luan <synmyth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are 64K and result in order-4 allocations, even with SLUB.

Therefore, just like we always have for the deflate buffers, use
vmalloc.
Reported-by: NMartin Jackson <mjackson220.list@gmail.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

pca954x power-on default is channel 0 connected. If multiple pca954x
muxes are connected to the same physical I2C bus, the parent bus will
see channel 0 devices behind both muxes by default. This is bad.

Scenario:
            -- pca954x @ 0x70 -- ch 0 (I2C-bus-101) -- EEPROM @ 0x50
            |
I2C-bus-1 ---
            |
            -- pca954x @ 0x71 -- ch 0 (I2C-bus-111) -- EEPROM @ 0x50

1. Load I2C bus driver: creates I2C-bus-1
2. Load pca954x driver: creates virtual I2C-bus-101 and I2C-bus-111
3. Load eeprom driver
4. Try to read EEPROM @ 0x50 on I2C-bus-101. The transaction will also bleed
   onto I2C-bus-111 because pca954x @ 0x71 channel 0 is connected by default.

Fix: Initialize pca954x to disconnected state in pca954x_probe()
Signed-off-by: NPetri Gynther <pgynther@google.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org

* Print all error and information messages even when debugging is
  disabled.
* Don't use adapter device to log messages before it is ready.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org

This patch updates the email address of the at32ap700x_wdt driver supported by
me to an email account I will use on a more regular basis in the future.
Signed-off-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Konstantin Belousov pointed out that 4697995b replaced the generic
i915_driver_irq_*install() functions with chipset specific routines
accessible only through driver->irq_*install(). So update the sanity
check in i915_request_wait() to match.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The failure is as follows:

1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect

The failure can only occur when using the forcewake userspace lock.

This has the unfortunate consequence of messing up the driver as well as
userspace, unless userspace closes the debugfs file, the kernel will
never end up waking the GT since the refcount will be > 1.

The solution is to try to recover the correct forcewake state based on
the refcount. There is a period of time where userspace reads/writes may
occur after the reset, before the GT has been forcewaked. The interface
was never designed to be a perfect solution for userspace reads/writes,
and the kernel portion is fixed by this patch.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

"iwlagn: map command buffers BIDI" uses the DMA_* enumerations for DMA
directions, even though the pci_* DMA API is still in use.  That patch
was undoubtedly developed on top of "iwlagn: don't use the PCI wrappers
for DMA operation", which is due in the next release.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the space between "platform:" prefix and the driver name.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NMartyn Welch <martyn.welch@ge.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Trying to build the Intel SCU Watchdog fails for me with gcc 4.6.0 -
$ gcc --version | head -n 1
gcc (GCC) 4.6.0 20110513 (prerelease)

like this :
  CC      drivers/watchdog/intel_scu_watchdog.o
In file included from drivers/watchdog/intel_scu_watchdog.c:49:0:
/home/jj/src/linux-2.6/arch/x86/include/asm/apb_timer.h: In function ‘apbt_time_init’:
/home/jj/src/linux-2.6/arch/x86/include/asm/apb_timer.h:65:42: warning: ‘return’ with a value, in function returning void [enabled by default]
drivers/watchdog/intel_scu_watchdog.c: In function ‘intel_scu_watchdog_init’:
drivers/watchdog/intel_scu_watchdog.c:468:2: error: implicit declaration of function ‘sfi_get_mtmr’ [-Werror=implicit-function-declaration]
drivers/watchdog/intel_scu_watchdog.c:468:32: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors

make[1]: *** [drivers/watchdog/intel_scu_watchdog.o] Error 1
make: *** [drivers/watchdog/intel_scu_watchdog.o] Error 2

Additionally, linux/types.h is needlessly being included twice in 
drivers/watchdog/intel_scu_watchdog.c
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Fix section mismatch and remove unused variable 'tmp'.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Commit e391be76 (MIPS: Alchemy: Clean up GPIO registers and accessors)
changed the way the GPIO was toggled. Prior to this patch, we would
always actively drive the GPIO output to either 0 or 1, this patch
drove the GPIO active to 0, and put the GPIO in tristate to drive it
to 1, unfortunately this does not work, revert back to active driving.

Using a signed variable (gstate) to hold the gpio state and using a bit-
wise operation on it also resulted in toggling value from 1 to -2 since
the variable is signed. This value was then passed on to gpio_direction_
output, which always perform a if (value) ... to set the value to the
gpio, so we were always writing a 1 to this GPIO instead of 1 -> 0 -> 1 ...
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

Otherwise, the gpiolib autorequest feature will produce a WARN_ON():

WARNING: at drivers/gpio/gpiolib.c:101 0x8020ec6c()
autorequest GPIO-215
[...]
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

Due to the whole single instance based watchdog API we use static data
for the wm831x watchdog which means that if the system tries to register
a second one we end up trying to register the same miscdevice again,
corrupting the miscdevice list. Work around this by checking for duplicate
registrations until we get a watchdog core.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

If a device fails in a way that causes pending request to take a while
to complete, md will not be able to immediately remove it from the
array in remove_and_add_spares.
It will then incorrectly look like a spare device and md will try to
recover it even though it is failed.
This leads to a recovery process starting and instantly aborting over
and over again.

We should check if the device is faulty before considering it to be a
spare.  This will avoid trying to start a recovery that cannot
proceed.

This bug was introduced in 2.6.26 so that patch is suitable for any
kernel since then.

Cc: stable@kernel.org
Reported-by: NJim Paradis <james.paradis@stratus.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

When auditing the locking in i915_gem.c (for a prospective change which
I then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it.

Since one is in initial setup and the other in driver unload, I'm
guessing the mutex is not required for either; but post a patch in case
it is.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The interface to ->truncate_range is changing very slightly: once "tmpfs:
take control of its truncate_range" has been applied, this can be applied.
 For now there is only a slight inefficiency while this remains unapplied,
but it will soon become essential for managing shmem's use of swap.

Change i915_gem_object_truncate() to use shmem_truncate_range() directly:
which should also spare i915 later change if we switch from
inode_operations->truncate_range to file_operations->fallocate.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.

Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in
the one place it's needed; elsewhere use shmem_read_mapping_page(), with
the mapping's gfp_mask properly initialized.

Forget about __GFP_COLD: since tmpfs initializes its pages with memset,
asking for a cold page is counter-productive.

Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now
declared there too, we shall remove the prototype from linux/mm.h later.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Soon tmpfs will stop supporting ->readpage and read_mapping_page(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.

ttm_tt_swapin() and ttm_tt_swapout() use shmem_read_mapping_page() in
place of read_mapping_page(), since their swap_space has been created with
shmem_file_setup().
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fis the warning

  drivers/tty/serial/8250_pci.c:1457: warning: initialization from incompatible pointer type

Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this section mismatch:

  WARNING: drivers/misc/ioc4.o(.data+0x144): Section mismatch in reference from the variable ioc4_load_modules_work to the function .devinit.text:ioc4_load_modules()
  The variable ioc4_load_modules_work references
  the function __devinit ioc4_load_modules()
  If the reference is valid then annotate the
  variable with __init* or __refdata (see linux/init.h) or name the variable:
  *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

This one is potentially fatal; by the time ioc4_load_modules is invoked
it may already have been freed.  For that reason ioc4_load_modules_work
can't be turned to __devinitdata but also because it's referenced in
ioc4_exit.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Acked-by: NBrent Casavant <bcasavan@sgi.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this section mismatch:

  WARNING: drivers/leds/leds-lp5523.o(.text+0x12f4): Section mismatch in reference from the function lp5523_probe() to the function .init.text:lp5523_init_led()
  The function lp5523_probe() references
  the function __init lp5523_init_led().
  This is often because lp5523_probe lacks a __init
  annotation or the annotation of lp5523_init_led is wrong.

Fixing this one triggers one more mismatch, fix that one as well.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>