I see the following error message in my kernel log from time to time:
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait

After investigation, it turns out that there's nothing to be afraid of
and everything works as intended. So remove the spurious log message.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Missing parens.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=30718Reported-by: NDave Gilbert <freedesktop@treblig.org>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NMatt Turner <mattst88@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make TV standard and DFP table revisions debug only.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

These bits are used for internal communication and should
be left enabled.  This may fix s/r issues on some systems.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.

This patch limit the vram allocation to visible vram until
we have acceleration up and running.

Note that it's more than unlikely that we run into any issue
related to that as when acceleration is not woring userspace
should allocate any object in vram beside front buffer which
should fit in visible vram.

V2 use real_vram_size as mc_vram_size could be bigger than
   the actual amount of vram

[airlied: fixup r700_cp_stop case]
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently the pressure range in Cintiq 21UX2 is limited to half of the
supported. This patch fixes the problem.
Signed-off-by: NAristeu Rozanski <aris@redhat.com>
Acked-by: NPing Cheng <pingc@wacom.com>
CC: stable@kernel.org
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Must drop reference taken by blk_make_request().
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org # .35.x
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ATM-C6 was commented out, pending public documentation.

https://bugzilla.kernel.org/show_bug.cgi?id=19762Tested-by: NDennis Jansen <Dennis.Jansen@...>
Signed-off-by: NLen Brown <len.brown@intel.com>

setup.phone and setup.eazmsn are 32 character buffers.
rcvmsg.msg_data.byte_array is a 48 character buffer.
sc_adapter[card]->channel[rcvmsg.phy_link_no - 1].dn is 50 chars.

The rcvmsg struct comes from the memcpy_fromio() in receivemessage().
I guess that means it's data off the wire.  I'm not very familiar with
this code but I don't see any reason to assume these strings are NULL
terminated.

Also it's weird that "dn" in a 50 character buffer but we only seem to
use 32 characters.  In drivers/isdn/sc/scioc.h, "dn" is only a 49
character buffer.  So potentially there is still an issue there.

The important thing for now is to prevent the memory corruption.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The i915 driver has quite a few module unload bugs, the known ones at
least have fixes that are targeting 2.6.37. However, in order to
maintain a stable kernel, we should prevent this known random memory
corruption following driver unload. This should have very low impact on
normal users who are unlikely to need to unload the i915 driver.
Suggested-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

since the handle references are all tied to a file_priv, and when it disappears
all the handle refs go with it.

The fbcon ones we'd only notice on unload, but the nouveau notifier one
would would happen on reboot.

nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com>
nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com>
i915 unload: Reported-by: Keith Packard <keithp@keithp.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Function read_sb_page may return ERR_PTR(...). Check for it.
Signed-off-by: NVasiliy Kulikov <segooon@gmail.com>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NNeilBrown <neilb@suse.de>

When performing a resync we pre-allocate some bios and repeatedly use
them.  This requires us to re-initialise them each time.
One field (bi_comp_cpu) and some flags weren't being initiaised
reliably.
Signed-off-by: NNeilBrown <neilb@suse.de>

bitmap_start_sync returns - via a pass-by-reference variable - the
number of sectors before we need to check with the bitmap again.
Since commit ef425673 this number can be substantially larger,
2^27 is a common value.

Unfortunately it is an 'int' and so when raid1.c:sync_request shifts
it 9 places to the left it becomes 0.  This results in a zero-length
read which the scsi layer justifiably complains about.

This patch just removes the shift so the common case becomes safe with
a trivially-correct patch.

In the next merge window we will convert this 'int' to a 'sector_t'
Reported-by: N"George Spelvin" <linux@horizon.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

  wireless-testing
  commit 37e5bf65
  Author: Luis R. Rodriguez <lrodriguez@atheros.com>
  Date:   Sat Jun 12 00:33:40 2010 -0400

    ath9k_hw: fix clock rate calculations for ANI

This commit accidentally broke clock rate calculation by doubling the
calculated clock rate
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix a WARN_ON failure in bond_masters sysfs file

Got a report of this warning recently

bonding: bond0 is being created...
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
Hardware name: ProLiant BL465c G1
proc_dir_entry 'bonding/bond0' already registered
Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
ipmi_si
ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
cc
iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
scsi_wai
t_scan]
Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
Call Trace:
[<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
[<ffffffff8114bf0b>] proc_register+0x14d/0x185
[<ffffffff8114c20c>] proc_create_data+0x87/0xa1
[<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
[<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
[<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
[<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
[<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
[<ffffffff812aec85>] class_attr_store+0x27/0x29
[<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
[<ffffffff81101acf>] vfs_write+0xa9/0x106
[<ffffffff81101be2>] sys_write+0x45/0x69
[<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
---[ end trace a677c3f7f8b16b1e ]---
bonding: Bond creation failed.

It happens because a user space writer to bond_master can try to
register an already existing bond interface name.  Fix it by teaching
bond_create to check for the existance of devices with that name first
in cases where a non-NULL name parameter has been passed in
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes a race pointed out by Dave Airlie where we don't take a buffer
object about to be destroyed off the LRU lists properly. It also fixes a rare
case where a buffer object could be destroyed in the middle of an
accelerated eviction.

The patch also adds a utility function that can be used to prematurely
release GPU memory space usage of an object waiting to be destroyed.
For example during eviction or swapout.

The above mentioned commit didn't queue the buffer on the delayed destroy
list under some rare circumstances. It also didn't completely honor the
remove_all parameter.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=615505
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Skge devices installed on some Gigabyte motherboards are not able to
perform 64 dma correctly due to board PCI implementation, so limit
DMA to 32bit if such boards are detected.

Bug was reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=447489Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Tested-by: NLuya Tshimbalanga <luya@fedoraproject.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Values here are in internal units rather than Watts, so we shouldn't
perform any conversion.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The undocumented interface we're using for reading CPU power seems to be
overreporting power.  Until we figure out how to correct it, disable CPU
turbo and power reporting to be safe.  This will keep the CPU within default
limits and still allow us to increase GPU frequency as needed.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The BIOS may hand us a lower CPU power limit than the default for a
given SKU.  We should use it in case the platform isn't designed to
dissapate the full TDP of a given part.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Both when polling the current turbo status (in poll_turbo_status mode)
and when handling thermal events (in ips_irq_handler) the current status
of GPU turbo is updated to match the hardware status.  However if during
driver initialisation we were unable aquire linkage to the i915 driver
enabling GPU turbo will lead to an oops on the first attempt to determine
GPU busy status.

Ensure that we do not enable GPU turbo unless we have driver linkage.

BugLink: http://bugs.launchpad.net/bugs/632430
Cc: stable@kernel.org
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Print some interesting values when MCP limits
are exceeded.
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

They're optional.  If not present or sane, we should use the CPU
defaults.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

If the CPU doesn't support turbo, don't try to enable/disable it.

http://bugzilla.kernel.org/show_bug.cgi?id=18742Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

 The patch is to create ips_adjust thread before ips_monitor begins
 to run  because the latter will kthread_stop() or wake up the former
 via ips->adjust pointer. Without this change, it is possible that
 ips->adjust is NULL when kthread_stop() or wake_up_process() is
 called in ips_monitor().
Signed-off-by: Nminskey guo <chaohong.guo@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

In ips_get_i915_syms(), the symbol i915_gpu_busy() is not released
when error occurs.
Signed-off-by: Nminskey guo <chaohong.guo@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The variable old_cpu_power is used to save the value of THM_CEC
register. In get_cpu_power(), it will be divided by 65535.
Signed-off-by: Nminskey guo <chaohong.guo@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The mask of sequence number in THM_ITV register is 16bit width instead
of 8bit.
Signed-off-by: Nminskey guo <chaohong.guo@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Register_xenstore_notifier should guarantee that the caller gets
notified even if xenstore is already up.
Therefore we revert "do not notify callers from
register_xenstore_notifier" and set xenstored_read at the right time for
PV on HVM guests too.
In fact in case of PV on HVM guests xenstored is ready only after the
platform pci driver has completed the initialization, so do not set
xenstored_ready before the call to xenbus_probe().

This patch fixes a shutdown_event watcher registration bug that causes
"xm shutdown" not to work properly.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>

When runtime PM is enabled by default for input devices, X hangs in
wacom open:
[<ffffffff814a00ea>] mutex_lock+0x1a/0x40
[<ffffffffa02bc94b>] wacom_resume+0x3b/0x90 [wacom]
[<ffffffff81327a32>] usb_resume_interface+0xd2/0x190
[<ffffffff81327b5d>] usb_resume_both+0x6d/0x110
[<ffffffff81327c24>] usb_runtime_resume+0x24/0x40
[<ffffffff8130a2cf>] __pm_runtime_resume+0x26f/0x450
[<ffffffff8130a23a>] __pm_runtime_resume+0x1da/0x450
[<ffffffff8130a53a>] pm_runtime_resume+0x2a/0x50
[<ffffffff81328176>] usb_autopm_get_interface+0x26/0x60
[<ffffffffa02bc626>] wacom_open+0x36/0x90 [wacom]

wacom_open() takes wacom->lock and calls usb_autopm_get_interface(),
which in turn calls wacom_resume() which tries to acquire the lock
again.

The fix is to call usb_autopm_get_interface() first, before we take
the lock.

Since we do not do usb_autopm_put_interface() until wacom_close()
is called runtime PM is effectively disabled for the driver, however
changing it now would risk regressions so the complete fix will
have to wait till the next merge window.
Reported-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Since 'select' ignores dependencies, drivers that select INET_LRO must
depend on INET.  This fixes the broken configuration reported in
<http://article.gmane.org/gmane.linux.kernel/825646>.
Reported-by: NSubrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

... and do the same for pread.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Move the access control up from the fast paths, which are no longer
universally taken first, up into the caller. This then duplicates some
sanity checking along the slow paths, but is much simpler.
Tracked as CVE-2010-2962.
Reported-by: NKees Cook <kees@ubuntu.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Sleep while acquiring a resource lock on the Super I/O port. This should
prevent collisions from causing the hardware probe to fail with -EBUSY.
Signed-off-by: NGiel van Schijndel <me@mortis.eu>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>

Instead of waiting for the display line value to settle, we can simply
wait for the pipe configuration register 'state' bit to turn off.

Contrarywise, disabling the plane will not cause the display line
value to stop changing, so instead we wait for the vblank interrupt
bit to get set. And, we only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

While the display port is in training mode, vblank interrupts don't
occur. Because we have to wait for the display port output to turn on
before starting the training sequence, enable the output in 'normal'
mode so that we can tell when a vblank has occurred, then start the
training sequence.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This patch adds the OF hook to the spi core so that devices
can automatically be registered based on device tree data.  This fixes
a problem with spi devices not binding to drivers after the cleanup of
the spi & i2c binding code.
Signed-off-by: NSinan Akman <sinan@writeme.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The SPI_MASTER_NO_TX bit (can't do buffer write) wasn't tested.  This
code was introduced in commit 3c8e1a84 (spi/spi-gpio: add support for
controllers without MISO or MOSI pin).  This patch fixes a bug in
choosing which transfer ops to use.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Extend the error handling code with operations found in other nearby error
handling code

A simplified version of the sematic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r exists@
@r@
statement S1,S2,S3;
constant C1,C2,C3;
@@

*if (...)
 {... S1 return -C1;}
...
*if (...)
 {... when != S1
    return -C2;}
...
*if (...)
 {... S1 return -C3;}
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org