Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35135
BUG: unable to handle kernel NULL pointer dereference at 000002d8
IP: [<f83694af>] nv04_dfp_restore+0x7f/0xd0 [nouveau]
(...)
Call Trace:
 [<f8372208>] nv04_display_destroy+0xa8/0x140 [nouveau]
 [<f830344a>] nouveau_unload+0x2a/0x160 [nouveau]
 [<f80d98fb>] drm_put_dev+0xbb/0x1b0 [drm]
 [<f8301025>] nouveau_pci_remove+0x15/0x20 [nouveau]
 [<c1292ad4>] pci_device_remove+0x44/0xf0
 [<c13339d1>] __device_release_driver+0x51/0xb0
 [<c133401f>] driver_detach+0x8f/0xa0
 [<c13338a3>] bus_remove_driver+0x63/0xa0
 [<c13340a9>] driver_unregister+0x49/0x80
 [<c1182f84>] ? sysfs_remove_file+0x14/0x20
 [<c1292bb2>] pci_unregister_driver+0x32/0x90
 [<c109b1da>] ? __stop_machine+0x5a/0x70
 [<f80d3f93>] drm_exit+0x83/0x90 [drm]
 [<f837875d>] nouveau_exit+0x1b/0x8be [nouveau]
 [<c1087b5b>] sys_delete_module+0x13b/0x1f0
 [<c1104c3e>] ? do_munmap+0x1fe/0x280
 [<c1104780>] ? arch_unmap_area_topdown+0x0/0x20
 [<c15096f4>] syscall_call+0x7/0xb
Reported-by: NFrancesco Marella <francesco.marella@gmail.com>
Tested-by: NFrancesco Marella <francesco.marella@gmail.com>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
[ currojerez@riseup.net: No need to spam the logs in that case, an
  unbound LVDS encoder is not an error. ]
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Perf tables v 1.2 and 1.3 (seen on Geforce FX/ 5) are not long enough
to store the voltage label/id

v2 - Remove comment from the code
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In line with envytools, verified on 4 or 5 BIOS'es.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>

Avoid touching the flip setup regs while
acceleration is running.  Set them at modeset
rather than during pageflip.  Touching these
regs while acceleration is active caused hangs
on pre-avivo chips.  These chips do not seem
to be affected, but better safe than sorry,
plus it avoids repeatedly reprogramming the
regs every flip.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Nouveau needs access to this structure to build an ELD block for use
by the HDA audio codec.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=35502

agd5f: also add sanity check to connector records.

v2: fix one more case.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.

If we don't clear the NAK, then all future GMBUS xfers will fail,
including DDC probes and EDID retrieval.

v2: Add some comments as suggested by Keith Packard.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: N"Mengmeng Meng" <mengmeng.meng@intel.com>

During modesetting, we need to wait for the hardware to report
readiness by polling the registers. Normally, we call msleep() between
reads, because some state changes may take a whole vblank or more
to complete. However during a panic, we are in an atomic context and
cannot sleep. Instead, busy spin polling the termination condition.

References: https://bugzilla.kernel.org/show_bug.cgi?id=31772Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch fixes information leakage to the userspace by initializing
the data buffer to zero.
Reported-by: NPeter Huewe <huewe.external@infineon.com>
Signed-off-by: NPeter Huewe <huewe.external@infineon.com>
Signed-off-by: NMarcel Selhorst <m.selhorst@sirrix.com>
[ Also removed the silly "* sizeof(u8)".  If that isn't 1, we have way
  deeper problems than a simple multiplication can fix.   - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We check the pointers together but at least one of them could be invalid
due to failed allocation. Since we cannot continue if either of the two
allocations has failed, exit early by freeing them both.

Cc: <stable@kernel.org> # 38.x
Reported-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

These functions take irq_data as an argument and avoid a redundant
lookup in the sparse irq case.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This driver is broken in several aspects.

 1) old style irq_chip functions. Sigh

 2) Abuse of the unlock callback. That's not supposed to be a state
    machine for evrything and some more.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

These functions take irq_data as an argument and avoid a redundant
lookup in the sparse irq case.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Convert to the new function names. Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: linux-parisc@vger.kernel.org

This is needed for determining the reason for failure when a softdog
timeout occurs.

We use softdog to watch for critical application failures and at the
minimum a snapshot of the system would help to determine the cause.  In
such a scenario the application could fail but there isn't a softlockup as
such, hence the detect softlockup feature does not help.

The patch adds a module parameter soft_panic which when set to 1 causes
softdog to invoke panic instead of reboot when the softdog timer expires. 
By invoking panic we execute kdump if it is configured and the vmcore
generated by kdump should provide atleast a minimal idea of the reason for
failure.

Based on an original patch by Ken Sugawara <sugaken.r3@gmail.com>
Signed-off-by: NAnithra P J <anithra@linux.vnet.ibm.com>
Reviewed-by: NWANG Cong <xiyou.wangcong@gmail.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Fix section mismatch warning:
Mark the called nv_tco_getdevice() as __devinit, just like its caller.

WARNING: drivers/watchdog/nv_tco.o(.devinit.text+0x16): Section mismatch in reference from the function nv_tco_init() to the function .init.text:nv_tco_getdevice()
The function __devinit nv_tco_init() references
a function __init nv_tco_getdevice().
If nv_tco_getdevice is only used by nv_tco_init then
annotate nv_tco_getdevice with a matching annotation.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Stefano found SP5100 TCO watchdog driver using wrong address.

[    9.148536] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01
[    9.148628] DEBUG __ioremap_caller WARNING address=b8fe00 size=8 valid=1 reserved=1

and e820 said that range is RAM.

We should check if we can use that reading out. BIOS could just program wrong address there.
Reported-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NMike Waychison <mikew@google.com>
Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

Request_mem_region should be used with release_mem_region, not
release_resource.

In pnx4008_wdt.c, a missing clk_put is added as well.

The semantic match that finds the first problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,E;
@@
*x = request_mem_region(...)
... when != release_mem_region(x)
    when != x = E
* release_resource(x);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

Request_mem_region should be used with release_mem_region, not
release_resource.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression x,E;
@@
*x = request_mem_region(...)
... when != release_mem_region(x)
    when != x = E
* release_resource(x);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

The current code sometimes generates build warnings due to how it checks
the silicon revision, so clean it up and properly document things.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The correct usage should be "static inline void" instead of "static void inline"
Signed-off-by: NG.Balaji <balajig81@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While testing the performance of different receive interrupt
coalescing settings on a single stream TCP benchmark, I noticed two
very different results. With rx-usecs=50, most of the time a
connection would hit 8280 Mbps but once in a while it would hit
9330 Mbps.

It turns out we are only applying the interrupt coalescing settings
to the first queue and whenever the rx hash would direct us onto
that queue we ran faster.

With this patch applied and rx-usecs=50, I get 9330 Mbps
consistently.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Acked-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We incorrectly returned -EINVAL when none of the devices in the array
had an integrity profile.  This in turn prevented mdadm from starting
the metadevice.  Fix this so we only return errors on mismatched
profiles and memory allocation failures.
Reported-by: NGiacomo Catenazzi <cate@cateee.net>
Reported-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes this build error:

  drivers/memstick/host/r592.c:26: error: 'enable_dma' redeclared as different kind of symbol
  arch/powerpc/include/asm/dma.h:189: note: previous definition of 'enable_dma' was here
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Alex Dubov <oakad@yahoo.com>
Acked-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The acpi video driver attempts to explicitly create a sysfs link between
the acpi device and the associated PCI device. However, we're now also
doing this from the backlight core, which means that we get a backtrace
caused by a duplicate file. Remove the code and leave it up to the
backlight core.
Reported-by: NJeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Convert to the new irq_chip functions and the new namespace.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NFlorian Fainelli <florian@openwrt.org>
LKML-Reference: <alpine.LFD.2.00.1103252150180.31464@localhost6.localdomain6>

Stephen ran into the following build error:

  drivers/mfd/cs5535-mfd.c:30:22: error: asm/olpc.h: No such file or directory

olpc.h exists only on x86 (and in the future, ARM).  Rather than
wrapping the include in an #ifdef, just change cs5535-mfd to only build
on x86.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In commit 95a0f10c ("drbd: store in-core bitmap little endian,
regardless of architecture") drbd had made the sane choice to use
little-endian bitmap functions everywhere.  However, it used the
horrible old functions names from <asm-generic/bitops/le.h>, that were
never really meant to be exported.

In the meantime, things got cleaned up, and in commit c4945b9e
("asm-generic: rename generic little-endian bitops functions") we
renamed the LE bitops to something sane, exactly so that they could be
used in random code without people gouging their eyes out when seeing
the crazy jumble of letters that were the old internal names.

As a result the drbd thing merged cleanly (commit 8d49a775: "Merge
branch 'for-2.6.39/drivers' of git://git.kernel.dk/linux-2.6-block"),
since there was no data conflict - but the end result obviously doesn't
actually compile.
Reported-and-tested-by: NIngo Molnar <mingo@elte.hu>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix build breakage on platforms, not providing readsw and writesw
functions, e.g., on x86(_64).
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

This is handled automatically now.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

This is what I intended to do since:
  1) the driver handles variable waits just fine, and
  2) interruptible waits aren't reported as load in the load avg.
Reported-and-tested-by: NAndreas Hartmann <andihartmann@freenet.de>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>