ARM: digicolor: add the machine directory to Makefile

Make the digicolor specific DT_MACHINE_START entry visible.

Fixes: df8d742e929 (ARM: initial support for Conexant Digicolor CX92755 SoC)
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'fixes-v4.0-rc2' of git://git./linux/kernel/git/tmlind/linux-omap into fixes

Pull "omap fixes against v4.0-rc2" from Tony Lindgren:

Fixes for various omap variants, mostly minor fixes for various SoCs
with the bigger changes being for the dra7 clocks and hwmod data:

- Fix wl12xx for dm3730-evm

- Fix omap4 prm save and clea

- Fix hwmod clkdm use count

- Fix hwmod data for pcie on dra7

- Fix lockdep for hwmod

- Fix USB on most omap3 boars by enabling it in the defconfig

- Fix the bypass clock source for omap5 and dra7

- Fix the ehrpwm clock for am33xx and am43xx

- Enable AES and SHAM for BeagleBone white

- Use rmii clock for am335x-lxm

- Fix polling intervals for omap5 thermal zones

- Fix slewctrl for am33xx and am43xx

- Fix dra7-evm dcan pinctrl

* tag 'fixes-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot
  ARM: OMAP: enable TWL4030_USB in omap2plus_defconfig
  ARM: dts: dra7x-evm: avoid possible contention while muxing on CAN lines
  ARM: dts: dra7x-evm: Don't use dcan1_rx.gpio1_15 in DCAN pinctrl
  ARM: dts: am43xx: fix SLEWCTRL_FAST pinctrl binding
  ARM: dts: am33xx: fix SLEWCTRL_FAST pinctrl binding
  ARM: dts: OMAP5: fix polling intervals for thermal zones
  ARM: dts: am335x-lxm: Use rmii-clock-ext
  ARM: dts: am335x-bone-common: enable aes and sham
  ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx
  ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
  ARM: dts: OMAP5: Fix the bypass clock source for dpll_iva and others
  ARM: dts: DRA7x: Fix the bypass clock source for dpll_iva and others
  ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen
  ARM: OMAP2+: hwmod: fix deassert hardreset clkdm usecounting
  ARM: DRA7: hwmod_data: Fix hwmod data for pcie
  ARM: omap2+: omap_hwmod: Set unique lock_class_key per hwmod

ARM: STi: Add STiH410 SoC support

This patch adds support to STiH410 SoC.

Please note "st,stih410" is already present in device tree.
The problem is that it is missing the entry in the match table,
and so the L2 cache and other cpus than 0 don't get initialized.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Tested-by: Maxime Coquelin <maxime.coquelin@st.com>
Acked-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

xen-pciback: limit guest control of command register

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.

Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.

This is CVE-2015-2150 / XSA-120.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Merge tag 'at91-fixes2' of git://git./linux/kernel/git/nferre/linux-at91 into fixes

Pull "Second fixes batch for AT91 on 4.0" from Nicolas Ferre:

- little fix for !MMU debug: may also help for randconfig
- fix of 2 errors in LCD clock definitions
- in PM code, not writing the key leads to not execute the action

* tag 'at91-fixes2' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91:
  ARM: at91/pm: MOR register KEY was missing
  ARM: at91/dt: sama5d4: fix lcdck clock definition
  ARM: at91/dt: sama5d4: rename lcd_clk into lcdc_clk
  ARM: at91: debug: fix non MMU debug

Merge tag 'socfpga_fixes_for_v4.0' of git://git.rocketboards.org/linux-socfpga-next into fixes

Pull "Fixes for v4.0 on the SoCFPGA platform" from Dinh Nguyen:

- Fix the SCU virtual mapping
- Add misssing DMA channels for UART nodes
- Fix a sporadic SMP error where CPU1 was not seeing its start address

* tag 'socfpga_fixes_for_v4.0' of git://git.rocketboards.org/linux-socfpga-next:
  ARM: socfpga: make sure socfpga_cpu1start_addr is properly flushed
  ARM: socfpga: fix uart DMA binding error
  ARM: socfpga: Correct SCU virtual mapping in socfpga

MAINTAINERS: add Freescale Vybrid SoC

Add Freescale Vybrid family as a own entry, along with an entry for
the so far orphan Vybrid device tree files. Also add myself as
a designated reviewer.

Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

MAINTAINERS: Remove self as ARM mach-bcm co-maintainer

Removing myself as a co-maintainer.

Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

arm64: KVM: Fix outdated comment about VTCR_EL2.PS

Commit 87366d8cf7b3 ("arm64: Add boot time configuration of
Intermediate Physical Address size") removed the hardcoded setting
of VTCR_EL2.PS to use ID_AA64MMFR0_EL1.PARange instead, but didn't
remove the (now rather misleading) comment.

Fix the comments to match reality (at least for the next few minutes).

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

arm64: KVM: Do not use pgd_index to index stage-2 pgd

The kernel's pgd_index macro is designed to index a normal, page
sized array. KVM is a bit diffferent, as we can use concatenated
pages to have a bigger address space (for example 40bit IPA with
4kB pages gives us an 8kB PGD.

In the above case, the use of pgd_index will always return an index
inside the first 4kB, which makes a guest that has memory above
0x8000000000 rather unhappy, as it spins forever in a page fault,
whist the host happilly corrupts the lower pgd.

The obvious fix is to get our own kvm_pgd_index that does the right
thing(tm).

Tested on X-Gene with a hacked kvmtool that put memory at a stupidly
high address.

Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting

We're using __get_free_pages with to allocate the guest's stage-2
PGD. The standard behaviour of this function is to return a set of
pages where only the head page has a valid refcount.

This behaviour gets us into trouble when we're trying to increment
the refcount on a non-head page:

page:ffff7c00cfb693c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x4000000000000000()
page dumped because: VM_BUG_ON_PAGE((*({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) *)&((&page->_count)->counter); })) <= 0)
BUG: failure at include/linux/mm.h:548/get_page()!
Kernel panic - not syncing: BUG!
CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[<ffff80000008a09c>] dump_backtrace+0x0/0x13c
[<ffff80000008a1e8>] show_stack+0x10/0x1c
[<ffff800000691da8>] dump_stack+0x74/0x94
[<ffff800000690d78>] panic+0x100/0x240
[<ffff8000000a0bc4>] stage2_get_pmd+0x17c/0x2bc
[<ffff8000000a1dc4>] kvm_handle_guest_abort+0x4b4/0x6b0
[<ffff8000000a420c>] handle_exit+0x58/0x180
[<ffff80000009e7a4>] kvm_arch_vcpu_ioctl_run+0x114/0x45c
[<ffff800000099df4>] kvm_vcpu_ioctl+0x2e0/0x754
[<ffff8000001c0a18>] do_vfs_ioctl+0x424/0x5c8
[<ffff8000001c0bfc>] SyS_ioctl+0x40/0x78
CPU0: stopping

A possible approach for this is to split the compound page using
split_page() at allocation time, and change the teardown path to
free one page at a time.  It turns out that alloc_pages_exact() and
free_pages_exact() does exactly that.

While we're at it, the PGD allocation code is reworked to reduce
duplication.

This has been tested on an X-Gene platform with a 4kB/48bit-VA host
kernel, and kvmtool hacked to place memory in the second page of
the hardware PGD (PUD for the host kernel). Also regression-tested
on a Cubietruck (Cortex-A7).

 [ Reworked to use alloc_pages_exact() and free_pages_exact() and to
   return pointers directly instead of by reference as arguments
    - Christoffer ]

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

drm/radeon: drop setting UPLL to sleep mode

Just keep it working, seems to fix some PLL problems.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fix wait to actually occur after the signaling callback

A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.

This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com>
Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com>
Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com>
Cc: stable@vger.kernel.org (v3.18+)
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

ARM: imx6sl-evk: set swbst_reg as vbus's parent reg

USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.

Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

ARM: imx6qdl-sabresd: set swbst_reg as vbus's parent reg

USB vbus 5V is from PMIC SWBST, so set swbst_reg as vbus's
parent reg, it fixed a bug that the voltage of vbus is incorrect
due to swbst_reg is disabled after boots up.

Cc: stable@vger.kernel.org
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

Merge tag 'for-linus-20150310' of git://git.infradead.org/linux-mtd

Pull MTD fixes from Brian Norris:

 * pxa3xx_nand
   - fix timeout issues when draining the FIFO (BCH only)
   - don't crash when no chip-selects are used

 * hisi504_nand
   - depend on HAS_DMA, to fix compile errors

* tag 'for-linus-20150310' of git://git.infradead.org/linux-mtd:
  mtd: nand: MTD_NAND_HISI504 should depend on HAS_DMA
  mtd: pxa3xx_nand: fix driver when num_cs is 0
  mtd: nand: pxa3xx: Fix PIO FIFO draining

Merge tag 'iommu-fixes-v4.0-rc3' of git://git./linux/kernel/git/joro/iommu

Pull iommu fixes from Joerg Roedel:
 "The patches contain:

   - fix multiple ARM IOMMU drivers to behave well when the hardware is
     not present

   - mark MSM driver as broken

   - fix build errors with the new ARM generic io-page-table code"

* tag 'iommu-fixes-v4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/io-pgtable-arm: Add built time dependency
  iommu/msm: Mark driver BROKEN
  iommu/rockchip: Play nice in multi-platform builds
  iommu/omap: Play nice in multi-platform builds
  iommu/exynos: Play nice in multi-platform builds
  iommu/io-pgtable-arm: Fix self-test WARNs on i386

kvm: move advertising of KVM_CAP_IRQFD to common code

POWER supports irqfds but forgot to advertise them.  Some userspace does
not check for the capability, but others check it---thus they work on
x86 and s390 but not POWER.

To avoid that other architectures in the future make the same mistake, let
common code handle KVM_CAP_IRQFD the same way as KVM_CAP_IRQFD_RESAMPLE.

Reported-and-tested-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Fixes: 297e21053a52f060944e9f0de4c64fad9bcd72fc
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>

of: unittest: Add options string testcase variants

Add testcase variants with '/' in the options string to test for
scan beyond end path name terminated by ':'.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Rob Herring <robh@kernel.org>

of: fix handling of '/' in options for of_find_node_by_path()

Ensure proper handling of paths with appended options (after ':'),
where those options may contain a '/'.

Fixes: 7914a7c5651a ("of: support passing console options with stdout-path")
Reported-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: <stable@vger.kernel.org> # 3.19
Signed-off-by: Rob Herring <robh@kernel.org>

of/unittest: Fix the wrong expected value in of_selftest_property_string

This patch fix the wrong expected value of of_property_match_string
in of_selftest_property_string.

Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Rob Herring <robh@kernel.org>

of/unittest: remove the duplicate of_changeset_init

Remove the duplicate of_changeset_init. In of_selftest_changeset
testcase, the "struct of_changeset chgset" is initialized twice,
but only once is enough. so, drop the first initializtion code.

Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Rob Herring <robh@kernel.org>

dt: submitting-patches: clarify that DT maintainers are to be cced on bindings

The exact steps provided for submitting binding patches can be read
as requiring the bindings to be sent only to the devicetree@vger.kernel.org
list. Since the DT maintainers would like to be Cced on any binding
submissions, make this requirement explicit in step 2.

Signed-off-by: Matt Porter <mporter@konsulko.com>
Signed-off-by: Rob Herring <robh@kernel.org>

of: unittest: fix I2C dependency

The unittest fails to link if I2C or I2C_MUX is a loadable module:

  drivers/built-in.o: In function `selftest_i2c_mux_remove':
  unittest.c:(.text+0xb0ce4): undefined reference to `i2c_del_mux_adapter'

This changes the newly added IS_ENABLED() checks to use IS_BUILTIN()
instead, which evaluates to false if the other driver is a module.

Reported-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: d5e75500ca401 ("of: unitest: Add I2C overlay unit tests.")
Signed-off-by: Rob Herring <robh@kernel.org>

of/overlay: Remove unused variable

Commit 3e7f7626fd49a ("of/overlay: Do not generate duplicate nodes") removed
the only use of the 'grandchild' variable, which leads to the following build
warning:

drivers/of/overlay.c: In function 'of_overlay_apply_single_device_node':
drivers/of/overlay.c:89:31: warning: unused variable 'grandchild' [-Wunused-variable]
  struct device_node *tchild, *grandchild;
                               ^

Remove this unused variable.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Rob Herring <robh@kernel.org>

Documentation: DT: Renamed of-serial.txt to 8250.txt

The file of-serial.txt was only for 8250 compatible UART implementations,
so renamed it to 8250.txt to avoid confusing other persons.
This is suggested by Arnd, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/291455.html

Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>

of: Fix premature bootconsole disable with 'stdout-path'

Support for devicetree serial consoles via 'stdout-path' causes
bootconsoles to be disabled when the vt dummy console loads, since
there is no preferred console (the preferred console is not added
until the device is probed).

Ensure there is at least a preferred console, even if never matched.

Requires: "console: Fix console name size mismatch"
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Rob Herring <robh@kernel.org>

ALSA: firewire-lib: leave unit reference counting completely

With previous commit, this module managed to leave the counting to each
drivers, but the isochronous resources functionality still increment/decrement
the count.

This commit purge such codes to leave the responsibility to each drivers.

Fix: c6f224dc20ad ('ALSA: firewire-lib: remove reference counting')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Revert "ALSA: dice: fix wrong offsets for Dice interface"

This reverts commit 8cdebf71098c07168ef6335e2f1f35d85dbe3049.

The reverted commit breaks out-stream functionality of Dice driver.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge tag 'v4.0-rc3' into HEAD

Linux 4.0-rc3

Merging in v4.0-rc3 because commit 30a22c215a00 (console: Fix
console name size mismatch) is a dependency.

drm/i915: Prevent TLB error on first execution on SNB

Long ago I found that I was getting sporadic errors when booting SNB,
with the symptom being that the first batch died with IPEHR != *ACTHD,
typically caused by the TLB being invalid. These magically disappeared
if I held the forcewake during the entire ring initialisation sequence.
(It can probably be shortened to a short critical section, but the whole
initialisation is full of register writes and so we would be taking and
releasing forcewake almost continually, and so holding it over the
entire sequence will probably be a net win!)

Note some of the kernels I encounted the issue already had the deferred
forcewake release, so it is still relevant.

I know that there have been a few other reports with similar failure
conditions on SNB, I think such as
References: https://bugs.freedesktop.org/show_bug.cgi?id=80913

v2: Wrap i915_gem_init_hw() with its own security blanket as we take
that path following resume and reset.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Do both mt and gen6 style forcewake reset on ivb probe

commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.

Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again

This fixes a regression from

commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jul 16 21:05:06 2014 +0000

    drm: i915: Use nsec based interfaces

that made a negative timeout return immediately rather than the
previously defined behaviour of waiting indefinitely.

Testcase: igt/gem_wait
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89494
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: fixed a checkpatch complaint about whitespace.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: use in_interrupt() not in_irq() to check context

The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.

We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/mst: fix recursive sleep warning on qlock

With drm-next, we can get a backtrace from sleeping
with mutex detection.

this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,

Daniel went over it and was happy we could drop this mutex
in this case.

Signed-off-by: Dave Airlie <airlied@redhat.com>

x86/asm/entry/32: Fix user_mode() misuses

The one in do_debug() is probably harmless, but better safe than sorry.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/d67deaa9df5458363623001f252d1aee3215d014.1425948056.git.luto@amacapital.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm/s390 bugfixes from Marcelo Tosatti.

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: s390: non-LPAR case obsolete during facilities mask init
  KVM: s390: include guest facilities in kvm facility test
  KVM: s390: fix in memory copy of facility lists
  KVM: s390/cpacf: Fix kernel bug under z/VM
  KVM: s390/cpacf: Enable key wrapping by default

Merge branch 'for-linus' of git://git./linux/kernel/git/s390/linux

Pull s390 fixes from Martin Schwidefsky:
 "One performance optimization for page_clear and a couple of bug fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/mm: fix incorrect ASCE after crst_table_downgrade
  s390/ftrace: fix crashes when switching tracers / add notrace to cpu_relax()
  s390/pci: unify pci_iomap symbol exports
  s390/pci: fix [un]map_resources sequence
  s390: let the compiler do page clearing
  s390/pci: fix possible information leak in mmio syscall
  s390/dcss: array index 'i' is used before limits check.
  s390/scm_block: fix off by one during cluster reservation
  s390/jump label: improve and fix sanity check
  s390/jump label: add missing jump_label_apply_nops() call

drm: Don't assign fbs for universal cursor support to files

The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in

commit 161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Jun 10 08:28:10 2014 -0700

    drm: Support legacy cursor ioctls via universal planes when possible (v4)

The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.

Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'trace-fixes-v4.0-rc2-2' of git://git./linux/kernel/git/rostedt/linux-trace

Pull seq-buf/ftrace fixes from Steven Rostedt:
 "This includes fixes for seq_buf_bprintf() truncation issue.  It also
  contains fixes to ftrace when /proc/sys/kernel/ftrace_enabled and
  function tracing are started.  Doing the following causes some issues:

    # echo 0 > /proc/sys/kernel/ftrace_enabled
    # echo function_graph > /sys/kernel/debug/tracing/current_tracer
    # echo 1 > /proc/sys/kernel/ftrace_enabled
    # echo nop > /sys/kernel/debug/tracing/current_tracer
    # echo function_graph > /sys/kernel/debug/tracing/current_tracer

  As well as with function tracing too.  Pratyush Anand first reported
  this issue to me and supplied a patch.  When I tested this on my x86
  test box, it caused thousands of backtraces and warnings to appear in
  dmesg, which also caused a denial of service (a warning for every
  function that was listed).  I applied Pratyush's patch but it did not
  fix the issue for me.  I looked into it and found a slight problem
  with trampoline accounting.  I fixed it and sent Pratyush a patch, but
  he said that it did not fix the issue for him.

  I later learned tha Pratyush was using an ARM64 server, and when I
  tested on my ARM board, I was able to reproduce the same issue as
  Pratyush.  After applying his patch, it fixed the problem.  The above
  test uncovered two different bugs, one in x86 and one in ARM and
  ARM64.  As this looked like it would affect PowerPC, I tested it on my
  PPC64 box.  It too broke, but neither the patch that fixed ARM or x86
  fixed this box (the changes were all in generic code!).  The above
  test, uncovered two more bugs that affected PowerPC.  Again, the
  changes were only done to generic code.  It's the way the arch code
  expected things to be done that was different between the archs.  Some
  where more sensitive than others.

  The rest of this series fixes the PPC bugs as well"

* tag 'trace-fixes-v4.0-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled
  ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl
  ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl
  seq_buf: Fix seq_buf_bprintf() truncation
  seq_buf: Fix seq_buf_vprintf() truncation

virtio-balloon: do not call blocking ops when !TASK_RUNNING

virtio balloon has this code:
        wait_event_interruptible(vb->config_change,
                                 (diff = towards_target(vb)) != 0
                                 || vb->need_stats_update
                                 || kthread_should_stop()
                                 || freezing(current));

Which is a problem because towards_target() call might block after
wait_event_interruptible sets task state to TAST_INTERRUPTIBLE, causing
the task_struct::state collision typical of nesting of sleeping
primitives

See also http://lwn.net/Articles/628628/ or Thomas's
bug report
http://article.gmane.org/gmane.linux.kernel.virtualization/24846
for a fuller explanation.

To fix, rewrite using wait_woken.

Cc: stable@vger.kernel.org
Reported-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

virtio_blk: fix comment for virtio 1.0

Fix up comment to match virtio 1.0 logic:
virtio_blk_outhdr isn't the first elements anymore,
the only requirement is that it comes first in
the s/g list.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

virtio_blk: typo fix

Now that QEmu reuses linux virtio headers, we noticed
a typo in the exported virtio block header. Fix it up.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

virtio_balloon: set DRIVER_OK before using device

virtio spec requires that all drivers set DRIVER_OK
before using devices. While balloon isn't yet
included in the virtio 1 spec, previous spec versions
also required this.

virtio balloon might violate this rule: probe calls
kthread_run before setting DRIVER_OK, which might run
immediately and cause balloon to inflate/deflate.

To fix, call virtio_device_ready before running the kthread.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org

Merge git://git./linux/kernel/git/davem/net

Pull networking fixes from David Miller:

 1) nft_compat accidently truncates ethernet protocol to 8-bits, from
    Arturo Borrero.

 2) Memory leak in ip_vs_proc_conn(), from Julian Anastasov.

 3) Don't allow the space required for nftables rules to exceed the
    maximum value representable in the dlen field.  From Patrick
    McHardy.

 4) bcm63xx_enet can accidently leave interrupts permanently disabled
    due to errors in the NAPI polling exit logic.  Fix from Nicolas
    Schichan.

 5) Fix OOPSes triggerable by the ping protocol module, due to missing
    address family validations etc.  From Lorenzo Colitti.

 6) Don't use RCU locking in sleepable context in team driver, from Jiri
    Pirko.

 7) xen-netback miscalculates statistic offset pointers when reporting
    the stats to userspace.  From David Vrabel.

 8) Fix a leak of up to 256 pages per VIF destroy in xen-netaback, also
    from David Vrabel.

 9) ip_check_defrag() cannot assume that skb_network_offset(),
    particularly when it is used by the AF_PACKET fanout defrag code.
    From Alexander Drozdov.

10) gianfar driver doesn't query OF node names properly when trying to
    determine the number of hw queues available.  Fix it to explicitly
    check for OF nodes named queue-group.  From Tobias Waldekranz.

11) MID field in macb driver should be 12 bits, not 16.  From Punnaiah
    Choudary Kalluri.

12) Fix unintentional regression in traceroute due to timestamp socket
    option changes.  Empty ICMP payloads should be allowed in
    non-timestamp cases.  From Willem de Bruijn.

13) When devices are unregistered, we have to get rid of AF_PACKET
    multicast list entries that point to it via ifindex.  Fix from
    Francesco Ruggeri.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (38 commits)
  tipc: fix bug in link failover handling
  net: delete stale packet_mclist entries
  net: macb: constify macb configuration data
  MAINTAINERS: add Marc Kleine-Budde as co maintainer for CAN networking layer
  MAINTAINERS: linux-can moved to github
  can: kvaser_usb: Read all messages in a bulk-in URB buffer
  can: kvaser_usb: Avoid double free on URB submission failures
  can: peak_usb: fix missing ctrlmode_ init for every dev
  can: add missing initialisations in CAN related skbuffs
  ip: fix error queue empty skb handling
  bgmac: Clean warning messages
  tcp: align tcp_xmit_size_goal() on tcp_tso_autosize()
  net: fec: fix unbalanced clk disable on driver unbind
  net: macb: Correct the MID field length value
  net: gianfar: correctly determine the number of queue groups
  ipv4: ip_check_defrag should not assume that skb_network_offset is zero
  net: bcmgenet: properly disable password matching
  net: eth: xgene: fix booting with devicetree
  bnx2x: Force fundamental reset for EEH recovery
  xen-netback: refactor xenvif_handle_frag_list()
  ...

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input subsystem fixes from Dmitry Torokhov:
 "Miscellaneous driver fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: psmouse - disable "palm detection" in the focaltech driver
  Input: psmouse - disable changing resolution/rate/scale for FocalTech
  Input: psmouse - ensure that focaltech reports consistent coordinates
  Input: psmouse - remove hardcoded touchpad size from the focaltech driver
  Input: tc3589x-keypad - set IRQF_ONESHOT flag to ensure IRQ request
  Input: ALPS - fix memory leak when detection fails
  Input: sun4i-ts - add thermal driver dependency
  Input: cyapa - remove superfluous type check in cyapa_gen5_read_idac_data()
  Input: cyapa - fix unaligned functions redefinition error
  Input: mma8450 - add parent device

Merge tag 'regulator-v4.0-rc2' of git://git./linux/kernel/git/broonie/regulator

Pull regulator fixes from Mark Brown:
 "A couple of driver specific fixes plus a fix for a regression in the
  core where the updates to use sysfs group registration were overly
  enthusiastic in eliding properties and removed some that had been
  previously present"

* tag 'regulator-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: Fix regression due to NULL constraints check
  regulator: rk808: Set the enable time for LDOs
  regulator: da9210: Mask all interrupt sources to deassert interrupt line

Merge tag 'spi-v4.0-rc2' of git://git./linux/kernel/git/broonie/spi

Pull spi fixes from Mark Brown:
 "A collection of driver specific fixes to which the usual comments
  about them being important if you see them mostly apply (except for
  the comment fix).  The pl022 one is particularly nasty for anyone
  affected by it"

* tag 'spi-v4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: pl022: Fix race in giveback() leading to driver lock-up
  spi: dw-mid: avoid potential NULL dereference
  spi: img-spfi: Verify max spfi transfer length
  spi: fix a typo in comment.
  spi: atmel: Fix interrupt setup for PDC transfers
  spi: dw: revisit FIFO size detection again
  spi: dw-pci: correct number of chip selects
  drivers: spi: ti-qspi: wait for busy bit clear before data write/read

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/linux-security

Pull tpm fixes from James Morris:
 "fixes for the TPM driver"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  tpm: fix call order in tpm-chip.c
  tpm/ibmvtpm: Additional LE support for tpm_ibmvtpm_send

Merge tag 'fbdev-fixes-4.0' of git://git./linux/kernel/git/tomba/linux

Pull fbdev fixes from Tomi Valkeinen:
 - Fix regression in with omapdss when using i2c displays
 - Fix possible null deref in fbmon
 - Check kalloc return value in AMBA CLCD

* tag 'fbdev-fixes-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  OMAPDSS: fix regression with display sysfs files
  video: fbdev: fix possible null dereference
  video: ARM CLCD: Add missing error check for devm_kzalloc

Merge branch 'for-4.0-fixes' of git://git./linux/kernel/git/tj/cgroup

Pull cgroup fixes from Tejun Heo:
 "The cgroup iteration update two years ago and the recent cpuset
  restructuring introduced regressions in subset of cpuset
  configurations.  Three patches to fix them.

  All are marked for -stable"

* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cpuset: Fix cpuset sched_relax_domain_level
  cpuset: fix a warning when clearing configured masks in old hierarchy
  cpuset: initialize effective masks when clone_children is enabled

Merge branch 'for-4.0-fixes' of git://git./linux/kernel/git/tj/libata

Pull libata fixlet from Tejun Heo:
 "Speed limiting fix for sata_fsl"

* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  sata-fsl: Apply link speed limits

Merge branch 'for-4.0-fixes' of git://git./linux/kernel/git/tj/wq

Pull workqueue fix from Tejun Heo:
 "One fix patch for a subtle livelock condition which can happen on
  PREEMPT_NONE kernels involving two racing cancel_work calls.  Whoever
  comes in the second has to wait for the previous one to finish.  This
  was implemented by making the later one block for the same condition
  that the former would be (work item completion) and then loop and
  retest; unfortunately, depending on the wake up order, the later one
  could lock out the former one to finish by busy looping on the cpu.

  This is fixed by implementing explicit wait mechanism.  Work item
  might not belong anywhere at this point and there's remote possibility
  of thundering herd problem.  I originally tried to use bit_waitqueue
  but it didn't work for static work items on modules.  It's currently
  using single wait queue with filtering wake up function and exclusive
  wakeup.  If this ever becomes a problem, which is not very likely, we
  can try to figure out a way to piggy back on bit_waitqueue"

* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE

ACPI / LPSS: provide con_id for the clkdev

Commit 7d78cbefaa (serial: 8250_dw: add ability to handle
the peripheral clock) introduces handling for a second clk
to 8250_dw.c which is the driver also for LPSS UART. The
second clk forces us to provide identifier (con_id) for the
clkdev we create.

This fixes an issue where 8250_dw.c is getting the same
handler for both clocks.

Fixes: 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock)
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: 3.17+ <stable@vger.kernel.org> # 3.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

clk: divider: fix calculation of initial best divider when rounding to closest

Similar to the reasoning for the previous commit

DIV_ROUND_CLOSEST(parent_rate, rate)

might not be the best integer divisor to get a good approximation for
rate from parent_rate (given the metric for CLK_DIVIDER_ROUND_CLOSEST).

For example assume a parent rate of 1000 Hz and a target rate of 700.
Using DIV_ROUND_CLOSEST the suggested divisor gets calculated to 1
resulting in a target rate of 1000 with a delta of 300 to the desired
rate. With choosing 2 as divisor however the resulting rate is 500 which
is nearer to 700.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>

clk: divider: fix selection of divider when rounding to closest

It's an invalid approach to assume that among two divider values
the one nearer the exact divider is the better one.

Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
the better divider as 62.5 is nearer to 89 than 125 is.

Fixes: 774b514390b1 (clk: divider: Add round to closest divider)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>

clk: divider: fix calculation of maximal parent rate for a given divider

The rate provided at the output of a clk-divider is calculated as:

DIV_ROUND_UP(parent_rate, div)

since commit b11d282dbea2 (clk: divider: fix rate calculation for
fractional rates). So to yield a rate not bigger than r parent_rate
must be <= r * div.

The effect of choosing a parent rate that is too big as was done before
this patch results in wrongly ruling out good dividers.

Note that this is not a complete fix as __clk_round_rate might return a
value >= its 2nd parameter. Also for dividers with
CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this
fixes the test case by Sascha Hauer that uses a chain of three dividers
under a fixed clock.

Fixes: b11d282dbea2 (clk: divider: fix rate calculation for fractional rates)
Suggested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Michael Turquette <mturquette@linaro.org>

tipc: fix bug in link failover handling

In commit c637c1035534867b85b78b453c38c495b58e2c5a
("tipc: resolve race problem at unicast message reception") we
introduced a new mechanism for delivering buffers upwards from link
to socket layer.

That code contains a bug in how we handle the new link input queue
during failover. When a link is reset, some of its users may be blocked
because of congestion, and in order to resolve this, we add any pending
wakeup pseudo messages to the link's input queue, and deliver them to
the socket. This misses the case where the other, remaining link also
may have congested users. Currently, the owner node's reference to the
remaining link's input queue is unconditionally overwritten by the
reset link's input queue. This has the effect that wakeup events from
the remaining link may be unduely delayed (but not lost) for a
potentially long period.

We fix this by adding the pending events from the reset link to the
input queue that is currently referenced by the node, whichever one
it is.

This commit should be applied to both net and net-next.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: delete stale packet_mclist entries

When an interface is deleted from a net namespace the ifindex in the
corresponding entries in PF_PACKET sockets' mclists becomes stale.
This can create inconsistencies if later an interface with the same ifindex
is moved from a different namespace (not that unlikely since ifindexes are
per-namespace).
In particular we saw problems with dev->promiscuity, resulting
in "promiscuity touches roof, set promiscuity failed. promiscuity
feature of device might be broken" warnings and EOVERFLOW failures of
setsockopt(PACKET_ADD_MEMBERSHIP).
This patch deletes the mclist entries for interfaces that are deleted.
Since this now causes setsockopt(PACKET_DROP_MEMBERSHIP) to fail with
EADDRNOTAVAIL if called after the interface is deleted, also make
packet_mc_drop not fail.

Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: macb: constify macb configuration data

The configurations are not modified by the driver.  Make them 'const' so
that they may be placed in a read-only section.

Signed-off-by: Josh Cartwright <joshc@ni.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'linux-can-fixes-for-4.0-20150309' of git://git./linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
pull-request: can 2015-03-09

this is a pull request for net/master for the 4.0 release cycle, it consists of
6 patches:

A patch by Oliver Hartkopp fixes a long outstanding bug in the infrastructure,
which leads to skb_under_panics when CAN interfaces are used by AF_PACKET
sockets e.g. by dhclient. Stephane Grosjean contributes a patch for the
peak_usb driver which adds a missing initialization. Two patches by Ahmed S.
Darwish fix problems in the kvaser_usb driver. Followed by two patches by
myself, updating the MAINTAINERS file
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled

Some archs (specifically PowerPC), are sensitive with the ordering of
the enabling of the calls to function tracing and setting of the
function to use to be traced.

That is, update_ftrace_function() sets what function the ftrace_caller
trampoline should call. Some archs require this to be set before
calling ftrace_run_update_code().

Another bug was discovered, that ftrace_startup_sysctl() called
ftrace_run_update_code() directly. If the function the ftrace_caller
trampoline changes, then it will not be updated. Instead a call
to ftrace_startup_enable() should be called because it tests to see
if the callback changed since the code was disabled, and will
tell the arch to update appropriately. Most archs do not need this
notification, but PowerPC does.

The problem could be seen by the following commands:

 # echo 0 > /proc/sys/kernel/ftrace_enabled
 # echo function > /sys/kernel/debug/tracing/current_tracer
 # echo 1 > /proc/sys/kernel/ftrace_enabled
 # cat /sys/kernel/debug/tracing/trace

The trace will show that function tracing was not active.

Cc: stable@vger.kernel.org # 2.6.27+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl

When ftrace is enabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when
ftrace is disabled globally through the proc interface, we must check if
ftrace_graph_active is set. If it is set, then we should also pass the
FTRACE_STOP_FUNC_RET command to ftrace_run_update_code().

Consider the following situation.

 # echo 0 > /proc/sys/kernel/ftrace_enabled

After this ftrace_enabled = 0.

 # echo function_graph > /sys/kernel/debug/tracing/current_tracer

Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never
called.

 # echo 1 > /proc/sys/kernel/ftrace_enabled

Now ftrace_enabled will be set to true, but still
ftrace_enable_ftrace_graph_caller() will not be called, which is not
desired.

Further if we execute the following after this:
  # echo nop > /sys/kernel/debug/tracing/current_tracer

Now since ftrace_enabled is set it will call
ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on
the ARM platform.

On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called,
it checks whether the old instruction is a nop or not. If it's not a nop,
then it returns an error. If it is a nop then it replaces instruction at
that address with a branch to ftrace_graph_caller.
ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore,
if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller()
or ftrace_disable_ftrace_graph_caller() consecutively two times in a row,
then it will return an error, which will cause the generic ftrace code to
raise a warning.

Note, x86 does not have an issue with this because the architecture
specific code for ftrace_enable_ftrace_graph_caller() and
ftrace_disable_ftrace_graph_caller() does not check the previous state,
and calling either of these functions twice in a row has no ill effect.

Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com
Cc: stable@vger.kernel.org # 2.6.31+
Signed-off-by: Pratyush Anand <panand@redhat.com>
[
  removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0
  if CONFIG_FUNCTION_GRAPH_TRACER is not set.
]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl

When /proc/sys/kernel/ftrace_enabled is set to zero, all function
tracing is disabled. But the records that represent the functions
still hold information about the ftrace_ops that are hooked to them.

ftrace_ops may request "REGS" (have a full set of pt_regs passed to
the callback), or "TRAMP" (the ops has its own trampoline to use).
When the record is updated to represent the state of the ops hooked
to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback
points to the correct trampoline (REGS has its own trampoline).

When ftrace_enabled is set to zero, all ftrace locations are a nop,
so they do not point to any trampoline. But the _EN flags are still
set. This can cause the accounting to go wrong when ftrace_enabled
is cleared and an ops that has a trampoline is registered or unregistered.

For example, the following will cause ftrace to crash:

 # echo function_graph > /sys/kernel/debug/tracing/current_tracer
 # echo 0 > /proc/sys/kernel/ftrace_enabled
 # echo nop > /sys/kernel/debug/tracing/current_tracer
 # echo 1 > /proc/sys/kernel/ftrace_enabled
 # echo function_graph > /sys/kernel/debug/tracing/current_tracer

As function_graph uses a trampoline, when ftrace_enabled is set to zero
the updates to the record are not done. When enabling function_graph
again, the record will still have the TRAMP_EN flag set, and it will
look for an op that has a trampoline other than the function_graph
ops, and fail to find one.

Cc: stable@vger.kernel.org # 3.17+
Reported-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Merge branch 'for-current' of https://github.com/PeterHuewe/linux-tpmdd into for-linus

ARM: at91/dt: at91sam9261: fix clocks and clock-names in udc definition

Peripheral clock is named pclk and system clock is named hclk (those are
the names expected by the at91_udc driver).

Drop the deprecated usb_clk (formerly used to configure the usb clock rate
which is now directly configurable through hclk).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>

MAINTAINERS: add Marc Kleine-Budde as co maintainer for CAN networking layer

This patch adds Marc Kleine-Budde as a co maintainer for the CAN networking
layer.

Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

MAINTAINERS: linux-can moved to github

As gitorious will shut down at the end of May 2015, the linux-can website moved
to github. This patch reflects this change.

Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

can: kvaser_usb: Read all messages in a bulk-in URB buffer

The Kvaser firmware can only read and write messages that are
not crossing the USB endpoint's wMaxPacketSize boundary. While
receiving commands from the CAN device, if the next command in
the same URB buffer crossed that max packet size boundary, the
firmware puts a zero-length placeholder command in its place
then moves the real command to the next boundary mark.

The driver did not recognize such behavior, leading to missing
a good number of rx events during a heavy rx load session.

Moreover, a tx URB context only gets freed upon receiving its
respective tx ACK event. Over time, the free tx URB contexts
pool gets depleted due to the missing ACK events. Consequently,
the netif transmission queue gets __permanently__ stopped; no
frames could be sent again except after restarting the CAN
newtwork interface.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

can: kvaser_usb: Avoid double free on URB submission failures

Upon a URB submission failure, the driver calls usb_free_urb()
but then manually frees the URB buffer by itself.  Meanwhile
usb_free_urb() has alredy freed out that transfer buffer since
we're the only code path holding a reference to this URB.

Remove two of such invalid manual free().

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

can: peak_usb: fix missing ctrlmode_ init for every dev

Fixes a missing initialization of ctrlmode and ctrlmode_supported fields,
for all other CAN devices than the first one. This fix only concerns
the PCAN-USB Pro FD dual-channels CAN-FD device made by PEAK-System.

Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

can: add missing initialisations in CAN related skbuffs

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh <austin@peloton-tech.com>
Reported-by: Daniel Steer <daniel.steer@mclaren.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

ALSA: hda - Fix regression of HD-audio controller fallback modes

The commit [63e51fd708f5: ALSA: hda - Don't take unresponsive D3
transition too serious] introduced a conditional fallback behavior to
the HD-audio controller depending on the flag set.  However, it
introduced a silly bug, too, that the flag was evaluated in a reverse
way.  This resulted in a regression of HD-audio controller driver
where it can't go to the fallback mode at communication errors.

Unfortunately (or fortunately?) this didn't come up until recently
because the affected code path is an error handling that happens only
on an unstable hardware chip.  Most of recent chips work stably, thus
they didn't hit this problem.  Now, we've got a regression report with
a VIA chip, and this seems indeed requiring the fallback to the
polling mode, and finally the bug was revealed.

The fix is a oneliner to remove the wrong logical NOT in the check.
(Lesson learned - be careful about double negation.)

The bug should be backported to stable, but the patch won't be
applicable to 3.13 or earlier because of the code splits.  The stable
fix patches for earlier kernels will be posted later manually.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94021
Fixes: 63e51fd708f5 ('ALSA: hda - Don't take unresponsive D3 transition too serious')
Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ip: fix error queue empty skb handling

When reading from the error queue, msg_name and msg_control are only
populated for some errors. A new exception for empty timestamp skbs
added a false positive on icmp errors without payload.

`traceroute -M udpconn` only displayed gateways that return payload
with the icmp error: the embedded network headers are pulled before
sock_queue_err_skb, leaving an skb with skb->len == 0 otherwise.

Fix this regression by refining when msg_name and msg_control
branches are taken. The solutions for the two fields are independent.

msg_name only makes sense for errors that configure serr->port and
serr->addr_offset. Test the first instead of skb->len. This also fixes
another issue. saddr could hold the wrong data, as serr->addr_offset
is not initialized  in some code paths, pointing to the start of the
network header. It is only valid when serr->port is set (non-zero).

msg_control support differs between IPv4 and IPv6. IPv4 only honors
requests for ICMP and timestamps with SOF_TIMESTAMPING_OPT_CMSG. The
skb->len test can simply be removed, because skb->dev is also tested
and never true for empty skbs. IPv6 honors requests for all errors
aside from local errors and timestamps on empty skbs.

In both cases, make the policy more explicit by moving this logic to
a new function that decides whether to process msg_control and that
optionally prepares the necessary fields in skb->cb[]. After this
change, the IPv4 and IPv6 paths are more similar.

The last case is rxrpc. Here, simply refine to only match timestamps.

Fixes: 49ca0d8bfaf3 ("net-timestamp: no-payload option")
Reported-by: Jan Niehusmann <jan@gondor.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
----

Changes
  v1->v2
  - fix local origin test inversion in ip6_datagram_support_cmsg
  - make v4 and v6 code paths more similar by introducing analogous
    ipv4_datagram_support_cmsg
  - fix compile bug in rxrpc
Signed-off-by: David S. Miller <davem@davemloft.net>

bgmac: Clean warning messages

On my test environment the throughput of a file transfer drops
from 4.4MBps to 116KBps due the number of repeated warning
messages. This patch removes the warning messages as DMA works
correctly with addresses using 0xC0000000 bits.

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux 4.0-rc3

sunrpc: fix braino in ->poll()

POLL_OUT isn't what callers of ->poll() are expecting to see; it's
actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
bit...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
Cc: Bruce Fields <bfields@fieldses.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'usb-4.0-rc3' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here's a round of USB fixes for 4.0-rc3.

  Nothing major, the usual gadget, xhci and usb-serial fixes and a few
  new device ids as well.

  All have been in linux-next successfully"

* tag 'usb-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (36 commits)
  xhci: Workaround for PME stuck issues in Intel xhci
  xhci: fix reporting of 0-sized URBs in control endpoint
  usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards
  USB: ch341: set tty baud speed according to tty struct
  USB: serial: cp210x: Adding Seletek device id's
  USB: pl2303: disable break on shutdown
  USB: mxuport: fix null deref when used as a console
  USB: serial: clean up bus probe error handling
  USB: serial: fix port attribute-creation race
  USB: serial: fix tty-device error handling at probe
  USB: serial: fix potential use-after-free after failed probe
  USB: console: add dummy __module_get
  USB: ftdi_sio: add PIDs for Actisense USB devices
  Revert "USB: serial: make bulk_out_size a lower limit"
  cdc-acm: Add support for Denso cradle CU-321
  usb-storage: support for more than 8 LUNs
  uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539
  USB: usbfs: don't leak kernel data in siginfo
  xhci: Clear the host side toggle manually when endpoint is 'soft reset'
  xhci: Allocate correct amount of scratchpad buffers
  ...

regulator: core: Fix enable GPIO reference counting

Normally _regulator_do_enable() isn't called on an already-enabled
rdev.  That's because the main caller, _regulator_enable() always
calls _regulator_is_enabled() and only calls _regulator_do_enable() if
the rdev was not already enabled.

However, there is one caller of _regulator_do_enable() that doesn't
check: regulator_suspend_finish().  While we might want to make
regulator_suspend_finish() behave more like _regulator_enable(), it's
probably also a good idea to make _regulator_do_enable() robust if it
is called on an already enabled rdev.

At the moment, _regulator_do_enable() is _not_ robust for already
enabled rdevs if we're using an ena_pin.  Each time
_regulator_do_enable() is called for an rdev using an ena_pin the
reference count of the ena_pin is incremented even if the rdev was
already enabled.  This is not as intended because the ena_pin is for
something else: for keeping track of how many active rdevs there are
sharing the same ena_pin.

Here's how the reference counting works here:

* Each time _regulator_enable() is called we increment
  rdev->use_count, so _regulator_enable() calls need to be balanced
  with _regulator_disable() calls.

* There is no explicit reference counting in _regulator_do_enable()
  which is normally just a warapper around rdev->desc->ops->enable()
  with code for supporting delays.  It's not expected that the
  "ops->enable()" call do reference counting.

* Since regulator_ena_gpio_ctrl() does have reference counting
  (handling the sharing of the pin amongst multiple rdevs), we
  shouldn't call it if the current rdev is already enabled.

Note that as part of this we cleanup (remove) the initting of
ena_gpio_state in regulator_register().  In _regulator_do_enable(),
_regulator_do_disable() and _regulator_is_enabled() is is clear that
ena_gpio_state should be the state of whether this particular rdev has
requested the GPIO be enabled.  regulator_register() was initting it
as the actual state of the pin.

Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

regulator: Only enable disabled regulators on resume

The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator.  However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator.  That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings.  We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.

Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish().  That may speed up suspend/resume and also
avoids exposing hidden bugs.

[Use much clearer commit message from Doug Anderson]

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Merge tag 'tty-4.0-rc3' of git://git./linux/kernel/git/gregkh/tty

Pull tty/serial fixes from Greg KH:
 "Here are some tty and serial driver fixes for 4.0-rc3.

  Along with the atime fix that you know about, here are some other
  serial driver bugfixes as well.  Most notable is a wait_until_sent
  bugfix that was traced back to being around since before 2.6.12 that
  Johan has fixed up.

  All have been in linux-next successfully"

* tag 'tty-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  TTY: fix tty_wait_until_sent maximum timeout
  TTY: fix tty_wait_until_sent on 64-bit machines
  USB: serial: fix infinite wait_until_sent timeout
  TTY: bfin_jtag_comm: remove incorrect wait_until_sent operation
  net: irda: fix wait_until_sent poll timeout
  serial: uapi: Declare all userspace-visible io types
  serial: core: Fix iotype userspace breakage
  serial: sprd: Fix missing spin_unlock in sprd_handle_irq()
  console: Fix console name size mismatch
  tty: fix up atime/mtime mess, take four
  serial: 8250_dw: Fix get_mctrl behaviour
  serial:8250:8250_pci: delete unneeded quirk entries
  serial:8250:8250_pci: fix redundant entry report for WCH_CH352_2S
  Change email address for 8250_pci
  serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO"
  Revert "tty/serial: of_serial: add DT alias ID handling"

Merge tag 'staging-4.0-rc3' of git://git./linux/kernel/git/gregkh/staging

Pull staging driver fixes from Greg KH:
 "Here are some IIO and staging driver fixes for 4.0-rc3.

  Details are in the shortlog, nothing major, mostly IIO fixes for
  reported issues.

  All have been in linux-next successfully"

* tag 'staging-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (23 commits)
  staging: comedi: adv_pci1710: fix AI INSN_READ for non-zero channel
  staging: comedi: vmk80xx: remove "firmware version" kernel messages
  staging: comedi: comedi_isadma: fix "stalled" detect in comedi_isadma_disable_on_sample()
  iio: ak8975: fix AK09911 dependencies
  iio: common: ssp_sensors: Protect PM-only functions to kill warning
  IIO: si7020: Allocate correct amount of memory in devm_iio_device_alloc
  Revert "iio:humidity:si7020: fix pointer to i2c client"
  iio: light: gp2ap020a00f: Select REGMAP_I2C
  iio: light: jsa1212: Select REGMAP_I2C
  iio: ad5686: fix optional reference voltage declaration
  iio:adc:mcp3422 Fix incorrect scales table
  iio: mxs-lradc: fix iio channel map regression
  iio: imu: adis16400: Fix sign extension
  staging: iio: ad2s1200: Fix sign extension
  iio: mxs-lradc: only update the buffer when its conversions have finished
  iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
  iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
  iio: mxs-lradc: separate touchscreen and buffer virtual channels
  iio: imu: inv_mpu6050: Prevent dereferencing NULL
  iio: iadc: wait_for_completion_timeout time in jiffies
  ...

gadgetfs: really get rid of switching ->f_op

... for ep0 as well

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge tag 'char-misc-4.0-rc3' of git://git./linux/kernel/git/gregkh/char-misc

Pull char/misc driver fixes from Greg KH:
 "Here are two char/misc fixes for 4.0-rc3.

  One is a reported binder driver fix needed due to a change in the mm
  core that happened in 4.0-rc1.  Another is a mei driver fix that
  resolves a reported issue in that driver.

  Both have been in linux-next for a while"

* tag 'char-misc-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  mei: make device disabled on stop unconditionally
  android: binder: fix binder mmap failures

Merge tag 'cc-4.0-rc2' of git://git./linux/kernel/git/gregkh/char-misc

Pull "code of conflict" from Greg KH:
 "This file tries to set the rational basis for our code reviews, gives
  some advice on how to conduct them, and provides an excalation channel
  for any kernel developers if they so desire it"

[ Let's see how this works ]

* tag 'cc-4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  Code of Conflict

gadgetfs: get rid of flipping ->f_op in ep_config()

Final methods start with get_ready_ep(), which will fail unless we have
->state == STATE_EP_ENABLED.  So they'd be failing just fine until that
first write() anyway.  Let's do the following:
* get_ready_ep() gets a new argument - true when called from
ep_write_iter(), false otherwise.
* make it quiet when it finds STATE_EP_READY (no printk, that is;
the case won't be impossible after that change).
* when that new argument is true, treat STATE_EP_READY the same
way as STATE_EP_ENABLED (i.e. return zero and do not unlock).
* in ep_write_iter(), after success of get_ready_ep() turn
if (!usb_endpoint_dir_in(&epdata->desc)) {
into
if (epdata->state == STATE_EP_ENABLED &&
    !usb_endpoint_dir_in(&epdata->desc)) {
- that logics only applies after config.
* have ep_config() take kernel-side buffer (i.e. use memcpy()
instead of copy_from_user() in there) and in the "let's call ep_io or
ep_aio" (again, in ep_write_iter()) add "... or ep_config() in case it's
not configured yet"

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

irqchip: gicv3-its: Support safe initialization

It's unsafe to change the configurations of an activated ITS directly
since this will lead to unpredictable results. This patch guarantees
the ITSes being initialized are quiescent.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-12-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Define macros for GITS_CTLR fields

Define macros for GITS_CTLR fields to avoid using magic numbers.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-11-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Add limitation to page order

When required size of Device Table is out of the page allocator's
capability, the whole ITS will fail in probing. This actually is
not the hardware's problem and is mainly a limitation of the kernel
page allocator. This patch will keep ITS going on to the next
initializaion stage with an explicit warning.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-10-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Use 64KB page as default granule

The field of page size in register GITS_BASERn might be read-only
if an implementation only supports a single, fixed page size. But
currently the ITS driver will throw out an error when PAGE_SIZE
is less than the minimum size supported by an ITS. So addressing
this problem by using 64KB pages as default granule for all the
ITS base tables.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
[maz: fixed bug breaking non Device Table allocations]
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-9-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Zero itt before handling to hardware

Some kind of brain-dead implementations chooses to insert ITEes in
rapid sequence of disabled ITEes, and an un-zeroed ITT will confuse
ITS on judging whether an ITE is really enabled or not. Considering
the implementations are still supported by the GICv3 architecture,
in which ITT is not required to be zeroed before being handled to
hardware, we do the favor in ITS driver.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Yun Wu <wuyun.wu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-8-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gic-v3: Fix out of bounds access to cpu_logical_map

While playing with KASan support for arm64/arm the following appeared on boot:

==================================================================
BUG: AddressSanitizer: out of bounds access in __asan_load8+0x14/0x1c at addr ffffffc000ad0dc0
Read of size 8 by task swapper/0/1
page:ffffffbdc202b400 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x400(reserved)
page dumped because: kasan: bad access detected
Address belongs to variable __cpu_logical_map+0x200/0x220
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6-next-20150129+ #481
Hardware name: FVP Base (DT)
Call trace:
[<ffffffc00008a794>] dump_backtrace+0x0/0x184
[<ffffffc00008a928>] show_stack+0x10/0x1c
[<ffffffc00075e46c>] dump_stack+0xa0/0xf8
[<ffffffc0001df490>] kasan_report_error+0x23c/0x264
[<ffffffc0001e0188>] check_memory_region+0xc0/0xe4
[<ffffffc0001dedf0>] __asan_load8+0x10/0x1c
[<ffffffc000431294>] gic_raise_softirq+0xc4/0x1b4
[<ffffffc000091fc0>] smp_send_reschedule+0x30/0x3c
[<ffffffc0000f0d1c>] try_to_wake_up+0x394/0x434
[<ffffffc0000f0de8>] wake_up_process+0x2c/0x6c
[<ffffffc0000d9570>] wake_up_worker+0x38/0x48
[<ffffffc0000dbb50>] insert_work+0xac/0xec
[<ffffffc0000dbd38>] __queue_work+0x1a8/0x374
[<ffffffc0000dbf60>] queue_work_on+0x5c/0x7c
[<ffffffc0000d8a78>] call_usermodehelper_exec+0x170/0x188
[<ffffffc0004037b8>] kobject_uevent_env+0x650/0x6bc
[<ffffffc000403830>] kobject_uevent+0xc/0x18
[<ffffffc00040292c>] kset_register+0xa8/0xc8
[<ffffffc0004d6c88>] bus_register+0x134/0x2e8
[<ffffffc0004d73b4>] subsys_virtual_register+0x2c/0x5c
[<ffffffc000a76a4c>] wq_sysfs_init+0x14/0x20
[<ffffffc000082a28>] do_one_initcall+0xa8/0x1fc
[<ffffffc000a70db4>] kernel_init_freeable+0x1ec/0x294
[<ffffffc00075aa5c>] kernel_init+0xc/0xec
Memory state around the buggy address:
 ffffff80003e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffff80003e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffff80003e0840: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
                   ^
 ffffff80003e0850: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00
==================================================================

The reason for that cpumask_next() returns >= nr_cpu_ids if no further cpus
set, but "==" condition is checked only, so we end up with out-of-bounds
access to cpu_logical_map.

Fix is by using the condition check for cpumask_next.

Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-7-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gic: Fix unsafe locking reported by lockdep

When compiled with CONFIG_LOCKDEP, the kernel shouts badly, saying
that the locking in the GIC code is unsafe. I'm afraid the kernel
is right:

       CPU0
       ----
  lock(irq_controller_lock);
  <Interrupt>
    lock(irq_controller_lock);

 *** DEADLOCK ***

This can happen while enabling, disabling, setting the type
or the affinity of an interrupt.

The fix is to take the interrupt_controller_lock with interrupts
disabled in these cases.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-6-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Fix unsafe locking reported by lockdep

When compiled with CONFIG_LOCKDEP, the kernel shouts badly, saying
that my locking is unsafe. I'm afraid the kernel is right:

       CPU0                    CPU1
       ----                    ----
  lock(&its->lock);
                               local_irq_disable();
                               lock(&irq_desc_lock_class);
                               lock(&its->lock);
  <Interrupt>
    lock(&irq_desc_lock_class);

 *** DEADLOCK ***

The fix is to always take its->lock with interrupts disabled.

Reported-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Iterate over PCI aliases to generate ITS configuration

The current PCI/MSI support in the GICv3 ITS doesn't really deal
with systems where different PCI devices end-up using the same
RequesterID (as it would be the case with non-transparent bridges,
for example). It is likely that none of these devices would
actually generate any interrupt, as the ITS is programmed with
the device's own ID, and not that of the bridge.

A solution to this is to iterate over the PCI hierarchy to
discover what the device aliases too. We also use this
to discover the upper bound of the number of MSIs that this
sub-hierarchy can generate.

With this in place, PCI aliases can be supported.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Allocate enough memory for the full range of DeviceID

The ITS table allocator is only allocating a single page per table.
This works fine for most things, but leads to silent lack of
interrupt delivery if we end-up with a device that has an ID that is
out of the range defined by a single page of memory. Even worse, depending
on the page size, behaviour changes, which is not a very good experience.

A solution is actually to allocate memory for the full range of ID that
the ITS supports. A massive waste memory wise, but at least a safe bet.

Tested on a Phytium SoC.

Tested-by: Chen Baozi <chenbaozi@kylinos.com.cn>
Acked-by: Chen Baozi <chenbaozi@kylinos.com.cn>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: gicv3-its: Fix ITS CPU init

We skip initialisation of ITS in case the device-tree has no
corresponding description, but we are still accessing to ITS bits while
setting CPU interface what leads to the kernel panic:

ITS: No ITS available, not enabling LPIs
CPU0: found redistributor 0 region 0:0x000000002f100000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc0007fb000
[00000000] *pgd=00000000fc407003, *pud=00000000fc407003, *pmd=00000000fc408003, *pte=006000002f000707
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc2+ #318
Hardware name: FVP Base (DT)
task: ffffffc00077edb0 ti: ffffffc00076c000 task.ti: ffffffc00076c000
PC is at its_cpu_init+0x2c/0x320
LR is at gic_cpu_init+0x168/0x1bc

It happens in gic_rdists_supports_plpis() because gic_rdists is NULL.
The gic_rdists is set to non-NULL only when ITS node is presented in
the device-tree.

Fix this by moving the call to gic_rdists_supports_plpis() inside the
!list_empty(&its_nodes) block, because it is that list that guards the
validity of the rest of the information in this driver.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1425659870-11832-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

irqchip: armada-370-xp: Fix chained per-cpu interrupts

On the Cortex-A9-based Armada SoCs, the MPIC is not the primary interrupt
controller. Yet, it still has to handle some per-cpu interrupt.

To do so, it is chained with the GIC using a per-cpu interrupt. However, the
current code only call irq_set_chained_handler, which is called and enable that
interrupt only on the boot CPU, which means that the parent per-CPU interrupt
is never unmasked on the secondary CPUs, preventing the per-CPU interrupt to
actually work as expected.

This was not seen until now since the only MPIC PPI users were the Marvell
timers that were not working, but not used either since the system use the ARM
TWD by default, and the ethernet controllers, that are faking there interrupts
as SPI, and don't really expect to have interrupts on the secondary cores
anyway.

Add a CPU notifier that will enable the PPI on the secondary cores when they
are brought up.

Cc: <stable@vger.kernel.org> # 3.15+
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1425378443-28822-1-git-send-email-maxime.ripard@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

Input: psmouse - disable "palm detection" in the focaltech driver

Apparently, the threshold for large contact area seems to be rather low on
some devices, causing the touchpad to frequently freeze during normal
usage. Because we do now know how we are supposed to use the value in
question, this commit just drops the related code completely.

Signed-off-by: Mathias Gottschlag <mgottschlag@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: psmouse - disable changing resolution/rate/scale for FocalTech

These PS/2 commands make some touchpads stop responding, so this commit
adds some dummy functions to replace the generic implementation. Because
scale changes were not encapsulated in a method of struct psmouse yet, this
commit adds a method set_scale to psmouse.

Signed-off-by: Mathias Gottschlag <mgottschlag@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>