user/sven/linux.git/include, branch v4.0.4

ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.

2015-05-17T16:55:10Z

commit f254e3c57b9d952e987502aefa0804c177dd2503 upstream. ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643 Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Dirk Behme Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman

nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()

2015-05-17T16:55:06Z

commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream. The range check for b-tree level parameter in nilfs_btree_root_broken() is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even though the level is limited to values in the range of 0 to (NILFS_BTREE_LEVEL_MAX - 1). Since the level parameter is read from storage device and used to index nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it can cause memory overrun during btree operations if the boundary value is set to the level parameter on device. This fixes the broken sanity check and adds a comment to clarify that the upper bound NILFS_BTREE_LEVEL_MAX is exclusive. Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

SCSI: add 1024 max sectors black list flag

2015-05-13T12:14:29Z

commit 35e9a9f93994d7f7d12afa41169c7ba05513721b upstream. This works around a issue with qnap iscsi targets not handling large IOs very well. The target returns: VPD INQUIRY: Block limits page (SBC) Maximum compare and write length: 1 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 4294967295 blocks Optimal transfer length: 4294967295 blocks Maximum prefetch, xdread, xdwrite transfer length: 0 blocks Maximum unmap LBA count: 8388607 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 16383 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0xffffffff blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 and it is *sometimes* able to handle at least one IO of size up to 8 MB. We have seen in traces where it will sometimes work, but other times it looks like it fails and it looks like it returns failures if we send multiple large IOs sometimes. Also it looks like it can return 2 different errors. It will sometimes send iscsi reject errors indicating out of resources or it will send invalid cdb illegal requests check conditions. And then when it sends iscsi rejects it does not seem to handle retries when there are command sequence holes, so I could not just add code to try and gracefully handle that error code. The problem is that we do not have a good contact for the company, so we are not able to determine under what conditions it returns which error and why it sometimes works. So, this patch just adds a new black list flag to set targets like this to the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19 caused this regression, so I also ccing stable. Reported-by: Christian Hesse Signed-off-by: Mike Christie Reviewed-by: Christoph Hellwig Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

uas: Add US_FL_MAX_SECTORS_240 flag

2015-05-13T12:14:28Z

commit ee136af4a064c2f61e2025873584d2c7ec93f4ae upstream. The usb-storage driver sets max_sectors = 240 in its scsi-host template, for uas we do not want to do that for all devices, but testing has shown that some devices need it. This commit adds a US_FL_MAX_SECTORS_240 flag for such devices, and implements support for it in uas.c, while at it it also adds support for US_FL_MAX_SECTORS_64 to uas.c. Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE

2015-05-13T12:14:27Z

commit a2d97723cb3a7741af81868427b36bba274b681b upstream. Correct small copy and paste error where autodisable was not being enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ALSA: emu10k1: Emu10k2 32 bit DMA mode

2015-05-13T12:14:24Z

commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream. Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two modes for DMA. Second mode is useful for 64 bit os with more then 2 GB of ram (fixes problems with big soundfont loading) 1) 32MB from 2 GB address space using 8192 pages (used now as default) 2) 16MB from 4 GB address space using 4096 pages Mode is set using HCFG_EXPANDED_MEM flag in HCFG register. Also format of emu10k2 page table is then different. Signed-off-by: Peter Zubaj Tested-by: Takashi Iwai Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ebpf: verifier: check that call reg with ARG_ANYTHING is initialized

2015-05-06T20:04:07Z

commit 80f1d68ccba70b1060c9c7360ca83da430f66bed upstream. I noticed that a helper function with argument type ARG_ANYTHING does not need to have an initialized value (register). This can worst case lead to unintented stack memory leakage in future helper functions if they are not carefully designed, or unintended application behaviour in case the application developer was not careful enough to match a correct helper function signature in the API. The underlying issue is that ARG_ANYTHING should actually be split into two different semantics: 1) ARG_DONTCARE for function arguments that the helper function does not care about (in other words: the default for unused function arguments), and 2) ARG_ANYTHING that is an argument actually being used by a helper function and *guaranteed* to be an initialized register. The current risk is low: ARG_ANYTHING is only used for the 'flags' argument (r4) in bpf_map_update_elem() that internally does strict checking. Fixes: 17a5267067f3 ("bpf: verifier (add verifier core)") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

nfsd: eliminate NFSD_DEBUG

2015-05-06T20:04:05Z

commit 135dd002c23054aaa056ea3162c1e0356905c195 upstream. Commit f895b252d4edf ("sunrpc: eliminate RPC_DEBUG") introduced use of IS_ENABLED() in a uapi header which leads to a build failure for userspace apps trying to use : linux/nfsd/debug.h:18:15: error: missing binary operator before token "(" #if IS_ENABLED(CONFIG_SUNRPC_DEBUG) ^ Since this was only used to define NFSD_DEBUG if CONFIG_SUNRPC_DEBUG is enabled, replace instances of NFSD_DEBUG with CONFIG_SUNRPC_DEBUG. Fixes: f895b252d4edf "sunrpc: eliminate RPC_DEBUG" Signed-off-by: Mark Salter Reviewed-by: Jeff Layton Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

drm/exynos: Enable DP clock to fix display on Exynos5250 and other

2015-05-06T20:04:03Z

commit 1c363c7cccf64128087002b0779986ad16aff6dc upstream. After adding display power domain for Exynos5250 in commit 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the display on Chromebook Snow and others stopped working after boot. The reason for this suggested Andrzej Hajda: the DP clock was disabled. This clock is required by Display Port and is enabled by bootloader. However when FIMD driver probing was deferred, the display power domain was turned off. This effectively reset the value of DP clock enable register. When exynos-dp is later probed, the clock is not enabled and display is not properly configured: exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok exynos-dp 145b0000.dp-controller: unable to config video Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") Signed-off-by: Krzysztof Kozlowski Reported-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Tested-by: Andreas Färber Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman

clk: tegra: Use the proper parent for plld_dsi

2015-05-06T20:03:58Z

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 Signed-off-by: Greg Kroah-Hartman