IB/iser: Fix wrong calculation of protection buffer length

commit a065fe6aa25ba6ba93c02dc13486131bb3c64d5f upstream.

This length miss-calculation may cause a silent data corruption
in the DIX case and cause the device to reference unmapped area.

Fixes: d77e65350f2d ('libiscsi, iser: Adjust data_length to include protection information')
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IB/mlx4: Fix WQE LSO segment calculation

commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream.

The current code decreases from the mss size (which is the gso_size
from the kernel skb) the size of the packet headers.

It shouldn't do that because the mss that comes from the stack
(e.g IPoIB) includes only the tcp payload without the headers.

The result is indication to the HW that each packet that the HW sends
is smaller than what it could be, and too many packets will be sent
for big messages.

An easy way to demonstrate one more aspect of the problem is by
configuring the ipoib mtu to be less than 2*hlen (2*56) and then
run app sending big TCP messages. This will tell the HW to send packets
with giant (negative value which under unsigned arithmetics becomes
a huge positive one) length and the QP moves to SQE state.

Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support')
Reported-by: Matthew Finlay <matt@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IB/core: don't disallow registering region starting at 0x0

commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream.

In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057ab5e4
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mmap_low_allowed SELinux knobs allow userspace to map
something at address 0x0).

This patch allows back such registration: ib_umem_get()
should probably don't care of the base address provided it
can be pinned with get_user_pages().

There's two possible overflows, in (addr + size) and in
PAGE_ALIGN(addr + size), this patch keep ensuring none
of them happen while allowing to pin memory at address
0x0. Anyway, the case of size equal 0 is no more (partially)
handled as 0-length memory region are disallowed by an
earlier check.

Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com
Cc: Shachar Raindel <raindel@mellanox.com>
Cc: Jack Morgenstein <jackm@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Reviewed-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IB/core: disallow registering 0-sized memory region

commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream.

If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.

This should not be allowed: it's not expected for a memory
region to have a size equal to 0.

This patch adds a check to explicitly refuse to register
a 0-sized region.

Link: http://mid.gmane.org/cover.1428929103.git.ydroneaud@opteya.com
Cc: Shachar Raindel <raindel@mellanox.com>
Cc: Jack Morgenstein <jackm@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

stk1160: Make sure current buffer is released

commit aeff09276748b66072f2db2e668cec955cf41959 upstream.

The available (i.e. not used) buffers are returned by stk1160_clear_queue(),
on the stop_streaming() path. However, this is insufficient and the current
buffer must be released as well. Fix it.

Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rc: img-ir: fix error in parameters passed to irq_free()

commit 80ccf4ad06dc9d2f06a8347b2d309cdc959f72b3 upstream.

img_ir_remove() passes a pointer to the ISR function as the 2nd
parameter to irq_free() instead of a pointer to the device data
structure.
This issue causes unloading img-ir module to fail with the below
warning after building and loading img-ir as a module.

WARNING: CPU: 2 PID: 155 at ../kernel/irq/manage.c:1278
__free_irq+0xb4/0x214() Trying to free already-free IRQ 58
Modules linked in: img_ir(-)
CPU: 2 PID: 155 Comm: rmmod Not tainted 3.14.0 #55 ...
Call Trace:
...
[<8048d420>] __free_irq+0xb4/0x214
[<8048d6b4>] free_irq+0xac/0xf4
[<c009b130>] img_ir_remove+0x54/0xd4 [img_ir] [<8073ded0>]
platform_drv_remove+0x30/0x54 ...

Fixes: 160a8f8aec4d ("[media] rc: img-ir: add base driver")

Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mvsas: fix panic on expander attached SATA devices

commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream.

mvsas is giving a General protection fault when it encounters an expander
attached ATA device.  Analysis of mvs_task_prep_ata() shows that the driver is
assuming all ATA devices are locally attached and obtaining the phy mask by
indexing the local phy table (in the HBA structure) with the phy id.  Since
expanders have many more phys than the HBA, this is causing the index into the
HBA phy table to overflow and returning rubbish as the pointer.

mvs_task_prep_ssp() instead does the phy mask using the port properties.
Mirror this in mvs_task_prep_ata() to fix the panic.

Reported-by: Adam Talbot <ajtalbot1@gmail.com>
Tested-by: Adam Talbot <ajtalbot1@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()

commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream.

Correctly rollback state if the failure occurs after we have handed over
the ownership of the buffer to the host.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sd: Fix missing ATO tag check

commit e557990e358934fb168d30371c9c0f63e314c6b8 upstream.

3aec2f41a8bae introduced a merge error where we would end up check for
sdkp instead of sdkp->ATO. Fix this so we register app tag capability
correctly.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sd: Unregister integrity profile

commit e727c42bd55794765c460b7ac2b6cc969f2a9698 upstream.

The new integrity code did not correctly unregister the profile for SD
disks. Call blk_integrity_unregister() when we release a disk.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Sagi Grimberg <sagig@dev.mellanox.co.il>
Tested-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250: Check UART_SCR is writable

commit f01a0bd8921b9d6668d41fae3198970e6318f532 upstream.

Au1x00/RT2800+ doesn't implement the 8250 scratch register (and
this may be true of other h/w currently supported by the 8250 driver);
read back the canary value written to the scratch register to enable
the console h/w restart after resume from system suspend.

Fixes: 4516d50aabedb ("serial: 8250: Use canary to restart console ...")
Reported-by: Mason <slash.tmp@free.fr>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: imx: Fix clearing of receiver overrun flag

commit 91555ce9012557b2d621d7b0b6ec694218a2a9bc upstream.

The writeable bits in the USR2 register are all "write 1 to
clear" so only write the bits that actually should be cleared.

Fixes: f1f836e4209e ("serial: imx: Add Rx Fifo overrun error message")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250_dw: add support for AMD SOC Carrizo

commit 5ef86b74209db33c133b5f18738dd8f3189b63a1 upstream.

Add ACPI identifier for UART on AMD SOC Carrizo.

Signed-off-by: Ken Xue <Ken.Xue@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm crypt: fix deadlock when async crypto algorithm returns -EBUSY

commit 0618764cb25f6fa9fb31152995de42a8a0496475 upstream.

I suspect this doesn't show up for most anyone because software
algorithms typically don't have a sense of being too busy.  However,
when working with the Freescale CAAM driver it will return -EBUSY on
occasion under heavy -- which resulted in dm-crypt deadlock.

After checking the logic in some other drivers, the scheme for
crypt_convert() and it's callback, kcryptd_async_done(), were not
correctly laid out to properly handle -EBUSY or -EINPROGRESS.

Fix this by using the completion for both -EBUSY and -EINPROGRESS.  Now
crypt_convert()'s use of completion is comparable to
af_alg_wait_for_completion().  Similarly, kcryptd_async_done() follows
the pattern used in af_alg_complete().

Before this fix dm-crypt would lockup within 1-2 minutes running with
the CAAM driver.  Fix was regression tested against software algorithms
on PPC32 and x86_64, and things seem perfectly happy there as well.

Signed-off-by: Ben Collins <ben.c@servergy.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qcom: Fix ipq806x LCC frequency tables

commit b3261d768bcdd4b368179ed85becf38c95461848 upstream.

These frequency tables list the wrong rates. Either they don't
have the correct frequency at all, or they're specified in kHz
instead of Hz. Fix it.

Fixes: c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) driver"
Tested-by: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qcom: fix RCG M/N counter configuration

commit 0b21503dbbfa669dbd847b33578d4041513cddb2 upstream.

Currently, a RCG's M/N counter (used for fraction division) is
set to either 'bypass' (counter disabled) or 'dual edge' (counter
enabled) based on whether the corresponding rcg struct has a mnd
field specified and a non-zero N.

In the case where M and N are the same value, the M/N counter is
still enabled by code even though no division takes place.
Leaving the RCG in such a state can result in improper behavior.
This was observed with the DSI pixel clock RCG when M and N were
both set to 1.

Add an additional check (M != N) to enable the M/N counter only
when it's needed for fraction division.

Signed-off-by: Archit Taneja <architt@codeaurora.org>
Fixes: bcd61c0f535a (clk: qcom: Add support for root clock
generators (RCGs))
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qcom: Properly change rates for ahbix clock

commit 9d3745d44a7faa7d24db7facb1949a1378162f3e upstream.

The ahbix clock can never be turned off in practice. To change the
rates we need to switch the mux off the M/N counter to an always on
source (XO), reprogram the M/N counter to get the rate we want and
finally switch back to the M/N counter. Add a new ops structure
for this type of clock so that we can set the rate properly.

Fixes: c99e515a92e9 "clk: qcom: Add IPQ806X LPASS clock controller (LCC) driver"
Tested-by: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qcom: Fix i2c frequency table

commit 0bf0ff82c34da02ee5795101b328225a2d519594 upstream.

PXO is 25MHz, not 27MHz. Fix the table.

Fixes: 24d8fba44af3 "clk: qcom: Add support for IPQ8064's global
clock controller (GCC)"

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <agross@codeaurora.org>
Tested-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: tegra: Use the proper parent for plld_dsi

commit c1d676cec572544616273d5853cb7cc38fbaa62b upstream.

The current parent, plld_out0, does not exist. The proper name is
pll_d_out0. While at it, rename the plld_dsi clock to pll_d_dsi_out to
be more consistent with other clock names.

Fixes: b270491eb9a0 ("clk: tegra: Define PLLD_DSI and remove dsia(b)_mux")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: tegra: Register the proper number of resets

commit 5e43e259171e1eee8bc074d9c44be434e685087b upstream.

The number of resets controls is 32 times the number of peripheral
register banks rather than 32 times the number of clocks. This reduces
(drastically) the number of reset controls registered from 10080 (315
clocks * 32) to 224 (6 peripheral register banks * 32).

This also fixes a potential crash because trying to use any of the
excess reset controls (224-10079) would have caused accesses beyond
the array bounds of the peripheral register banks definition array.

Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Fixes: 6d5b988e7dc5 ("clk: tegra: implement a reset driver")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: samsung: exynos4: Disable ARMCLK down feature on Exynos4210 SoC

commit 3a9e9cb65be84d6c64fbe9c69a73c15d59f29454 upstream.

Commit 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK
down feature") enabled ARMCLK down feature on all Exynos4
SoCs.  Unfortunately on Exynos4210 SoC ARMCLK down feature
causes a lockup when ondemand cpufreq governor is used.
Fix it by limiting ARMCLK down feature to Exynos4x12 SoCs.

This patch was tested on:
- Exynos4210 SoC based Trats board
- Exynos4210 SoC based Origen board
- Exynos4412 SoC based Trats2 board
- Exynos4412 SoC based Odroid-U3 board

Cc: Daniel Drake <drake@endlessm.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Kukjin Kim <kgene@kernel.org>
Fixes: 42773b28e71d ("clk: samsung: exynos4: Enable ARMCLK down feature")
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

gpio: mvebu: Fix mask/unmask managment per irq chip type

commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream.

Level IRQ handlers and edge IRQ handler are managed by tow different
sets of registers. But currently the driver uses the same mask for the
both registers. It lead to issues with the following scenario:

First, an IRQ is requested on a GPIO to be triggered on front. After,
this an other IRQ is requested for a GPIO of the same bank but
triggered on level. Then the first one will be also setup to be
triggered on level. It leads to an interrupt storm.

The different kind of handler are already associated with two
different irq chip type. With this patch the driver uses a private
mask for each one which solves this issue.

It has been tested on an Armada XP based board and on an Armada 375
board. For the both boards, with this patch is applied, there is no
such interrupt storm when running the previous scenario.

This bug was already fixed but in a different way in the legacy
version of this driver by Evgeniy Dushistov:
9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain
sequence of request_irq can cause irq storm". The fact the new version
of the gpio drive could be affected had been discussed there:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012

Reported-by: Evgeniy A. Dushistov <dushistov@mail.ru>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xtensa: ISS: fix locking in TAP network adapter

commit 24e94454c8cb6a13634f5a2f5a01da53a546a58d upstream.

- don't lock lp->lock in the iss_net_timer for the call of iss_net_poll,
  it will lock it itself;
- invert order of lp->lock and opened_lock acquisition in the
  iss_net_open to make it consistent with iss_net_poll;
- replace spin_lock with spin_lock_bh when acquiring locks used in
  iss_net_timer from non-atomic context;
- replace spin_lock_irqsave with spin_lock_bh in the iss_net_start_xmit
  as the driver doesn't use lp->lock in the hard IRQ context;
- replace __SPIN_LOCK_UNLOCKED(lp.lock) with spin_lock_init, otherwise
  lockdep is unhappy about using non-static key.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range

commit 01e84c70fe40c8111f960987bcf7f931842e6d07 upstream.

xtensa actually uses sync_file_range2 implementation, so it should
define __NR_sync_file_range2 as other architectures that use that
function. That fixes userspace interface (that apparently never worked)
and avoids special-casing xtensa in libc implementations.
See the thread ending at
http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html
for more details.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xtensa: xtfpga: fix hardware lockup caused by LCD driver

commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 upstream.

LCD driver is always built for the XTFPGA platform, but its base address
is not configurable, and is wrong for ML605/KC705. Its initialization
locks up KC705 board hardware.

Make the whole driver optional, and its base address and bus width
configurable. Implement 4-bit bus access method.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline()

commit 4c533c801d1c9b5c38458a0e7516e0cf50643782 upstream.

acpi_scan_is_offline() may be called under the physical_node_lock
lock of the given device object's parent, so prevent lockdep from
complaining about that by annotating that instance with
SINGLE_DEPTH_NESTING.

Fixes: caa73ea158de (ACPI / hotplug / driver core: Handle containers in a special way)
Reported-and-tested-by: Xie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPICA: Store GPE register enable masks upfront

commit 0ee0d34985ceffe4036319e1e46df8bff591b9e3 upstream.

It is reported that ACPI interrupts do not work any more on
Dell Latitude D600 after commit c50f13c672df (ACPICA: Save
current masks of enabled GPEs after enable register writes).
The problem turns out to be related to the fact that the
enable_mask and enable_for_run GPE bit masks are not in
sync (in the absence of any system suspend/resume events)
for at least one GPE register on that machine.

Address this problem by writing the enable_for_run mask into
enable_mask as soon as enable_for_run is updated instead of
doing that only after the subsequent register write has
succeeded.  For consistency, update acpi_hw_gpe_enable_write()
to store the bit mask to be written into the GPE register
in enable_mask unconditionally before the write.

Since the ACPI_GPE_SAVE_MASK flag is not necessary any more after
that, drop it along with the symbols depending on it.

Reported-and-tested-by: Jim Bos <jim876@xs4all.nl>
Fixes: c50f13c672df (ACPICA: Save current masks of enabled GPEs after enable register writes)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPICA: Tables: Don't release ACPI_MTX_TABLES in acpi_tb_install_standard_table().

commit 77ddc2fe08329e375505bc36a3df3233fe57317b upstream.

ACPICA commit c70434d4da13e65b6163c79a5aa16b40193631c7

ACPI_MTX_TABLES is acquired and released by the callers of
acpi_tb_install_standard_table() so releasing it in the function itself is
causing the following error in Linux kernel if the table is reloaded:

ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321)
Call Trace:
  [<ffffffff81b0bd48>] dump_stack+0x4f/0x7b
  [<ffffffff81546bf5>] acpi_ut_release_mutex+0x47/0x67
  [<ffffffff81544357>] acpi_load_table+0x73/0xcb

Link: https://github.com/acpica/acpica/commit/c70434d4
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPICA: Utilities: split IO address types from data type models.

commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream.

ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451

It is reported that on a physically 64-bit addressed machine, 32-bit kernel
can trigger crashes in accessing the memory regions that are beyond the
32-bit boundary. The region field's start address should still be 32-bit
compliant, but after a calculation (adding some offsets), it may exceed the
32-bit boundary. This case is rare and buggy, but there are real BIOSes
leaked with such issues (see References below).

This patch fixes this gap by always defining IO addresses as 64-bit, and
allows OSPMs to optimize it for a real 32-bit machine to reduce the size of
the internal objects.

Internal acpi_physical_address usages in the structures that can be fixed
by this change include:
 1. struct acpi_object_region:
    acpi_physical_address address;
 2. struct acpi_address_range:
    acpi_physical_address start_address;
    acpi_physical_address end_address;
 3. struct acpi_mem_space_context;
    acpi_physical_address address;
 4. struct acpi_table_desc
    acpi_physical_address address;
See known issues 1 for other usages.

Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer
from same problem, so this patch changes it accordingly.

For iasl, it will enforce acpi_physical_address as 32-bit to generate
32-bit OSPM compatible tables on 32-bit platforms, we need to define
ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h.

Known issues:
 1. Cleanup of mapped virtual address
   In struct acpi_mem_space_context, acpi_physical_address is used as a virtual
   address:
    acpi_physical_address                   mapped_physical_address;
   It is better to introduce acpi_virtual_address or use acpi_size instead.
   This patch doesn't make such a change. Because this should be done along
   with a change to acpi_os_map_memory()/acpi_os_unmap_memory().
   There should be no functional problem to leave this unchanged except
   that only this structure is enlarged unexpectedly.

Link: https://github.com/acpica/acpica/commit/aacf863c
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501
Reported-and-tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reported-and-tested-by: Sial Nije <sialnije@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: pcm512x: Fix divide by zero issue

commit f073faa73626f41db7050a69edd5074c53ce6d6c upstream.

If den=1 and pllin_rate>20MHz then den and num are adjusted to 0
causing a divide by zero error a few lines further on. Therefore
this patch correctly scales num and den such that
pllin_rate/den < 20MHz as required in the device data sheet.

Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: pcm512x: Add 'Analogue' prefix to analogue volume controls

commit 4d9b13c7cc803fbde59d7e998f7de2b9a2101c7e upstream.

This is to ensure that 'alsactl restore' does not apply default
initialisation as the chip reset defaults are preferred.

Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: davinci-evm: drop un-necessary remove function

commit a57069e33fbc6625f39e1b09c88ea44629a35206 upstream.

As davinci card gets registered using 'devm_' api
there is no need to unregister the card in 'remove'
function.
Hence drop the 'remove' function.

Fixes: ee2f615d6e59c (ASoC: davinci-evm: Add device tree binding)
Signed-off-by: Manish Badarkhe <manishvb@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: wm8741: Fix rates constraints values

commit 8787041d9bb832b9449b1eb878cedcebce42c61a upstream.

The WM8741 DAC supports the following typical audio sampling rates:
  44.1kHz, 88.2kHz, 176.4kHz (eg: with a master clock of 22.5792MHz)
  32kHz, 48kHz, 96kHz, 192kHz (eg: with a master clock of 24.576MHz)

For the rates lists, we should use 82000 instead of 88235, 176400
instead of 1764000 and 192000 instead of 19200 (seems to be a typo).

Signed-off-by: Sergej Sawazki <ce3a@gmx.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: cs4271: Increase delay time after reset

commit 74ff960222d90999508b4ba0d3449f796695b6d5 upstream.

The delay time after a reset in the codec probe callback was too short,
and did not work on certain hw because the codec needs more time to
power on. This increases the delay time from 1us to 1ms.

Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Acked-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/cell: Fix cell iommu after it_page_shift changes

commit 7261b956b276aa97fbf60d00f1d7717d2ea6ee78 upstream.

The patch to add it_page_shift incorrectly changed the increment of
uaddr to use it_page_shift, rather then (1 << it_page_shift).

This broke booting on at least some Cell blades, as the iommu was
basically non-functional.

Fixes: 3a553170d35d ("powerpc/iommu: Add it_page_shift field to determine iommu page size")
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/cell: Fix crash in iic_setup_cpu() after per_cpu changes

commit b0dd00addc5035f87ec9c5820dacc1ebc7fcb3e6 upstream.

The conversion from __get_cpu_var() to this_cpu_ptr() in iic_setup_cpu()
is wrong. It causes an oops at boot.

We need the per-cpu address of struct cpu_iic, not cpu_iic.regs->prio.

Sparse noticed this, because we pass a non-iomem pointer to out_be64(),
but we obviously don't check the sparse results often enough.

Fixes: 69111bac42f5 ("powerpc: Replace __get_cpu_var uses")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc: Fix missing L2 cache size in /sys/devices/system/cpu

commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream.

This problem appears to have been introduced in 2.6.29 by commit
93197a36a9c1 "Rewrite sysfs processor cache info code".

This caused lscpu to error out on at least e500v2 devices, eg:

  error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory

Some embedded powerpc systems use cache-size in DTS for the unified L2
cache size, not d-cache-size, so we need to allow for both DTS names.
Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle
this.

Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code")
Signed-off-by: Dave Olson <olson@cumulusnetworks.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/powernv: Don't map M64 segments using M32DT

commit 027fa02f84e851e21daffdf8900d6117071890f8 upstream.

If M64 has been supported, the prefetchable 64-bits memory resources
shouldn't be mapped to the corresponding PE# via M32DT. Unfortunately,
we're doing that in pnv_ioda_setup_pe_seg() wrongly. The issue was
introduced by commit 262af55 ("powerpc/powernv: Enable M64 aperatus
for PHB3"). The patch fixes the issue by simply skipping M64 resources
when updating to M32DT.

Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: errata: add workaround for cortex-a53 erratum #845719

commit 905e8c5dcaa147163672b06fe9dcb5abaacbc711 upstream.

When running a compat (AArch32) userspace on Cortex-A53, a load at EL0
from a virtual address that matches the bottom 32 bits of the virtual
address used by a recent load at (AArch64) EL1 might return incorrect
data.

This patch works around the issue by writing to the contextidr_el1
register on the exception return path when returning to a 32-bit task.
This workaround is patched in at runtime based on the MIDR value of the
processor.

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: apply alternatives for !SMP kernels

commit 137650aad96c9594683445e41afa8ac5a2097520 upstream.

Currently we only perform alternative patching for kernels built with
CONFIG_SMP, as we call apply_alternatives_all() in smp.c, which is only
built for CONFIG_SMP. Thus !SMP kernels may not have necessary
alternatives patched in.

This patch ensures that we call apply_alternatives_all() once all CPUs
are booted, even for !SMP kernels, by having the smp_init_cpus() stub
call this for !SMP kernels via up_late_init. A new wrapper,
do_post_cpus_up_work, is added so we can hook other calls here later
(e.g. boot mode logging).

Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Fixes: e039ee4ee3fcf174 ("arm64: add alternative runtime patching")
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Adjust EFI libstub object include logic

commit ad08fd494bf00c03ae372e0bbd9cefa37bf608d6 upstream.

Commit f4f75ad5 ("efi: efistub: Convert into static library")
introduced a static library for EFI stub, libstub.

The EFI libstub directory is referenced by the kernel build system via
a obj subdirectory rule in:
drivers/firmware/efi/Makefile

Unfortunately, arm64 also references the EFI libstub via:
libs-$(CONFIG_EFI_STUB) += drivers/firmware/efi/libstub/

If we're unlucky, the kernel build system can enter libstub via two
simultaneous threads resulting in build failures such as:

fixdep: error opening depfile: drivers/firmware/efi/libstub/.efi-stub-helper.o.d: No such file or directory
scripts/Makefile.build:257: recipe for target 'drivers/firmware/efi/libstub/efi-stub-helper.o' failed
make[1]: *** [drivers/firmware/efi/libstub/efi-stub-helper.o] Error 2
Makefile:939: recipe for target 'drivers/firmware/efi/libstub' failed
make: *** [drivers/firmware/efi/libstub] Error 2
make: *** Waiting for unfinished jobs....

This patch adjusts the arm64 Makefile to reference the compiled library
explicitly (as is currently done in x86), rather than the directory.

Fixes: f4f75ad5 efi: efistub: Convert into static library
Signed-off-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: head.S: ensure visibility of page tables

commit 91d57155dc5ab4b311624b7ee570339b6af19ad5 upstream.

After writing the page tables, we use __inval_cache_range to invalidate
any stale cache entries. Strongly Ordered memory accesses are not
ordered w.r.t. cache maintenance instructions, and hence explicit memory
barriers are required to provide this ordering. However,
__inval_cache_range was written to be used on Normal Cacheable memory
once the MMU and caches are on, and does not have any barriers prior to
the DC instructions.

This patch adds a DMB between the page tables being written and the
corresponding cachelines being invalidated, ensuring that the
invalidation makes the new data visible to subsequent cacheable
accesses. A barrier is not required before the prior invalidate as we do
not access the page table memory area prior to this, and earlier
barriers in preserve_boot_args and set_cpu_boot_mode_flag ensures
ordering w.r.t. any stores performed prior to entering Linux.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: c218bca74eeafa2f ("arm64: Relax the kernel cache requirements for boot")
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: fix midr range for Cortex-A57 erratum 832075

commit 6d1966dfd6e0ad2f8aa4b664ae1a62e33abe1998 upstream.

Register MIDR_EL1 is masked to get variant and revision fields, then
compared against midr_range_min and midr_range_max when checking
whether CPU is affected by any particular erratum. However, variant
and revision fields in MIDR_EL1 are separated by 16 bits, so the min
and max of midr range should be constructed accordingly, otherwise
the patch will not be applied when variant field is non-0.

Acked-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Bo Yan <byan@nvidia.com>
[will: use MIDR_VARIANT_SHIFT to construct upper bound]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card

commit 2eeff0b4317a02f0e281df891d990194f0737aae upstream.

Add 04f2:aff1 to ath3k.c supported devices list and btusb.c blacklist, so
that the device can load the ath3k firmware and re-enumerate itself as an
AR3011 device.

T:  Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04f2 ProdID=aff1 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Signed-off-by: Alexander Ploumistos <alexpl@fedoraproject.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iser-target: Fix possible deadlock in RDMA_CM connection error

commit 4a579da2586bd3b79b025947ea24ede2bbfede62 upstream.

Before we reach to connection established we may get an
error event. In this case the core won't teardown this
connection (never established it), so we take care of freeing
it ourselves.

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iser-target: Fix session hang in case of an rdma read DIF error

commit 364189f0ada5478e4faf8a552d6071a650d757cd upstream.

This hang was a result of a missing command put when
a DIF error occurred during a rdma read (and we sent
an CHECK_CONDITION error without passing it to the
backend).

Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target/file: Fix SG table for prot_buf initialization

commit c836777830428372074d5129ac513e1472c99791 upstream.

In fd_do_prot_rw(), it allocates prot_buf which is used to copy from
se_cmd->t_prot_sg by sbc_dif_copy_prot().  The SG table for prot_buf
is also initialized by allocating 'se_cmd->t_prot_nents' entries of
scatterlist and setting the data length of each entry to PAGE_SIZE
at most.

However if se_cmd->t_prot_sg contains a clustered entry (i.e.
sg->length > PAGE_SIZE), the SG table for prot_buf can't be
initialized correctly and sbc_dif_copy_prot() can't copy to prot_buf.
(This actually happened with TCM loopback fabric module)

As prot_buf is allocated by kzalloc() and it's physically contiguous,
we only need a single scatterlist entry.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target/file: Fix UNMAP with DIF protection support

commit 64d240b721b21e266ffde645ec965c3b6d1c551f upstream.

When UNMAP command is issued with DIF protection support enabled,
the protection info for the unmapped region is remain unchanged.
So READ command for the region causes data integrity failure.

This fixes it by invalidating protection info for the unmapped region
by filling with 0xff pattern.  This change also adds helper function
fd_do_prot_fill() in order to reduce code duplication with existing
fd_format_prot().

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target/file: Fix BUG() when CONFIG_DEBUG_SG=y and DIF protection enabled

commit 38da0f49e8aa1649af397d53f88e163d0e60c058 upstream.

When CONFIG_DEBUG_SG=y and DIF protection support enabled, kernel
BUG()s are triggered due to the following two issues:

1) prot_sg is not initialized by sg_init_table().

When CONFIG_DEBUG_SG=y, scatterlist helpers check sg entry has a
correct magic value.

2) vmalloc'ed buffer is passed to sg_set_buf().

sg_set_buf() uses virt_to_page() to convert virtual address to struct
page, but it doesn't work with vmalloc address.  vmalloc_to_page()
should be used instead.  As prot_buf isn't usually too large, so
fix it by allocating prot_buf by kmalloc instead of vmalloc.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target: Fix COMPARE_AND_WRITE with SG_TO_MEM_NOALLOC handling

commit c8e639852ad720499912acedfd6b072325fd2807 upstream.

This patch fixes a bug for COMPARE_AND_WRITE handling with
fabrics using SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC.

It adds the missing allocation for cmd->t_bidi_data_sg within
transport_generic_new_cmd() that is used by COMPARE_AND_WRITE
for the initial READ payload, even if the fabric is already
providing a pre-allocated buffer for cmd->t_data_sg.

Also, fix zero-length COMPARE_AND_WRITE handling within the
compare_and_write_callback() and target_complete_ok_work()
to queue the response, skipping the initial READ.

This fixes COMPARE_AND_WRITE emulation with loopback, vhost,
and xen-backend fabric drivers using SG_TO_MEM_NOALLOC.

Reported-by: Christoph Hellwig <hch@lst.de>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iscsi-target: Convert iscsi_thread_set usage to kthread.h

commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca upstream.

This patch converts iscsi-target code to use modern kthread.h API
callers for creating RX/TX threads for each new iscsi_conn descriptor,
and releasing associated RX/TX threads during connection shutdown.

This is done using iscsit_start_kthreads() -> kthread_run() to start
new kthreads from within iscsi_post_login_handler(), and invoking
kthread_stop() from existing iscsit_close_connection() code.

Also, convert iscsit_logout_post_handler_closesession() code to use
cmpxchg when determing when iscsit_cause_connection_reinstatement()
needs to sleep waiting for completion.

Reported-by: Sagi Grimberg <sagig@mellanox.com>
Tested-by: Sagi Grimberg <sagig@mellanox.com>
Cc: Slava Shwartsman <valyushash@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: storvsc: Fix a bug in copy_from_bounce_buffer()

commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream.

We may exit this function without properly freeing up the maapings
we may have acquired. Fix the bug.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

UBI: fix check for "too many bytes"

commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream.

The comparison from the previous line seems to have been erroneously
(partially) copied-and-pasted onto the next. The second line should be
checking req.bytes, not req.lnum.

Coverity CID #139400

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
[rw: Fixed comparison]
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

UBI: initialize LEB number variable

commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream.

In some of the 'out_not_moved' error paths, lnum may be used
uninitialized. Don't ignore the warning; let's fix it.

This uninitialized variable doesn't have much visible effect in the end,
since we just schedule the PEB for erasure, and its LEB number doesn't
really matter (it just gets printed in debug messages). But let's get it
straight anyway.

Coverity CID #113449

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

UBI: fix out of bounds write

commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream.

If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the
PEB->LEB mapping.

Caught by Coverity, CID #711212.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

UBI: account for bitflips in both the VID header and data

commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream.

We are completely discarding the earlier value of 'bitflips', which
could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the
bitwise OR of header and data 'bitflip' statuses instead.

Coverity CID #1226856

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile

commit f82263c6989c31ae9b94cecddffb29dcbec38710 upstream.

Since commit ee0778a30153
("tools/power: turbostat: make Makefile a bit more capable")
turbostat's Makefile is using

  [...]
  BUILD_OUTPUT    := $(PWD)
  [...]

which obviously causes trouble when building "turbostat" with

  make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat

because GNU make does not update nor guarantee that $PWD is set.

This patch changes the Makefile to use $CURDIR instead, which GNU make
guarantees to set and update (i.e. when using "make -C ...") and also
adds support for the O= option (see "make help" in your root of your
kernel source tree for more details).

Link: https://bugs.gentoo.org/show_bug.cgi?id=533918
Fixes: ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable")
Signed-off-by: Thomas D. <whissi@whissi.de>
Cc: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools lib traceevent kbuffer: Remove extra update to data pointer in PADDING

commit c5e691928bf166ac03430e957038b60adba3cf6c upstream.

When a event PADDING is hit (a deleted event that is still in the ring
buffer), translate_data() sets the length of the padding and also updates
the data pointer which is passed back to the caller.

This is unneeded because the caller also updates the data pointer with
the passed back length. translate_data() should not update the pointer,
only set the length.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150324135923.461431960@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH

commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream.

We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), but we forgot to do the same for 64bit backtraces.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf tools: Work around lack of sched_getcpu in glibc < 2.6.

commit e1e455f4f4d35850c30235747620d0d078fe9f64 upstream.

This patch fixes this build error with glibc < 2.6.

  CC       util/cloexec.o
cc1: warnings being treated as errors
util/cloexec.c: In function ‘perf_flag_probe’:
util/cloexec.c:24: error: implicit declaration of function
‘sched_getcpu’
util/cloexec.c:24: error: nested extern declaration of ‘sched_getcpu’
make: *** [util/cloexec.o] Error 1

Signed-off-by: Vinson Lee <vlee@twitter.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Link: http://lkml.kernel.org/r/1427137761-16119-1-git-send-email-vlee@twopensource.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf tools: Fix perf-read-vdsox32 not building and lib64 install dir

commit 76aea7731e7050c066943a1d7456ec6510702601 upstream.

Commit:

  c6e5e9fbc3ea ("perf tools: Fix building error in x86_64 when dwarf unwind is on")

removed the definition of IS_X86_64 but not all places using it, with
the consequence that perf-read-vdsox32 would not be built anymore, and
the default lib install directory was 'lib' instead of 'lib64'.

Also needs to go to v3.19.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: http://lkml.kernel.org/r/CAMe9rOqpGVq3D88w+D15ef7sv6G6k57ZeTvxBm46=WFgzo9p1w@mail.gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf symbols: Define STT_GNU_IFUNC for glibc 2.9 and older.

commit 4e31050f482c02c822b150d71cf1ea5be7c9d6e4 upstream.

The token STT_GNU_IFUNC is not available with glibc 2.9 and older.
Define this token if it is not already defined.

This patch fixes this build errors with older versions of glibc.

  CC       util/symbol-elf.o
util/symbol-elf.c: In function ‘elf_sym__is_function’:
util/symbol-elf.c:75: error: ‘STT_GNU_IFUNC’ undeclared (first use in this function)
util/symbol-elf.c:75: error: (Each undeclared identifier is reported only once
util/symbol-elf.c:75: error: for each function it appears in.)
make: *** [util/symbol-elf.o] Error 1

Signed-off-by: Vinson Lee <vlee@twitter.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Avi Kivity <avi@cloudius-systems.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Waiman Long <Waiman.Long@hp.com>
Link: http://lkml.kernel.org/r/1423528286-13630-1-git-send-email-vlee@twopensource.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tpm: fix: sanitized code paths in tpm_chip_register()

commit 34d47b6322087665be33ca3aa81775b143a4d7ac upstream.

I started to work with PPI interface so that it would be available
under character device sysfs directory and realized that chip
registeration was still too messy.

In TPM 1.x in some rare scenarios (errors that almost never occur)
wrong order in deinitialization steps was taken in teardown. I
reproduced these scenarios by manually inserting error codes in the
place of the corresponding function calls.

The key problem is that the teardown is messy with two separate code
paths (this was inherited when moving code from tpm-interface.c).

Moved TPM 1.x specific register/unregister functionality to own helper
functions and added single code path for teardown in tpm_chip_register().
Now the code paths have been fixed and it should be easier to review
later on this part of the code.

Fixes: 7a1d7e6dd76a ("tpm: TPM 2.0 baseline support")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Scot Doyle <lkml14@scotdoyle.com>
Reviewed-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Update detach_mounts to leave mounts connected

commit e0c9c0afd2fc958ffa34b697972721d81df8a56f upstream.

Now that it is possible to lazily unmount an entire mount tree and
leave the individual mounts connected to each other add a new flag
UMOUNT_CONNECTED to umount_tree to force this behavior and use
this flag in detach_mounts.

This closes a bug where the deletion of a file or directory could
trigger an unmount and reveal data under a mount point.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Fix the error check in __detach_mounts

commit f53e57975151f54ad8caa1b0ac8a78091cd5700a upstream.

lookup_mountpoint can return either NULL or an error value.
Update the test in __detach_mounts to test for an error value
to avoid pathological cases causing a NULL pointer dereferences.

The callers of __detach_mounts should prevent it from ever being
called on an unlinked dentry but don't take any chances.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Honor MNT_LOCKED when detaching mounts

commit ce07d891a0891d3c0d0c2d73d577490486b809e1 upstream.

Modify umount(MNT_DETACH) to keep mounts in the hash table that are
locked to their parent mounts, when the parent is lazily unmounted.

In mntput_no_expire detach the children from the hash table, depending
on mnt_pin_kill in cleanup_mnt to decrement the mnt_count of the children.

In __detach_mounts if there are any mounts that have been unmounted
but still are on the list of mounts of a mountpoint, remove their
children from the mount hash table and those children to the unmounted
list so they won't linger potentially indefinitely waiting for their
final mntput, now that the mounts serve no purpose.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Factor umount_mnt from umount_tree

commit 6a46c5735c29175da55b2fa9d53775182422cdd7 upstream.

For future use factor out a function umount_mnt from umount_tree.
This function unhashes a mount and remembers where the mount
was mounted so that eventually when the code makes it to a
sleeping context the mountpoint can be dput.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Factor out unhash_mnt from detach_mnt and umount_tree

commit 7bdb11de8ee4f4ae195e2fa19efd304e0b36c63b upstream.

Create a function unhash_mnt that contains the common code between
detach_mnt and umount_tree, and use unhash_mnt in place of the common
code.  This add a unncessary list_del_init(mnt->mnt_child) into
umount_tree but given that mnt_child is already empty this extra
line is a noop.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Don't propagate unmounts to locked mounts

commit 0c56fe31420ca599c90240315f7959bf1b4eb6ce upstream.

If the first mount in shared subtree is locked don't unmount the
shared subtree.

This is ensured by walking through the mounts parents before children
and marking a mount as unmountable if it is not locked or it is locked
but it's parent is marked.

This allows recursive mount detach to propagate through a set of
mounts when unmounting them would not reveal what is under any locked
mount.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: On an unmount propagate clearing of MNT_LOCKED

commit 5d88457eb5b86b475422dc882f089203faaeedb5 upstream.

A prerequisite of calling umount_tree is that the point where the tree
is mounted at is valid to unmount.

If we are propagating the effect of the unmount clear MNT_LOCKED in
every instance where the same filesystem is mounted on the same
mountpoint in the mount tree, as we know (by virtue of the fact
that umount_tree was called) that it is safe to reveal what
is at that mountpoint.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Delay removal from the mount hash.

commit 411a938b5abc9cb126c41cccf5975ae464fe0f3e upstream.

- Modify __lookup_mnt_hash_last to ignore mounts that have MNT_UMOUNTED set.
- Don't remove mounts from the mount hash table in propogate_umount
- Don't remove mounts from the mount hash table in umount_tree before
  the entire list of mounts to be umounted is selected.
- Remove mounts from the mount hash table as the last thing that
  happens in the case where a mount has a parent in umount_tree.
  Mounts without parents are not hashed (by definition).

This paves the way for delaying removal from the mount hash table even
farther and fixing the MNT_LOCKED vs MNT_DETACH issue.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Add MNT_UMOUNT flag

commit 590ce4bcbfb4e0462a720a4ad901e84416080bba upstream.

In some instances it is necessary to know if the the unmounting
process has begun on a mount.  Add MNT_UMOUNT to make that reliably
testable.

This fix gets used in fixing locked mounts in MNT_DETACH

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: In umount_tree reuse mnt_list instead of mnt_hash

commit c003b26ff98ca04a180ff34c38c007a3998d62f9 upstream.

umount_tree builds a list of mounts that need to be unmounted.
Utilize mnt_list for this purpose instead of mnt_hash.  This begins to
allow keeping a mount on the mnt_hash after it is unmounted, which is
necessary for a properly functioning MNT_LOCKED implementation.

The fact that mnt_list is an ordinary list makding available list_move
is nice bonus.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Don't propagate umounts in __detach_mounts

commit 8318e667f176f7ea34451a1a530634e293f216ac upstream.

Invoking mount propagation from __detach_mounts is inefficient and
wrong.

It is inefficient because __detach_mounts already walks the list of
mounts that where something needs to be done, and mount propagation
walks some subset of those mounts again.

It is actively wrong because if the dentry that is passed to
__detach_mounts is not part of the path to a mount that mount should
not be affected.

change_mnt_propagation(p,MS_PRIVATE) modifies the mount propagation
tree of a master mount so it's slaves are connected to another master
if possible.  Which means even removing a mount from the middle of a
mount tree with __detach_mounts will not deprive any mount propagated
mount events.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Improve the umount_tree flags

commit e819f152104c9f7c9fe50e1aecce6f5d4bf06d65 upstream.

- Remove the unneeded declaration from pnode.h
- Mark umount_tree static as it has no callers outside of namespace.c
- Define an enumeration of umount_tree's flags.
- Pass umount_tree's flags in by name

This removes the magic numbers 0, 1 and 2 making the code a little
clearer and makes it possible for there to be lazy unmounts that don't
propagate.  Which is what __detach_mounts actually wants for example.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: make fsync to sync parent dir in no-journal for real this time

commit e12fb97222fc41e8442896934f76d39ef99b590a upstream.

Previously commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c added a
support for for syncing parent directory of newly created inodes to
make sure that the inode is not lost after a power failure in
no-journal mode.

However this does not work in majority of cases, namely:
 - if the directory has inline data
 - if the directory is already indexed
 - if the directory already has at least one block and:
- the new entry fits into it
- or we've successfully converted it to indexed

So in those cases we might lose the inode entirely even after fsync in
the no-journal mode. This also includes ext2 default mode obviously.

I've noticed this while running xfstest generic/321 and even though the
test should fail (we need to run fsck after a crash in no-journal mode)
I could not find a newly created entries even when if it was fsynced
before.

Fix this by adjusting the ext4_add_entry() successful exit paths to set
the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the
parent directory as well.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Frank Mayhar <fmayhar@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rtlwifi: rtl8192cu: Add new device ID

commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 upstream.

Add new ID for ASUS N10 WiFi dongle.

Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rtlwifi: rtl8192cu: Add new USB ID

commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream.

USB ID 2001:330d is used for a D-Link DWA-131.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFC: st21nfcb: Retry i2c_master_send if it returns a negative value

commit d4a41d10b2cb5890aeda6b2912973b2a754b05b1 upstream.

i2c_master_send may return many negative values different than
-EREMOTEIO.
In case an i2c transaction is NACK'ed, on raspberry pi B+
kernel 3.18, -EIO is generated instead.

Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/macb: fix the peripheral version test

commit 361918970b7426bba97a64678ef2b2679c37199b upstream.

We currently need two checks of the peripheral version in MACB_MID register.
One of them got out of sync after modification by 8a013a9c71b2 (net: macb:
Include multi queue support for xilinx ZynqMP ethernet version).
Fix this in macb_configure_caps() so that xilinx ZynqMP will be considered
as a GEM flavor.

Fixes: 8a013a9c71b2 ("net: macb: Include multi queue support for xilinx ZynqMP
ethernet version")

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Punnaiah Choudary Kalluri <punnaia@xilinx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

intel_idle: Update support for Silvermont Core in Baytrail SOC

commit d7ef76717322c8e2df7d4360b33faa9466cb1a0d upstream.

On some Silvermont-Core/Baytrail-SOC systems,
C1E latency is higher than original specifications.
Although C1E is still enumerated in CPUID.MWAIT.EDX,
we delete the state from intel_idle to avoid latency impact.

Under some conditions, the latency of the C6N-BYT and C6S-BYT states
may exceed the specified values of 40 and 140 usec, respectively.
Increase those values to 300 and 500 usec; to assure
that the hardware does not violate constraints that may be set
by the Linux PM_QOS sub-system.

Also increase the C7-BYT target residency to 4.0 ms from 1.5 ms.

Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Kumar P Mahesh <mahesh.kumar.p@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ptrace: fix race between ptrace_resume() and wait_task_stopped()

commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.

ptrace_resume() is called when the tracee is still __TASK_TRACED.  We set
tracee->exit_code and then wake_up_state() changes tracee->state.  If the
tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T)
wrongly looks like another report from tracee.

This confuses debugger, and since wait_task_stopped() clears ->exit_code
the tracee can miss a signal.

Test-case:

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <pthread.h>
#include <assert.h>

int pid;

void *waiter(void *arg)
{
int stat;

for (;;) {
assert(pid == wait(&stat));
assert(WIFSTOPPED(stat));
if (WSTOPSIG(stat) == SIGHUP)
continue;

assert(WSTOPSIG(stat) == SIGCONT);
printf("ERR! extra/wrong report:%x\n", stat);
}
}

int main(void)
{
pthread_t thread;

pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
for (;;)
kill(getpid(), SIGHUP);
}

assert(pthread_create(&thread, NULL, waiter, NULL) == 0);

for (;;)
ptrace(PTRACE_CONT, pid, 0, SIGCONT);

return 0;
}

Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix
should use lock_task_sighand(child).

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Pavel Labath <labath@google.com>
Tested-by: Pavel Labath <labath@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fs/binfmt_elf.c: fix bug in loading of PIE binaries

commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream.

With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down
address allocation strategy, load_elf_binary() will attempt to map a PIE
binary into an address range immediately below mm->mmap_base.

Unfortunately, load_elf_ binary() does not take account of the need to
allocate sufficient space for the entire binary which means that, while
the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent
PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are
that is supposed to be the "gap" between the stack and the binary.

Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this
means that binaries with large data segments > 128MB can end up mapping
part of their data segment over their stack resulting in corruption of the
stack (and the data segment once the binary starts to run).

Any PIE binary with a data segment > 128MB is vulnerable to this although
address randomization means that the actual gap between the stack and the
end of the binary is normally greater than 128MB.  The larger the data
segment of the binary the higher the probability of failure.

Fix this by calculating the total size of the binary in the same way as
load_elf_interp().

Signed-off-by: Michael Davidson <md@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mfd: core: Fix platform-device name collisions

commit a77c50b44cfb663ad03faba9800fec19bdf83577 upstream.

Since commit 6e3f62f0793e ("mfd: core: Fix platform-device id
generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when
registering mfd-devices.

Unfortunately, some mfd-drivers rely on the old behaviour of generating
platform-device ids by adding the cell id also to the special value of
PLATFORM_DEVID_NONE. The resulting platform ids are not only used to
generate device-unique names, but are also used instead of the cell id
to identify cells when probing subdevices.

These drivers should be updated to use PLATFORM_DEVID_AUTO, which would
also allow more than one device to be registered without resorting to
hacks (see for example wm831x), but lets fix the regression first by
partially reverting the above mentioned commit with respect to
PLATFORM_DEVID_NONE.

Fixes: 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: alps - fix touchpad buttons getting stuck when used with trackpoint

commit 6bcca19f5dcedc3a006ca0bcc3699a437cadee74 upstream.

When the left touchpad button gets pressed, and then the trackpoint is
moved, and then the button is released, the following happens:

1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1

2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in
   this packet because when the trackstick is active it communicates the
   combined touchpad + pointing stick buttons in the trackstick packet,
   since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter
   to alps_report_buttons the combining is not detected and the
   pointing stick evdev node will also report BTN_LEFT 1

3) on release of the button a pointing stick packet with BTN_LEFT 0 is
   received and the pointing stick evdev node will report BTN_LEFT 0

Note how because of the passing as NULL for dev2 the touchpad evdev node
will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button.

This is a regression in 4.0 introduced by commit 04aae283ba6a8
("Input: ALPS - do not mix trackstick and external PS/2 mouse data")

This commit fixes this by passing in the touchpad evdev as dev2 parameter
when calling alps_report_buttons for the pointingstick on alps v2 devices,
so that alps_report_buttons correctly detect that we're already reporting
the button as pressed via the touchpad evdev node, and will also send the
release event there.

Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: elantech - fix absolute mode setting on some ASUS laptops

commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream.

On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each
time set_rate is done.

In order to fix this, we will verify the firmware version, and if it
matches the one in those laptops, the set_rate function is overloaded
with a function elantech_set_rate_restore_reg_07 that performs the
set_rate with the original function, followed by a restore of reg_07
(the register that sets the absolute mode on elantech v4 hardware).

Also the ASUS TP500LN and X750JN firmware version, capabilities, and
button constellation is added to elantech.c

Reported-and-tested-by: George Moutsopoulos <gmoutso@yahoo.co.uk>
Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - fix headset mic detection problem for one more machine

commit e8191a8e475551b277d85cd76c3f0f52fdf42e86 upstream.

We have two machines with alc256 codec in the pin quirk table, so
moving the common pins to ALC256_STANDARD_PINS.

BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447909
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek - Fix Headphone Mic doesn't recording for ALC256

commit d32b66668c702aed0e330dc5ca186afbadcdacf8 upstream.

Switch default pcbeep path to Line in path.

Signed-off-by: Kailang Yang <kailang@realtek.com>
Tested-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - fix "num_steps = 0" error on ALC256

commit 7d1b6e29327428993ba568bdd8c66734070f45e0 upstream.

The ALC256 does not have a mixer nid at 0x0b, and there's no
loopback path (the output pins are directly connected to the DACs).

This commit fixes an "num_steps = 0 for NID=0xb (ctl = Beep Playback Volume)"
error (and as a result, problems with amixer/alsamixer).

If there's pcbeep functionality, it certainly isn't controlled by setting an
amp on 0x0b, so disable beep functionality (at least for now).

BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1446517
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T450

commit f2aa111041ce36b94e651d882458dea502e76721 upstream.

The Lenovo Thinkpad T450 requires the ALC292_FIXUP_TPT440_DOCK as well in
order to get working sound output on the docking stations headphone jack.

Patch tested on a Thinkpad T450 (20BVCTO1WW) using kernel 4.0-rc7 in
conjunction with a ThinkPad Ultradock.

Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: emu10k1: don't deadlock in proc-functions

commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream.

The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read
acquire the emu_lock before accessing the FPGA. The function used
to access the FPGA (snd_emu1010_fpga_read) also tries to take
the emu_lock which causes a deadlock.
Remove the outer locking in the proc-functions (guarding only the
already safe fpga read) to prevent this deadlock.

[removed superfluous flags variables too -- tiwai]

Signed-off-by: Michael Gernoth <michael@gernoth.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Don't attempt to get Microsoft Lifecam Cinema sample rate

commit eef0342cf32689f77d78ee3302999e5caaa6a8f3 upstream.

Adds Microsoft LifeCam Cinema USB ID to the snd_usb_get_sample_rate_quirk list as the Lifecam Cinema does not appear to support getting the sample rate.

Fixes the issue where the LifeCam Cinema would wait for USB timeout and log the message "cannot get freq at ep 0x82" when accessed.

Addresses bug report https://bugzilla.kernel.org/show_bug.cgi?id=95961.

Signed-off-by: Adam Honse <calcprogrammer1@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226)

commit c0278669fb61596cc1a10ab8686d27c37269c37b upstream.

This model uses the same dock port as the previous generation.

Signed-off-by: Yves-Alexis Perez <corsac@debian.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: at91: usb: propagate rate modification to the parent clk

commit 4591243102faa8de92da320edea47219901461e9 upstream.

The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate
modification requests to their parents.
This causes a bug when the PLLB is left uninitialized by the bootloader
(PLL multiplier set to 0, or in other words, PLL rate = 0 Hz).

Implement the determinate_rate method and propagate the change rate
request to the parent clk.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Bo Shen <voice.shen@atmel.com>
Tested-by: Bo Shen <voice.shen@atmel.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: hub: use new USB_RESUME_TIMEOUT

commit bbc78c07a51f6fd29c227b1220a9016e585358ba upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: isp1760: hcd: use new USB_RESUME_TIMEOUT

commit 59c9904cce77b55892e15f40791f1e66e4d3a1e6 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: hcd: use new USB_RESUME_TIMEOUT

commit 74bd7b69801819707713b88e9d0bc074efa2f5e7 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: sl811: use new USB_RESUME_TIMEOUT

commit 08debfb13b199716da6153940c31968c556b195d upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: ehci: use new USB_RESUME_TIMEOUT

commit ea16328f80ca8d74434352157f37ef60e2f55ce2 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: xhci: use new USB_RESUME_TIMEOUT

commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 upstream.

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>