These are fixes for compiler warnings that for the most
part were introduced during the 3.8 cycle but are otherwise
harmless.

* warning-fixes:
  scripts/sortextable: silence script output
  ARM: s3c: i2c: add platform_device forward declaration
  ARM: mvebu: allow selecting mvebu without Armada XP
  ARM: pick Versatile by default for !MMU
  ARM: integrator: fix build with INTEGRATOR_AP off
  ARM: integrator/versatile: fix NOMMU warnings
  ARM: sa1100: don't warn about mach/ide.h
  ARM: shmobile: fix defconfig warning on CONFIG_USB
  ARM: w90x900: fix legacy assembly syntax
  ARM: samsung: fix assembly syntax for new gas
  ARM: disable virt_to_bus/virt_to_bus almost everywhere
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The exception table sorter outputs one line every time
it gets called, e.g. 'sort done marker at 66dc00', which
is slightly annoying when doing 'make -s' which is otherwise
completely silent. Since that output is not helpful to
most people building the kernel, turn it off by default.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David Daney <david.daney@cavium.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>

A recent cleanup to the mach-osiris.c file is causing build errors
because the i2c-s3c2410.h header file is included before we see
the definition for platform_device. The fix is to make the header file
more robust against inclusion from other places. While this should
normally go through the i2c tree, the bug only exists in arm-soc
at the moment, so it's easier to fix it there before it goes upstream.

Without this patch, building s3c2410_defconfig results in:

arch/arm/mach-s3c24xx/mach-osiris.c:34:0:
include/linux/platform_data/i2c-s3c2410.h:37:26: warning: 'struct platform_device' declared inside parameter list [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: linux-i2c@vger.kernel.org
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>

Selecting only CONFIG_ARCH_MVEBU but not the respective
options for Armada 370 or Armada XP results in these
link errors:

arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_init_cpus':
arch/arm/mach-mvebu/platsmp.c:91: undefined reference to `coherency_get_cpu_count'
arch/arm/mach-mvebu/platsmp.c:104: undefined reference to `armada_mpic_send_doorbell'
arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_prepare_cpus':
arch/arm/mach-mvebu/platsmp.c:111: undefined reference to `set_cpu_coherent'
arch/arm/mach-mvebu/built-in.o: In function `armada_xp_boot_secondary':
arch/arm/mach-mvebu/platsmp.c:83: undefined reference to `armada_xp_boot_cpu'
arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_init':
arch/arm/mach-mvebu/platsmp.c:75: undefined reference to `armada_xp_mpic_smp_cpu_init'
arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_startup':
arch/arm/mach-mvebu/headsmp.S:46: undefined reference to `ll_set_cpu_coherent'

We can solve this by enabling all common MVEBU files that are
referenced by the SMP files. This means we enable code that
is not going to be used without a machine descriptor referencing
it, but only if the kernel is configured specifically for this
case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>

The introduction of ARCH_MULTIPLATFORM changed
the default for nommu kernels from Versatile to
Integrator, which is less common, and does not
currently build for allnoconfig because that does
not select any of the CPUs.

This also ensures that at least one of the three
board files in versatile are enabled, which lets
us successfully build an allnoconfig kernel.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>

The conditional declaration of ap_uart_data is broken
and causes this build error:

In file included from arch/arm/mach-integrator/core.c:35:0:
arch/arm/mach-integrator/common.h:6:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token

Turning the check into an constant-expression if(IS_ENABLED()) statement
creates more readable code and solves this problem as well.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>

On NOMMU kernels, the io_desc variables are unused
because we don't use the MMU to remap the MMIO
areas.

Marking these variables as __maybe_unused easily
avoids the otherwise harmless warnings like

warning: 'versatile_io_desc' defined but not used
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>

This warning has existed since before the start of (git) history.
Apparently nobody has bothered to fix it in a long time, and
this is unlikely to change. Note that the file that the warning
refers to has moved to a different location and was subsequently
deleted in 2008.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>

A recent update to the marzen_defconfig introduced a
duplicate CONFIG_USB=y line. This removes one of the
two.

arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Cc: linux-sh@vger.kernel.org

New ARM binutils don't allow extraneous whitespace inside
of brackets, which causes this error on all mach-w90x900
defconfigs:

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'

This removes the whitespace in order to build the kernel
again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>

Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: stable@vger.kernel.org

We are getting a number of warnings about the use of the deprecated
bus_to_virt function in drivers using the ARM ISA DMA API:

drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
(declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]

This is only because that function gets used by the inline
set_dma_addr() helper. We know that any driver for the ISA DMA API
is correctly using the DMA addresses, so we can change this
to use the __bus_to_virt() function instead, which does not warn.

After this, there are no remaining drivers that are used on
any defconfigs on ARM using virt_to_bus or bus_to_virt, with
the exception of the OSS sound driver. That driver is only used
on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
on all other platforms and hide the deprecated functions, which
is far more effective than marking them as deprecated, in order
to avoid any new users of that code.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>

From Nicolas Ferre:
Correction of 9x5 and 9n12 USART nodes

* tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
  ARM: at91/DT: remove atmel,use-dma-* from 9x5 and 9n12 USART nodes

This is a branch of fixes that originally were scheduled for 3.8 but
due to the request from Linus to hold back on all but the most critical
of fixes, we're re-queueing them for 3.9 here.

* fixes-for-3.9:
  ARM: dts: imx6: fix fec ptp clock slow 10 time
  ARM: highbank: mask cluster id from cpu_logical_map
  ARM: scu: mask cluster id from cpu_logical_map
  ARM: scu: add empty scu_enable for !CONFIG_SMP
  ARM: at91/at91sam9x5.dtsi: fix usart3 TXD
  ARM: at91: at91sam9x5: fix usart3 pinctrl name
  ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440
  ARM: dts: fix tick and alarm irq numbers for exynos5440
  ARM: dts: fix compatible value for exynos pinctrl
  ARM: dts: Fix compatible value of pinctrl module on EXYNOS5440
  ARM: S3C24XX: fix uninitialized variable warning
  mfd/vexpress: vexpress_sysreg_setup must not be __init
  ARM: ux500: Fix u9540 booting issues
  arm: mvebu: i2c come back in defconfig
  arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
  Dove: activate GPIO interrupts in DT
  ARM: ux500: add spin_unlock(&master_lock).
  ARM: ux500: Disable Power Supply and Battery Management by default
Signed-off-by: Olof Johansson <olof@lixom.net>

msm_smd_probe is a driver probe function and may get
called after the __init time, so it must not call
any __init function, as the link-time warning reports.
Take away the __init annotation on proc_comm_boot_wait
to fix this.

Without this patch, building msm_defconfig results in:

WARNING: vmlinux.o(.text+0xb048): Section mismatch in reference from the function msm_smd_probe() to the function .init.text:proc_comm_boot_wait()
The function msm_smd_probe() references
the function __init proc_comm_boot_wait().
This is often because msm_smd_probe lacks a __init
annotation or the annotation of proc_comm_boot_wait is wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Daniel Walker <c_dwalke@quicinc.com>
Cc: linux-arm-msm@vger.kernel.org
Acked-by: David Brown <davidb@codeaurora.org>
Signed-off-by: Olof Johansson <olof@lixom.net>

Sort the VT8500 entries in alphabetical order and add missing entries
for the files.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Signed-off-by: Olof Johansson <olof@lixom.net>

When running on Integrator/AP using atags, ap_syscon_base is initialised
in ->map_io, which isn't called for !MMU platforms.

Instead, initialise the pointer in ->machine_init, as we do when booting
with device-tree.

Cc: stable@vger.kernel.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'omap-for-v3.9/fixes-non-critical-signed-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/fixes-non-critical

From Tony Lindgren:
Few fixes for v3.9 merge window that are not urgent for
the -rc series.

* tag 'omap-for-v3.9/fixes-non-critical-signed-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: using strlcpy instead of strncpy
  ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
  ARM: OMAP: Fix the use of uninitialized dma_lch_count
  ARM: OMAP: make wakeupgen_lock raw
  + Linux 3.8-rc6

From Shawn Guo:
imx fixes for 3.8, take 4

 - It fixes fec ptp clock pointer in device tree source.

* tag 'imx-fixes-3.8-4' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: dts: imx6: fix fec ptp clock slow 10 time

From Rob Herring:
highbank fixes for 3.8

-Compile fix for !SMP
-More cpu cluster id related fixes

* tag 'highbank-fixes-for-3.8' of git://sources.calxeda.com/kernel/linux:
  ARM: highbank: mask cluster id from cpu_logical_map
  ARM: scu: mask cluster id from cpu_logical_map
  ARM: scu: add empty scu_enable for !CONFIG_SMP

Fix the use of USART on both at91sam9x5 and at91sam9n12. In DTS, the
atmel,use-dma-[rx|tx] property is present but a DMA channel cannot be used.
Indeed the connexion between the DMA engine and the slave is not implemented
yet in Device Tree.
Note however that this property is also used for PDC (private DMA) on older
SoCs. This is why the driver alone cannot determine the validity of this
property.
Reported-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [3.8+]

ptp should use enet_ref instead of pll6_enet
pll6_enet is fixed 500Mhz.
There are divider between enet_ref and pll6_enet
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

the fields must be null-terminated:
the caller may use it as null-terminted string, next.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Commit 9725f445 (ARM: OMAP: Add DT support for timer driver) added
device-tree support for selecting a clockevent timer by property.
However, the code is currently ignoring the property passed and
selecting the first available timer found. Hence, for the OMAP3 beagle
board timer-12 is not being selected as expected. Fix this problem
by ensuring the timer property is passed to omap_get_timer_dt().
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

  'omap_dma_reserve_channels' when used is suppose to be from command.
    so, it alreay has value before 1st call of omap_system_dma_probe.
    and it will never be changed again during running (not from ioctl).

  but 'dma_lch_count' is zero before 1st call of omap_system_dma_probe.
    so it will be failed for omap_dma_reserve_channels, when 1st call.

  so, need use 'd->lch_count' instead of 'dma_lch_count' for judging.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

When applying RT patch on top of Linux, spinlocks are
implemented as RT-mutexes, which means they are preemptable.

Current GIC implementation on OMAP is using a spinlock
to protect against preemption. As it turns out, we need
to convert that lock into a raw_spinlock so that OMAP's
interrupt controller works as expected after RT-patch
is applied.

This patch is simply to decrease the amount of changes
RT-team needs to carry out of tree. It doesn't cause any
changes in behavior.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Pull more device-mapper fixes from Alasdair G Kergon:
 "A fix for stacked dm thin devices and a fix for the new dm WRITE SAME
  support."

* tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
  dm: fix write same requests counting
  dm thin: fix queue limits stacking

PullHID fixes from Jiri Kosina:

 - fix i2c-hid and hidraw interaction, by Benjamin Tissoires

 - a quirk to make a particular device (Formosa IR receiver) work
   properly, by Nicholas Santos

* 'for-3.8/upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: i2c-hid: fix i2c_hid_output_raw_report
  HID: usbhid: quirk for Formosa IR receiver
  HID: remove x bit from sensor doc

Pull NFS client bugfixes from Trond Myklebust:

 - Error reporting in nfs_xdev_mount incorrectly maps all errors to
   ENOMEM

 - Fix an NFSv4 refcounting issue

 - Fix a mount failure when the server reboots during NFSv4 trunking
   discovery

 - NFSv4.1 mounts may need to run the lease recovery thread.

 - Don't silently fail setattr() requests on mountpoints

 - Fix a SUNRPC socket/transport livelock and priority queue issue

 - We must handle NFS4ERR_DELAY when resetting the NFSv4.1 session.

* tag 'nfs-for-3.8-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session
  SUNRPC: When changing the queue priority, ensure that we change the owner
  NFS: Don't silently fail setattr() requests on mountpoints
  NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery
  NFSv4: Fix NFSv4 trunking discovery
  NFSv4: Fix NFSv4 reference counting for trunked sessions
  NFS: Fix error reporting in nfs_xdev_mount

Pull MIPS updates from Ralf Baechle:
 "A number of fixes all across the MIPS tree.  No area is particularly
  standing out and things have cooled down quite nicely for a release."

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Function tracer: Fix broken function tracing
  mips: Move __virt_addr_valid() to a place for MIPS 64
  MIPS: Netlogic: Fix UP compilation on XLR
  MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE
  MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE
  MIPS: Lantiq: Fix cp0_perfcount_irq mapping
  MIPS: DSP: Fix DSP mask for registers.
  MIPS: Fix build failure by adding definition of pfn_pmd().
  MIPS: Octeon: Fix warning.
  MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__
  MIPS: PNX833x: Fix comment.
  MIPS: Add struct p_format to union mips_instruction.
  MIPS: Export <asm/break.h>.
  MIPS: BCM47xx: Enable SSB prerequisite SSB_DRIVER_PCICORE.
  MIPS: BCM47xx: Select GPIOLIB for BCMA on bcm47xx platform
  MIPS: vpe.c: Fix null pointer dereference in print arguments.

With commit a0ae0240 (ARM: kernel: add device tree init map function),
the cpu id value may include the cluster id and is no longer 0-3, so we
need to mask it now to get the right hard cpu index.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>

With commit a0ae0240 (ARM: kernel: add device tree init map function),
the cpu id value may include the cluster id and is no longer 0-3, so we
need to mask it in scu_power_mode to get the local cpu number. Since we
are only dealing with the cpu we are running on, the cluster id should
not ever be needed.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>

Add an empty version of scu_enable for !SMP builds. This fixes
compile error for highbank suspend code on !SMP builds.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>

i2c_hid_output_raw_report is used by hidraw to forward set_report requests.
The current implementation of i2c_hid_set_report needs to take the
report_id as an argument. The report_id is stored in the first byte
of the buffer in argument of i2c_hid_output_raw_report.

Not removing the report_id from the given buffer adds this byte 2 times
in the command, leading to a non working command.
Reported-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Function tracing is currently broken for all 32 bit MIPS platforms.
When tracing is enabled, the kernel immediately hangs on boot.
This is a result of commit b732d439
that changes the kernel/trace/Kconfig file so that is no longer
forces FRAME_POINTER when FUNCTION_TRACING is enabled.

MIPS frame pointers are generally considered to be useless because
they cannot be used to unwind the stack. Unfortunately the MIPS
function tracing code has bugs that are masked by the use of frame
pointers. This commit fixes the bugs so that MIPS frame pointers
don't need to be enabled.

The bugs are a result of the odd calling sequence used to call the trace
routine. This calling sequence is inserted into every traceable function
when the tracing CONFIG option is enabled. This sequence is generated
for 32bit MIPS platforms by the compiler via the "-pg" flag.

Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
call to the trace routine "_mcount" (some legacy thing where 2 arguments
used to be pushed on the stack). The _mcount routine is expected to
adjust the sp by +8 before returning.  So when not disabled, the original
jalr and addiu will be there, so _mcount has to adjust sp.

The problem is that when tracing is disabled for a function, the
"jalr _mcount" instruction is replaced with a nop, but the
"addiu sp,sp,-8" is still executed and the stack pointer is left
trashed. When frame pointers are enabled the problem is masked
because any access to the stack is done through the frame
pointer and the stack pointer is restored from the frame pointer when
the function returns.

This patch writes two nops starting at the address of the "jalr _mcount"
instruction whenever tracing is disabled. This means that the
"addiu sp,sp.-8" will be converted to a nop along with the "jalr".  When
disabled, there will be two nops.

This is SMP safe because the first time this happens is during
ftrace_init() which is before any other processor has been started.
Subsequent calls to enable/disable tracing when other CPUs ARE running
will still be safe because the enable will only change the first nop
to a "jalr" and the disable, while writing 2 nops, will only be changing
the "jalr". This patch also stops using stop_machine() to call the
tracer enable/disable routines and calls them directly because the
routines are SMP safe.

When the kernel first boots we have to be able to handle the gcc
generated jalr, addui sequence until ftrace_init gets a chance to run
and change the sequence. At this point mcount just adjusts the stack
and returns. When ftrace_init runs, we convert the jalr/addui to nops.
Then whenever tracing is enabled we convert the first nop to a "jalr
mcount+8". The mcount+8 entry point skips the stack adjust.

[ralf@linux-mips.org: Folded in  Steven Rostedt's build fix.]
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Cc: rostedt@goodmis.org
Cc: ddaney.cavm@gmail.com
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4806/
Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

When processing write same requests, fix dm to send the configured
number of WRITE SAME requests to the target rather than the number of
discards, which is not always the same.

Device-mapper WRITE SAME support was introduced by commit
23508a96 ("dm: add WRITE SAME support").
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>

Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use
virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
32, and not for MIPS 64.

When compiling for my yeeloong2, which supposedly supports hibernation,
which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
got this error:

  LD      init/built-in.o
kernel/built-in.o: In function `memory_bm_free':
snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e44c): undefined reference to `__virt_addr_valid'
kernel/built-in.o: In function `snapshot_write_next':
(.text+0x4e890): undefined reference to `__virt_addr_valid'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2

I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
mmap.c such that it gets compiled for mips 64 and 32.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

thin_io_hints() is blindly copying the queue limits from the thin-pool
which can lead to incorrect limits being set.  The fix here simply
deletes the thin_io_hints() hook which leaves the existing stacking
infrastructure to set the limits correctly.

When a thin-pool uses an MD device for the data device a thin device
from the thin-pool must respect MD's constraints about disallowing a bio
from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
chunksize is 1152K and thin-pool chunksize is 256K I see the following
md/raid0 error (with extra debug tracing added to thin_endio) when
mkfs.xfs is executed against the thin device:

md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0

This extra DM debugging shows that the failing bio is spanning across
the first and second logical 1152K chunk (sector 2080 + 255 takes the
bio beyond the first chunk's boundary of sector 2304).  So the bio
splitting that DM is doing clearly isn't respecting the MD limits.

max_hw_sectors_kb is 127 for both the thin-pool and thin device
(queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
precision).  So this explains why bi_size is 130560.

But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
that it doesn't have a .merge function (for bio_add_page to consult
indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
device that has a compulsory merge_bvec_fn.  This scenario is exactly
why DM must resort to sending single PAGE_SIZE bios to the underlying
layer. Some additional context for this is available in the header for
commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").

Long story short, the reason a thin device doesn't properly get
configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
thin_io_hints() is blindly copying the queue limits from the thin-pool
device directly to the thin device's queue limits.

Fix this by eliminating thin_io_hints.  Doing so is safe because the
block layer's queue limits stacking already enables the upper level thin
device to inherit the thin-pool device's discard and minimum_io_size and
optimal_io_size limits that get set in pool_io_hints.  But avoiding the
queue limits copy allows the thin and thin-pool limits to be different
where it is important, namely max_hw_sectors_kb.
Reported-by: Daniel Browning <db@kavod.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alasdair G Kergon <agk@redhat.com>

Pull x86 EFI fixes from Peter Anvin:
 "This is a collection of fixes for the EFI support.  The controversial
  bit here is a set of patches which bumps the boot protocol version as
  part of fixing some serious problems with the EFI handover protocol,
  used when booting under EFI using a bootloader as opposed to directly
  from EFI.  These changes should also make it a lot saner to support
  cross-mode 32/64-bit EFI booting in the future.  Getting these changes
  into 3.8 means we avoid presenting an inconsistent ABI to bootloaders.

  Other changes are display detection and fixing efivarfs."

* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, efi: remove attribute check from setup_efi_pci
  x86, build: Dynamically find entry points in compressed startup code
  x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode
  x86, efi: Fix 32-bit EFI handover protocol entry point
  x86, efi: Fix display detection in EFI boot stub
  x86, boot: Define the 2.12 bzImage boot protocol
  x86/boot: Fix minor fd leakage in tools/relocs.c
  x86, efi: Set runtime_version to the EFI spec revision
  x86, efi: fix 32-bit warnings in setup_efi_pci()
  efivarfs: Delete dentry from dcache in efivarfs_file_write()
  efivarfs: Never return ENOENT from firmware
  efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
  efivarfs: Drop link count of the right inode