drm/i915: tune down hangcheck noise

We already have a big splashing *ERROR* for all the relevant cases of
hangs, so this one here is redudant. And it results in an unclean
dmesg when running with simulated hangs. Regression has been
introduced in

commit 05407ff889ceebe383aa5907219f86582ef96b72
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Thu May 30 09:04:29 2013 +0300

    drm/i915: detect hang using per ring hangcheck_score

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68641
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fix lvds/dp panel fitter setting

If need to enable the panel fitter, the crtc timings have to be
programmed according to the panel's native (fixed) mode. This isn't the
case atm, since after the encoder changes adjusted_mode to fixed
mode the crtc_* timing fields of adjusted_mode will stay at their original
non-native values that the user passed in. This results in a corrupted
output.

One exception is when we have a second pass of computing encoder configs
due to bandwidth limitation, since then we'll set adjusted_mode.crtc_*
fields to the fixed mode values set in the first pass; so in this case
things will work out.

Fix this by updating the adjusted_mode.crtc_* fields when we set the
fixed panel mode.

This regression has been introduced in

commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 21 21:37:09 2013 +0200

    drm/i915: clean up crtc timings computation

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fuse: postpone end_page_writeback() in fuse_writepage_locked()

The patch fixes a race between ftruncate(2), mmap-ed write and write(2):

1) An user makes a page dirty via mmap-ed write.
2) The user performs shrinking truncate(2) intended to purge the page.
3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
   writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
   the original page by end_page_writeback.
4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
   is free.
5) Ordinary write(2) extends i_size back to cover the page. Note that
   fuse_send_write_pages do wait for fuse writeback, but for another
   page->index.
6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
   fuse_send_writepage is supposed to crop inarg->size of the request,
   but it doesn't because i_size has already been extended back.

Moving end_page_writeback to the end of fuse_writepage_locked fixes the
race because now the fact that truncate_pagecache is successfully returned
infers that fuse_writepage_locked has already called end_page_writeback.
And this, in turn, infers that fuse_flush_writepages has already called
fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
could not extend it because of i_mutex held by ftruncate(2).

Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
fuse: invalidate inode attributes on xattr modification

Calls like setxattr and removexattr result in updation of ctime.
Therefore invalidate inode attributes to force a refresh.

Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
fuse: hotfix truncate_pagecache() issue

The way how fuse calls truncate_pagecache() from fuse_change_attributes()
is completely wrong. Because, w/o i_mutex held, we never sure whether
'oldsize' and 'attr->size' are valid by the time of execution of
truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
released fc->lock in the middle of fuse_change_attributes(), we completely
loose control of actions which may happen with given inode until we reach
truncate_pagecache. The list of potentially dangerous actions includes
mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.

The typical outcome of doing truncate_pagecache() with outdated arguments
is data corruption from user point of view. This is (in some sense)
acceptable in cases when the issue is triggered by a change of the file on
the server (i.e. externally wrt fuse operation), but it is absolutely
intolerable in scenarios when a single fuse client modifies a file without
any external intervention. A real life case I discovered by fsx-linux
looked like this:

1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
to the server synchronously, then calls fuse_change_attributes(). The
latter updates i_size, releases fc->lock, but before comparing oldsize vs
attr->size..
3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
updating attributes and i_size, but now oldsize is equal to
outarg.attr.size because i_size has just been updated (step 2). Hence,
fuse_do_setattr() returns w/o calling truncate_pagecache().
4. As soon as ftruncate(2) completes, the user extends file size by
write(2) making a hole in the middle of file, then reads data from the hole
either by read(2) or mmap-ed read. The user expects to get zero data from
the hole, but gets stale data because truncate_pagecache() is not executed
yet.

The scenario above illustrates one side of the problem: not truncating the
page cache even though we should. Another side corresponds to truncating
page cache too late, when the state of inode changed significantly.
Theoretically, the following is possible:

1. As in the previous scenario fuse_dentry_revalidate() discovered that
i_size changed (due to our own fuse_do_setattr()) and is going to call
truncate_pagecache() for some 'new_size' it believes valid right now. But
by the time that particular truncate_pagecache() is called ...
2. fuse_do_setattr() returns (either having called truncate_pagecache() or
not -- it doesn't matter).
3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
4. mmap-ed write makes a page in the extended region dirty.

The result will be the lost of data user wrote on the fourth step.

The patch is a hotfix resolving the issue in a simplistic way: let's skip
dangerous i_size update and truncate_pagecache if an operation changing
file size is in progress. This simplistic approach looks correct for the
cases w/o external changes. And to handle them properly, more sophisticated
and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
postpone it until the issue is well discussed on the mailing list(s).

Changed in v2:
 - improved patch description to cover both sides of the issue.

Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
fuse: readdir: check for slash in names

Userspace can add names containing a slash character to the directory
listing.  Don't allow this as it could cause all sorts of trouble.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
MIPS: R4k clock source initialization bug fix

This is a fix for a bug introduced with commit
447cdf2628b59aa513a42785450b348dced26d8a, submitted as archived here:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20080312235002.c717dde3.yoichi_yuasa%40tripeaks.co.jp
regrettably with no further explanation.

The issue is with the CP0 Count register read erratum present on R4000 and
some R4400 processors.  If this erratum is present, then a read from this
register that happens around the time it reaches the value stored in the
CP0 Compare register causes a CP0 timer interrupt that is supposed to
happen when the values in the two registers match to be missed.  The
implication for the chips affected is the CP0 timer can be used either as
a source of a timer interrupt (a clock event) or as a source of a
high-resolution counter (a clock source), but not both at a time.

The erratum does not affect timer interrupt operation itself, because in
this case the CP0 Count register is only read while the timer interrupt
has already been raised, while high-resolution counter references happen
at random times.

Additionally some systems apparently have issues with the timer interrupt
line being routed externally and not following the usual CP0 Count/Compare
semantics.  In this case we don't want to use the R4k clock event.

We've meant to address the erratum and the timer interrupt routing issue
in time_init, however the commit referred to above broke our solution.
What we currently have is we enable the R4k clock source if the R4k clock
event initialization has succeeded (the timer is present and has no timer
interrupt routing issue) or there is no CP0 Count register read erratum.
Which gives the following boolean matrix:

clock event | count erratum => clock source
------------+---------------+--------------
     0      |       0       |      1 (OK)
     0      |       1       |      0 (bug!) -> no interference, could use
     1      |       0       |      1 (OK)
     1      |       1       |      1 (bug!) -> can't use, interference

What we want instead is to enable the R4k clock source if there is no CP0
Count register read erratum (obviously) or the R4k clock event
initialization has *failed* -- because in the latter case we won't be
using the timer interrupt anyway, so we don't care about any interference
CP0 Count reads might cause with the interrupt.  This corresponds to the
following boolean matrix:

clock event | count erratum => clock source
------------+---------------+--------------
     0      |       0       |      1
     0      |       1       |      1
     1      |       0       |      1
     1      |       1       |      0

This is implemented here, effectively reverting the problematic commit,
and a short explanation is given next to code modified so that the
rationale is known to future readers and confusion is prevented from
happening here again.

It is worth noting that mips_clockevent_init returns 0 upon success while
cpu_has_mfc0_count_bug returns 0 upon failure.  This is because the former
function returns an error code while the latter returns a boolean value.
To signify the difference I have therefore chosen to compare the result of
the former call explicitly against 0.

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5799/
MIPS: Ftrace: Fix function tracing return address to match

Dynamic function tracing was not working on MIPS.  When doing dynamic
tracing, the tracer attempts to match up the passed in address with
the one the compiler creates in the mcount tables.  The MIPS code was
passing in the return address from the tracing function call, but the
compiler tables were the address of the function call.  So they
wouldn't match.

Just subtracting 8 from the return address will give the address of
the function call.  Easy enough.

Signed-off-by: Corey Minyard <cminyard@mvista.com>
[david.daney@cavium.com: Adjusted code comment and patch Subject.]
Signed-off-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/5592/
thermal: hwmon: move hwmon support to single file

In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.

In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
drivers: thermal: parent virtual hwmon with thermal zone

When  creating virtual hwmon devices based out of thermal
zone devices, the virtual devices won't have parents.

This patch changes the code so that the parent of virtual
hwmon devices is the thermal zone device that they are
based of.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional

When registering a new thermal_device, the thermal framework
will always add a hwmon sysfs interface.

This patch adds a flag to make this behavior optional. Now
when registering a new thermal device, the caller can
optionally inform if hwmon interface is desirable. This can
be done by means of passing a thermal_zone_params.no_hwmon == true.

In order to keep same behavior as of today, all current
calls will by default create the hwmon interface.

Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: Zhang Rui <rui.zhang@intel.com>
Suggested-by: Wei Ni <wni@nvidia.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
thermal: thermal_core: allow binding with limits on bind_params

When registering a thermal zone device using platform information
via bind_params, the thermal framework will always perform the
cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).

This patch changes the data structures so that it is possible
to inform what are the desired limits for each trip point
inside a bind_param. The way the binding is performed is also
changed so that it uses the new data structure.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
drivers: thermal: add check when unregistering cpu cooling

This patch avoids NULL pointer accesses while unregistering
cpu cooling devices, in case a NULL pointer is received.

Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
MIPS: Loongson: Hide the pci code behind CONFIG_PCI

The pci.c code depends on symbols which are only visible
if CONFIG_PCI is selected.

Also fixes the following problem on loongson allnoconfig:
arch/mips/built-in.o: In function `pcibios_init':
pci.c:(.init.text+0x528):
undefined reference to `register_pci_controller'
arch/mips/built-in.o:(.data+0xc):
undefined reference to `loongson_pci_ops'

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5584/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: TXx9: Fix build error if CONFIG_TOSHIBA_JMR3927 is not selected

The jmr3927_vec txx9_board_vec struct is defined in
txx9/jmr3927/setup.c which is only built if
CONFIG_TOSHIBA_JMR3927 is selected. This patch fixes the following
build problem:

arch/mips/txx9/generic/setup.c: In function 'select_board':
arch/mips/txx9/generic/setup.c:354:20: error:
'jmr3927_vec' undeclared (first use in this function)
arch/mips/txx9/generic/setup.c:354:20: note: each undeclared
identifier is reported only once for each function it appears in
make[3]: *** [arch/mips/txx9/generic/setup.o] Error 1

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5713/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Kconfig: Drop obsolete NR_CPUS_DEFAULT_{1,2} options

The NR_CPUS_DEFAULT_1 introduced as an aid for the QEMU
platform in 72ede9b18967e7a8a62a88f164f003193f6d891f
"[MIPS] Qemu: Fix Symmetric Uniprocessor support"
which was later removed in
302922e5f6901eb6f29c58539631f71b3d9746b8
"[MIPS] Qemu: Remove platform."

On certain randconfigs it may happen for NR_CPUS to have an
empty value because not all SMP platforms select a suitable
NR_CPUS_DEFAULT_* value. We fix this by restoring the range
of NR_CPUS to 2..64 and drop the NR_CPUS_DEFAULT_{1,2} symbols.
The first one is no longer used and the latter is not needed since
NR_CPUS=2 is now the default value.

Fixes the following problem on a randconfig:
.config:164:warning: symbol value '' invalid for NR_CPUS

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5747/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: powertv: Drop BOOTLOADER_DRIVER Kconfig symbol

The kbldr.h header file required for this was neither committed in the
original submission in a3a0f8c8ed2e2470f4dcd6da95020d41fed84747
"MIPS: PowerTV: Base files for Cisco PowerTV platform"
nor was it ever present in the git tree so this option never worked.
Fixes the following build problem:
arch/mips/powertv/reset.c:25:36: fatal error: asm/mach-powertv/kbldr.h: No such
file or directory
compilation terminated.

Cc: David VomLehn <dvomlehn@cisco.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: David VomLehn <dvomlehn@cisco.com>
Patchwork: https://patchwork.linux-mips.org/patch/5801/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: add <dt-bindings/> symlink

Add symlink to include/dt-bindings from arch/mips/boot/dts/include/ to
match the ones in ARM and Meta architectures so that preprocessed device
tree files can include various useful constant definitions.

See commit c58299a (kbuild: create an "include chroot" for DT bindings)
merged in v3.10-rc1 for details.

MIPS structures it's dts files a little differently to other
architectures, having a separate dts directory for each SoC/platform,
but most of the definitions in the dt-bindings/ directory are common so
for now lets just have a single "include chroot" for all MIPS platforms.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: Steven. J. Hill <steven.hill@imgtec.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Acked-by: Stephen Warren <swarren@nvidia.com>
Patchwork: http://patchwork.linux-mips.org/patch/5745/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Refactor boot and boot/compressed rules

Split out the arch/mips/boot/ and arch/mips/boot/compressed/ targets
into boot-y and bootz-y variables. This makes it slightly cleaner to add
new targets.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5793/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Refactor load/entry address calculations

The vmlinux load address and entry address is calculated in multiple
places:
 - arch/mips/Makefile defines load-y from CONFIG_PHYSICAL_START (or
   defined by the platform) and passes it to
   arch/mips/boot/compressed/Makefile.
 - arch/mips/boot/compressed/Makefile calculates kernel entry using nm.
 - arch/mips/lasat/image/Makefile calculates both load and entry address
   using nm.

Lets combine these in the main Makefile and then pass them as Make
parameters to each of the three boot image Makefiles (in boot/,
boot/compressed, lasat/image/). The boot/ Makefile doesn't currently use
them, but will soon need to for U-Boot image targets.

The existing load-y definition is used in preference to calculating the
load address using nm.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5794/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>