Some archs such as blackfin, would like to have an arch specific
probe_kernel_read() and probe_kernel_write() implementation which can
fall back to the generic implementation if no special operations are
needed.

CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm/radeon/kms: rs600: use correct mask for SW interrupt
  gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
  drm/radeon/radeon_device.c: move a dereference below a NULL test
  drm/radeon/radeon_fence.c: move a dereference below the NULL test
  drm/radeon/radeon_connectors.c: add a NULL test before dereference
  drm/radeon/kms: fix memory leak
  drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line()
  drm/edid: Fix CVT width/height decode
  drm/edid: Skip empty CVT codepoints
  drm: remove address mask param for drm_pci_alloc()
  drm/radeon/kms: add missing breaks in i2c and ss lookups
  drm/radeon/kms: add primary dac adj values table
  drm/radeon/kms: fallback to default connector table

* korg/drm-radeon-next:
  drm/radeon/kms: rs600: use correct mask for SW interrupt
  gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
  drm/radeon/radeon_device.c: move a dereference below a NULL test
  drm/radeon/radeon_fence.c: move a dereference below the NULL test
  drm/radeon/radeon_connectors.c: add a NULL test before dereference
  drm/radeon/kms: fix memory leak
  drm/radeon/kms: add missing breaks in i2c and ss lookups
  drm/radeon/kms: add primary dac adj values table
  drm/radeon/kms: fallback to default connector table

The mask happens to be the same, but the IH is reading the status, not the
not the control register.
Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13338
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13335
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13334
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The encoder variable can be NULL in this function so I believe it should
be checked before dereference.

Coverity CID: 13253

[airlied: extremely unlikely to happen]
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Stanse found a memory leak in radeon_master_create. master_priv is not
freed/assigned on all paths. Fix that.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* drm-core-next:
  drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line()
  drm/edid: Fix CVT width/height decode
  drm/edid: Skip empty CVT codepoints
  drm: remove address mask param for drm_pci_alloc()

This always evaluates to true.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_pci_alloc() has input of address mask for setting pci dma
mask on the device, which should be properly setup by drm driver.
And leave it as a param for drm_pci_alloc() would cause confusion
or mistake would corrupt the correct dma mask setting, as seen on
intel hw which set wrong dma mask for hw status page. So remove
it from drm_pci_alloc() function.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (23 commits)
  drm/i915: remove full registers dump debug
  drm/i915: Add DP dpll limit on ironlake and use existing DPLL search function
  drm/i915: Select the correct BPC for LVDS on Ironlake
  drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake
  drm/i915: Enable/disable the dithering for LVDS based on VBT setting
  drm/i915: Permit pinning whilst the device is 'suspended'
  drm/i915: Hold struct mutex whilst pinning power context bo.
  drm/i915: fix unused var
  drm/i915: Storage class should be before const qualifier
  drm/i915: remove render reclock support
  drm/i915: Fix RC6 suspend/resume
  drm/i915: execbuf2 support
  drm/i915: Reload hangcheck timer too for Ironlake
  drm/i915: only enable hotplug for detected outputs
  drm/i915: Track whether cursor needs physical address in intel_device_info
  drm/i915: Implement IS_* macros using static tables
  drm/i915: Move PCI IDs into i915 driver
  drm/i915: Update LVDS connector status when receiving ACPI LID event
  drm/i915: Add MALATA PC-81005 to ACPI LID quirk list
  drm/i915: implement new pm ops for i915
  ...

The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush.  This
is important when doing things like setting software breakpoints with
gdb.  So switch the NOMMU code over to do the same.

This patch makes the reasonable assumption that copy_from_user_page()
won't fail - which is probably fine, as we've checked the VMA from which
we're copying is usable, and the copy is not allowed to cross VMAs.  The
one case where it might go wrong is if the VMA is a device rather than
RAM, and that device returns an error which - in which case rubbish will
be returned rather than EIO.
Signed-off-by: NJie Zhang <jie.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDavid McCullough <david_mccullough@mcafee.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When working with FDPIC, there are many shared mappings of read-only
code regions between applications (the C library, applet packages like
busybox, etc.), but the current do_mmap_pgoff() function will issue an
icache flush whenever a VMA is added to an MM instead of only doing it
when the map is initially created.

The flush can instead be done when a region is first mmapped PROT_EXEC.
Note that we may not rely on the first mapping of a region being
executable - it's possible for it to be PROT_READ only, so we have to
remember whether we've flushed the region or not, and then flush the
entire region when a bit of it is made executable.

However, this also affects the brk area.  That will no longer be
executable.  We can mprotect() it to PROT_EXEC on MPU-mode kernels, but
for NOMMU mode kernels, when it increases the brk allocation, making
sys_brk() flush the extra from the icache should suffice.  The brk area
probably isn't used by NOMMU programs since the brk area can only use up
the leavings from the stack allocation, where the stack allocation is
larger than requested.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current code will load the stack size and protection markings, but
then only use the markings in the MMU code path.  The NOMMU code path
always passes PROT_EXEC to the mmap() call.  While this doesn't matter
to most people whilst the code is running, it will cause a pointless
icache flush when starting every FDPIC application.  Typically this
icache flush will be of a region on the order of 128KB in size, or may
be the entire icache, depending on the facilities available on the CPU.

In the case where the arch default behaviour seems to be desired
(EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine
whether we should be setting PROT_EXEC or not.

For arches that support an MPU (Memory Protection Unit - an MMU without
the virtual mapping capability), setting PROT_EXEC or not will make an
important difference.

It should be noted that this change also affects the executability of
the brk region, since ELF-FDPIC has that share with the stack.  However,
this is probably irrelevant as NOMMU programs aren't likely to use the
brk region, preferring instead allocation via mmap().
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-2.6.33' of git://linux-nfs.org/~bfields/linux:
  sunrpc: fix peername failed on closed listener
  nfsd: make sure data is on disk before calling ->fsync
  nfsd: fix "insecure" export option

There're some warnings of "nfsd: peername failed (err 107)!"
socket error -107 means Transport endpoint is not connected.
This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
when kernel_getpeername returns -107. This means socket might be CLOSED.

And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]

        if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
        <snip>
                newxpt = xprt->xpt_ops->xpo_accept(xprt);
        <snip>

So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.

Let's take a look at commit b0401d72, this commit has moved the close
processing after do recvfrom method, but this commit also introduces this
warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
close it, not accpet then close.
Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
Cc: J. Bruce Fields <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

nfsd is not using vfs_fsync, so I missed it when changing the calling
convention during the 2.6.32 window.  This patch fixes it to not only
start the data writeout, but also wait for it to complete before calling
into ->fsync.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

* 'davinci-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci:
  DaVinci: DM365: Add the device_enable for the DaVinci Keyscan
  davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci
  davinci: da8xx/omap-l1: mark RTC as a wakeup source
  davinci: cp_intc: provide set_wake function
  Davinci VPFE Capture: Take i2c adapter id through platform data

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] lpfc 8.3.7: Update Driver version to 8.3.7
  [SCSI] lpfc 8.3.7: Fix discovery failures.
  [SCSI] lpfc 8.3.7: Fix SCSI protocol related errors.
  [SCSI] lpfc 8.3.7: Fix hardware/SLI relates issues
  [SCSI] lpfc 8.3.7: Fix NPIV operation errors
  [SCSI] lpfc 8.3.7: Fix FC protocol errors
  [SCSI] stex: fix scan of nonexistent lun
  [SCSI] pmcraid: fix to avoid twice scsi_dma_unmap for a command
  [SCSI] qla2xxx: Update version number to 8.03.01-k9.
  [SCSI] qla2xxx: Added to EEH support.
  [SCSI] qla2xxx: Extend base EEH support in qla2xxx.
  [SCSI] qla2xxx: Fix for a multiqueue bug in CPU affinity mode
  [SCSI] qla2xxx: Get the link data rate explicitly during device resync.
  [SCSI] cxgb3i: Fix a login over vlan issue

This one reverts 9e3a6d15.
As reported by http://bugzilla.kernel.org/show_bug.cgi?id=14485,
this dump will cause hang problem on some machine. If something
really needs this kind of full registers dump, that could be done
within intel-gpu-tools.

Cc: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

For some clocks, the old Ironlake DPLL calculator wold give m/n/p
combinations that didn't match the spreadsheet of what HW validation
tests.  Instead, use the G4X DPLL calculator, which does a better job
at it.

So we use the intel_g4x_find_best_pll to calculate the DPLL for CRT/HDMI/LVDS
on ironlake. At the same time to consider the dpll setting for display port, we
add the display port DPLL limit on ironlake, which will directly use the
function of intel_find_pll_ironlake_dp to get the corresponding dpll setting.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel,
the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8.
At the same time the BPC will be 8 when the output device is CRT/HDMI/DP.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x
platform the dithering flag is defined in LVDS register. And on the ironlake
the dithering flag is defined in pipeconf register.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

As pinning (allocating and binding GTT memory) does not actually invoke
GPU commands, it is safe, and indeed is attempted, during resumption
from suspension:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Hugh found an error path where we were attempting to unref a bo without
holding the struct mutex:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
  ------------[ cut here ]------------
  WARNING: at drivers/gpu/drm/drm_gem.c:438 drm_gem_object_free+0x20/0x5e()
  Hardware name: ESPRIMO Mobile V5505
  Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
  Pid: 3793, comm: s2ram Not tainted 2.6.33-rc2 #4
  Call Trace:
   [<7815298e>] warn_slowpath_common+0x59/0x6b
   [<781529b3>] warn_slowpath_null+0x13/0x18
   [<78317c1a>] ? drm_gem_object_free+0x20/0x5e
   [<78317c1a>] drm_gem_object_free+0x20/0x5e
   [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
   [<7829df11>] kref_put+0x38/0x45
   [<7833a5f0>] intel_init_clock_gating+0x232/0x271
   [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
   [<7832c307>] i915_restore_state+0x21a/0x2b3
   [<7832379d>] i915_resume+0x3c/0xbb
   [<78174fe5>] ? trace_hardirqs_on_caller+0xfc/0x123
   [<7831c756>] ? drm_class_resume+0x0/0x3e
   [<7831c78d>] drm_class_resume+0x37/0x3e
   [<78351e0a>] legacy_resume+0x1e/0x51
   [<78351ece>] device_resume+0x91/0xab
   [<7831c756>] ? drm_class_resume+0x0/0x3e
   [<78352226>] dpm_resume+0x58/0x10f
   [<783522fb>] dpm_resume_end+0x1e/0x2c
   [<78180f80>] suspend_devices_and_enter+0x61/0x84
   [<78180ff8>] enter_state+0x55/0x83
   [<7818091c>] state_store+0x94/0xaa
   [<7829d09e>] kobj_attr_store+0x1e/0x23
   [<782098e0>] sysfs_write_file+0x66/0x99
   [<781cd2f0>] vfs_write+0x8a/0x108
   [<781cd408>] sys_write+0x3c/0x63
   [<78125c10>] sysenter_do_call+0x12/0x36
  ---[ end trace a343537f29950fda ]---

It is in fact slightly more insiduous that first appears since we are
attempting to not just free the object without the lock, but are trying
to do the whole bo manipulation without holding the lock.
Reported-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function

Partly this is because gcc isn't smart enough.  But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

This code generally fails to adjust the render clock, and when it does,
it conflicts with some other register settings and can cause problems.

So remove this code altogether.  I'm reworking it now to do the right
thing, but the only bit it will share is the VBT check for whether
reclocking is supported, so I'm leaving that bit.

Reverts most of 652c393a ("add dynamic
clock frequency control"), though for many the regressions showed up
in the later 181a5336 ("Fix render
reclock availability detection").
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We restored RC6 twice on resume, even with modesetting off.  Instead,
only restore it once and skip RC6 initialization entirely in non-KMS mode.
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Tested-by: NJeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This patch adds a new execbuf ioctl, execbuf2, for use by clients that
want to control fence register allocation more finely.  The buffer
passed in to the new ioctl includes a new relocation type to indicate
whether a given object needs a fence register assigned for the command
buffer in question.

Compatibility with the existing execbuf ioctl is implemented in terms
of the new code, preserving the assumption that fence registers are
required for pre-965 rendering commands.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: Remove pre-emptive clear_fence_reg()]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
[anholt: Removed dmesg spam]
Signed-off-by: NEric Anholt <eric@anholt.net>

Adds the device_enable function to the DaVinci Keyscan platform data
to setup the PINMUX configuration.

It also removes #ifdef from the DM365 EVM board in order to load it
properly as a module.
Signed-off-by: NMiguel Aguilar <miguel.aguilar@ridgerun.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

All DaVinci platforms include a DSP or co-processor for
audio/video acceleration.

While creating memory for the DSP/co-processor, system
integrator can end up creating a hole in the memory map
of the sort:

<kernel memory> <hole (memory for DSP)> <kernel memory>

This sort of configuration needs ARCH_HAS_HOLES_MEMORYMODEL
enabled. See further details see this discussion on ARM
linux mailing list:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15262.html

The patch is boot tested on OMAP-L138, DM6446 and DM355 EVMs
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
CC: Sriramakrishnan <srk@ti.com>
CC: Khasim Syed Mohammed <khasim@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

On da850, RTC alarm is a wakeup source from deep sleep.
Mark it as a wakeup source after the rtc platform device
is registered.

Without this patch, the rtc-omap driver suspends the RTC
during the suspend sequence and hence it cannot wakeup the
SoC.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

There is nothing special to be done for interrupts
which can wakeup the device from sleep on CP-INTC,
but not having a set_wake implemented prevents use
of common drivers which expect this function to be
implemented for all wakeup interrupt sources.

This patch fixes the issue encountered when using the
omap-rtc driver on DA850. On DA850 the RTC alarm
interrupt is used to wake up the SoC from deep sleep
mode. Without this patch, the disable_irq_wake throws
an unbalanced wake disable warning while resuming
because the previous enable call fails for lack of
set_wake implementation.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.

So modified respective davinci board files.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>