aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-12-12cpufreq: intel_pstate: Minor cleanup for FRAC_BITSPrarit Bhargava1-1/+1
785ee27 ("cpufreq: intel_pstate: Fix limits->max_perf rounding error") hardcodes the value of FRAC_BITS. This patch fixes that minor issue. Fixes: 785ee2788141 (cpufreq: intel_pstate: Fix limits->max_perf rounding error) Signed-off-by: Prarit Bhargava <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-12-12cpufreq: tegra: add regulator dependency for T124Arnd Bergmann1-1/+1
This driver is the only one that calls regulator_sync_voltage(), but it can currently be built with CONFIG_REGULATOR disabled, producing this build error: drivers/cpufreq/tegra124-cpufreq.c: In function 'tegra124_cpu_switch_to_pllx': drivers/cpufreq/tegra124-cpufreq.c:68:2: error: implicit declaration of function 'regulator_sync_voltage' [-Werror=implicit-function-declaration] regulator_sync_voltage(priv->vdd_cpu_reg); My first attempt was to implement a helper for this function for regulator_sync_voltage, but Mark Brown explained: We don't do this for *all* regulator API functions - there's some where using them strongly suggests that there is actually a dependency on the regulator API. This does seem like it might be falling into the specialist category [...] Looking at the code I'm pretty unclear on what the authors think the use of _sync_voltage() is doing in the first place so it may be even better to just remove the call. It seems to have been included in the first commit so there's not changelog explaining things and there's no comment either. I'd *expect* it to be a noop as far as I can see. This adds the dependency to make the driver always build successfully or not be enabled at all. Alternatively, we could investigate if the driver should stop calling regulator_sync_voltage instead. Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Jon Hunter <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-12-11ipv6: sctp: clone options to avoid use after freeEric Dumazet1-0/+8
SCTP is lacking proper np->opt cloning at accept() time. TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP. We might later factorize this code in a common helper to avoid future mistakes. Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-12-11xfrm: add rcu protection to sk->sk_policy[]Eric Dumazet4-23/+42
XFRM can deal with SYNACK messages, sent while listener socket is not locked. We add proper rcu protection to __xfrm_sk_clone_policy() and xfrm_sk_policy_lookup() This might serve as the first step to remove xfrm.xfrm_policy_lock use in fast path. Fixes: fa76ce7328b2 ("inet: get rid of central tcp/dccp listener timer") Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Steffen Klassert <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-12-11xfrm: add rcu grace period in xfrm_policy_destroy()Eric Dumazet2-2/+10
We will soon switch sk->sk_policy[] to RCU protection, as SYNACK packets are sent while listener socket is not locked. This patch simply adds RCU grace period before struct xfrm_policy freeing, and the corresponding rcu_head in struct xfrm_policy. Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Steffen Klassert <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-12-11Merge tag 'imx-fixes-4.4-2' of ↵Kevin Hilman4-12/+9
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Merge "ARM: imx: fixes for 4.4, 2nd round" from Shawn Guo: The i.MX fixes for 4.4, 2nd round: - Fix vf610 SAI clock configuration bug which is discovered by the newly added master mode support in SAI audio driver. - Fix buggy L2 cache latency values in vf610 device trees, which may cause system hang when cpu runs at a higher frequency. * tag 'imx-fixes-4.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: vf610: use reset values for L2 cache latencies ARM: dts: vf610: fix clock definition for SAI2 ARM: imx: clk-vf610: fix SAI clock tree
2015-12-11ls2080a/dts: Add little endian property for GPIO IP blockLiu Gang1-0/+4
The GPIO block for ls2080a platform has little endian registers, the GPIO driver needs this property to read/write registers by right interface. Signed-off-by: Liu Gang <[email protected]> Signed-off-by: Li Yang <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2015-12-11dt-bindings: define little-endian property for QorIQ GPIOLi Yang1-0/+4
The GPIO block on different QorIQ chips could have registers in different endianess. Define the property to specify which endian is used by the hardware. Signed-off-by: Liu Gang <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Li Yang <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2015-12-11ARM64: dts: ls2080a: fix eSDHC endiannessyangbo lu1-0/+1
Add the "little-endian" property to fix the issue that eSDHC is not working and dumping out "mmc0: Controller never released inhibit bit(s)." error messages constantly. Fixes: 5461597f6ce0 ("dts/ls2080a: Update DTSI to add support of various peripherals") Signed-off-by: Yangbo Lu <[email protected]> Signed-off-by: Li Yang <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2015-12-11USB: add quirk for devices with broken LPMAlan Stern3-1/+15
Some USB device / host controller combinations seem to have problems with Link Power Management. For example, Steinar found that his xHCI controller wouldn't handle bandwidth calculations correctly for two video cards simultaneously when LPM was enabled, even though the bus had plenty of bandwidth available. This patch introduces a new quirk flag for devices that should remain disabled for LPM, and creates quirk entries for Steinar's devices. Signed-off-by: Alan Stern <[email protected]> Reported-by: Steinar H. Gunderson <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-12-11xhci: fix usb2 resume timing and races.Mathias Nyman2-6/+44
According to USB 2 specs ports need to signal resume for at least 20ms, in practice even longer, before moving to U0 state. Both host and devices can initiate resume. On device initiated resume, a port status interrupt with the port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. On host initiated resume, current code sets the port to resume state, sleep 20ms, and finally sets the port to U0 state. This should also be changed to work in a similar way as the device initiated resume, with timestamp tagging, but that is not yet tested and will be a separate fix later. There are a few issues with this approach 1. A host initiated resume will also generate a resume event. The event handler will find the port in resume state, believe it's a device initiated resume, and act accordingly. 2. A port status request might cut the resume signalling short if a get_port_status request is handled during the host resume signalling. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happens to the port during device initiated resume signalling it will leave all the device resume parameters hanging uncleared, preventing further suspend, returning -EBUSY, and cause the pm thread to busyloop trying to enter suspend. Fix this by using the existing resuming_ports bitfield to indicate that resume signalling timing is taken care of. Check if the resume_done[port] is set before using it for timestamp comparison, and also clear out any resume signalling related variables if port is not in U0 or Resume state This issue was discovered when a PM thread busylooped, trying to runtime suspend the xhci USB 2 roothub on a Dell XPS Cc: stable <[email protected]> Reported-by: Daniel J Blueman <[email protected]> Tested-by: Daniel J Blueman <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-12-11nfit: acpi_nfit_notify(): Do not leave device lockedAlexey Khoroshilov1-1/+1
Even if dev->driver is null because we are being removed, it is safer to not leave device locked. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <[email protected]> Reviewed-by: Ross Zwisler <[email protected]> Reviewed-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]>
2015-12-11Input: atmel_mxt_ts - add maxtouch to I2C table for module autoloadJavier Martinez Canillas1-0/+1
The Atmel maxtouch DT binding documents that the compatible string for the device is "atmel,maxtouch" and the I2C core always reports a module alias of the form i2c:alias where alias is the compatible string model: $ grep MODALIAS /sys/devices/platform/12e00000.i2c/i2c-8/8-004b/uevent MODALIAS=i2c:maxtouch But there isn't maxtouch entry in the I2C device ID table so when the i2c:maxtouch MODALIAS uevent is reported, kmod is not able to match the alias with a module to load: $ modinfo atmel_mxt_ts | grep alias alias: of:N*T*Catmel,maxtouch alias: i2c:mXT224 alias: i2c:atmel_mxt_tp alias: i2c:atmel_mxt_ts alias: i2c:qt602240_ts So add the maxtouch entry to the I2C device ID table to allow the module to be autoloaded when the device is registered via OF. Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2015-12-11ses: fix additional element traversal bugJames Bottomley2-1/+13
KASAN found that our additional element processing scripts drop off the end of the VPD page into unallocated space. The reason is that not every element has additional information but our traversal routines think they do, leading to them expecting far more additional information than is present. Fix this by adding a gate to the traversal routine so that it only processes elements that are expected to have additional information (list is in SES-2 section 6.1.13.1: Additional Element Status diagnostic page overview) Reported-by: Pavel Tikhomirov <[email protected]> Tested-by: Pavel Tikhomirov <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]>
2015-12-11Merge tag 'dm-4.4-fixes-2' of ↵Linus Torvalds4-20/+161
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: "Five stable fixes: - Two DM btree bufio buffer leak fixes that resolve reported BUG_ONs during DM thinp metadata close's dm_bufio_client_destroy(). - A DM thinp range discard fix to handle discarding a partially mapped range. - A DM thinp metadata snapshot fix to make sure the btree roots saved in the metadata snapshot are the most current. - A DM space map metadata refcounting fix that improves both DM thinp and DM cache metadata" * tag 'dm-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm btree: fix bufio buffer leaks in dm_btree_del() error path dm space map metadata: fix ref counting bug when bootstrapping a new space map dm thin metadata: fix bug when taking a metadata snapshot dm thin metadata: fix bug in dm_thin_remove_range() dm btree: fix leak of bufio-backed block in btree_split_sibling error path
2015-12-11Merge branch 'for-linus' of ↵Linus Torvalds2-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse fixes from Miklos Szeredi: "Two bugfixes, both bound for -stable" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: fuse: break infinite loop in fuse_fill_write_pages() cuse: fix memory leak
2015-12-11Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds16-112/+131
Pull drm fixes from Dave Airlie: "Not too much this time. - One nouveau workaround extended to a few more GPUs - Some amdgpu big endian fixes, and a regression fixer - Some vmwgfx fixes - One ttm locking fix - One vgaarb fix" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: vgaarb: fix signal handling in vga_get() radeon: Fix VCE IB test on Big-Endian systems radeon: Fix VCE ring test for Big-Endian systems radeon/cik: Fix GFX IB test on Big-Endian drm/amdgpu: fix the lost duplicates checking drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default drm/vmwgfx: Implement the cursor_set2 callback v2 drm/vmwgfx: fix a warning message drm/ttm: Fixed a read/write lock imbalance
2015-12-11gpio: ath79: Fix the logic to clear offset bit of AR71XX_GPIO_REG_OE registerAxel Lin1-1/+1
Signed-off-by: Axel Lin <[email protected]> Acked-by: Alban Bedel <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-12-11arm64: Improve error reporting on set_pte_at() checksCatalin Marinas1-4/+8
Currently the BUG_ON() checks do not give enough information about the PTEs being set. This patch changes BUG_ON to WARN_ONCE and dumps the values of the old and new PTEs. In addition, the checks are only made if the new PTE entry is valid. Signed-off-by: Catalin Marinas <[email protected]> Reported-by: Ming Lei <[email protected]> Cc: Will Deacon <[email protected]>
2015-12-11ARM: dts: vf610: use reset values for L2 cache latenciesStefan Agner2-6/+1
Linux on Vybrid used several different L2 latencies so far, none of them seem to be the right ones. According to the application note AN4947 ("Understanding Vybrid Architecture"), the tag portion runs on CPU clock and is inside the L2 cache controller, whereas the data portion is stored in the external SRAM running on platform clock. Hence it is likely that the correct value requires a higher data latency then tag latency. These are the values which have been used so far: - The mainline values: arm,data-latency = <1 1 1>; arm,tag-latency = <2 2 2>; Those values have lead to problems on higher clocks. They look like a poor translation from the reset values (missing +1 offset and a mix up between tag/latency values). - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation): arm,data-latency = <4 2 3> arm,tag-latency = <4 2 3> The cache initialization function along with the value matches the i.MX6 code from the same kernel, so it seems that those values have just been copied. - The Colibri values: arm,data-latency = <2 1 2>; arm,tag-latency = <3 2 3>; Those were a mix between the values of the Linux 3.0 based BSP and the mainline values above. - The SoC Reset values (converted to DT notation): arm,data-latency = <3 3 3>; arm,tag-latency = <2 2 2>; So far there is no official statement on what the correct values are. See also the related Freescale community thread: https://community.freescale.com/message/579785#579785 For now, the reset values seem to be the best bet. Remove all other "bogus" values and use the reset value on vf610.dtsi level. Signed-off-by: Stefan Agner <[email protected]> Cc: <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2015-12-11vgaarb: fix signal handling in vga_get()Kirill A. Shutemov1-2/+4
There are few defects in vga_get() related to signal hadning: - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE case; - if we found pending signal we must remove ourself from wait queue and change task state back to running; - -ERESTARTSYS is more appropriate, I guess. Signed-off-by: Kirill A. Shutemov <[email protected]> Cc: [email protected] Reviewed-by: David Herrmann <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2015-12-11Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie3-55/+59
into drm-fixes some big endian fixes and one regression fix. * 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux: radeon: Fix VCE IB test on Big-Endian systems radeon: Fix VCE ring test for Big-Endian systems radeon/cik: Fix GFX IB test on Big-Endian drm/amdgpu: fix the lost duplicates checking
2015-12-11Merge tag 'omap-for-v4.4/fixes-rc4' of ↵Arnd Bergmann4-5/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "omap fixes against v4.4-rc4" from Tony Lindgren Few fixes for omaps for v4.4-rc cycle: - Fix clock source for ARM TWD and global timers on am437x - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of when MACH_OMAP3_PANDORA is selected - Fix SPI DMA handles for dm816x as only some were mapped - Fix up mbox cells for dm816x to make mailbox usable * tag 'omap-for-v4.4/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: am4372: fix clock source for arm twd and global timers ARM: OMAP2+: enable REGULATOR_FIXED_VOLTAGE ARM: dts: add dm816x missing spi DT dma handles ARM: dts: add dm816x missing #mbox-cells
2015-12-11ARM: pxa: use PWM lookup table for all machinesArnd Bergmann1-0/+5
The recent change to use a pwm lookup table for the ezx machines was incomplete and only changed the a780 model, but not the other ones in the same file. This adds the missing calls to pwm_add_table(). Signed-off-by: Arnd Bergmann <[email protected]> Fixes: c3322022897c ("ARM: pxa: ezx: Use PWM lookup table") Acked-by: Thierry Reding <[email protected]> Acked-by: Robert Jarzmik <[email protected]>
2015-12-11Merge tag 'berlin-fixes-for-4.4-rc1-1' of ↵Arnd Bergmann1-3/+5
git://git.infradead.org/users/hesselba/linux-berlin into fixes Merge "Marvell Berlin fixes for 4.4-rc1 (round 1)" from Sebastian Hesselbarth: - fix wrong SDIO DT clocks on BG2Q * tag 'berlin-fixes-for-4.4-rc1-1' of git://git.infradead.org/users/hesselba/linux-berlin: ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1 ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock
2015-12-11Merge tag 'at91-4.4-fixes-2' of ↵Arnd Bergmann3-2/+12
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into fixes Merge "Second fixes for 4.4" from Alexandre Belloni: - fix of a hardware setup that prevents the sd/mmc interface to show up on sama5d2. - proper selection of pinctrl drivers. PIO4 is necessary for the sama5d2 to boot. * tag 'at91-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: ARM: at91: fix pinctrl driver selection ARM: at91/dt: add always-on to 1.8V regulator
2015-12-11Merge tag 'samsung-fixes-4.4' of ↵Arnd Bergmann4-4/+8
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into fixes Merge "Fixes for Exynos" from Krzysztof Kozlowski: 1. Fix potential NULL pointer dereference in Exynos PMU driver. 2. Remove incorrect __init annotation from s3c24xx cpufreq driver structures. * tag 'samsung-fixes-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: cpufreq: s3c24xx: Do not mark s3c2410_plls_add as __init ARM: EXYNOS: Fix potential NULL pointer access in exynos_sys_powerdown_conf
2015-12-10Merge tag 'for-linus' of ↵Linus Torvalds19-102/+146
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma Pull rdma fixes from Doug Ledford: "Most are minor to important fixes. There is one performance enhancement that I took on the grounds that failing to check if other processes can run before running what's intended to be a background, idle-time task is a bug, even though the primary effect of the fix is to improve performance (and it was a very simple patch)" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: IB/mlx5: Postpone remove_keys under knowledge of coming preemption IB/mlx4: Use vmalloc for WR buffers when needed IB/mlx4: Use correct order of variables in log message iser-target: Remove explicit mlx4 work-around mlx4: Expose correct max_sge_rd limit IB/mad: Require CM send method for everything except ClassPortInfo IB/cma: Add a missing rcu_read_unlock() IB core: Fix ib_sg_to_pages() IB/srp: Fix srp_map_sg_fr() IB/srp: Fix indirect data buffer rkey endianness IB/srp: Initialize dma_length in srp_map_idb IB/srp: Fix possible send queue overflow IB/srp: Fix a memory leak IB/sa: Put netlink request into the request list before sending IB/iser: use sector_div instead of do_div IB/core: use RCU for uverbs id lookup IB/qib: Minor fixes to qib per SFF 8636 IB/core: Fix user mode post wr corruption IB/qib: Fix qib_mr structure
2015-12-10pinctrl: intel: fix offset calculation issue of register PAD_OWNQipeng Zha1-4/+5
The calculation equation of PAD_OWN register offset is not correct for Broxton, verified this fix will get right offset for Broxton. Signed-off-by: Qi Zheng <[email protected]> Signed-off-by: Qipeng Zha <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-12-10pinctrl: intel: fix bug of register offset calculationQipeng Zha4-17/+20
The group size for registers PADCFGLOCK, HOSTSW_OWN, GPI_IS, GPI_IE, are not 24 for Broxton, Add a parameter to allow different platform to set correct value. Signed-off-by: Qi Zheng <[email protected]> Signed-off-by: Qipeng Zha <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-12-10ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1Jisheng Zhang1-2/+4
We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag, so the sdhci0 and sdhci1 don't work. We fix this by adding the optional 2nd clock for BG2Q's sdhci0 and sdhci1. This patch brings another benefit: the 2nd clock can be disabled during runtime pm, so saves power a bit. Signed-off-by: Jisheng Zhang <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]>
2015-12-10ARM: dts: berlin: correct BG2Q's sdhci2 2nd clockJisheng Zhang1-1/+1
The optional 2nd clock is CLKID_SDIO. We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag, so the sdhci2 doesn't work. This patch fixes this issue by correcting the sdhci2's 2nd clock. Signed-off-by: Jisheng Zhang <[email protected]> Signed-off-by: Sebastian Hesselbarth <[email protected]>
2015-12-10Merge tag 'sound-4.4-rc5' of ↵Linus Torvalds5-17/+85
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Again less intensive changes in this rc: you can find only a few HD-audio fixes (noise fixes for Intel Broxton chip and a few Thinkpad models, quirks for Alienware 17 and Packard Bell DOTS) in addition to a long-standing rme96 bug fix" * tag 'sound-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/ca0132 - quirk for Alienware 17 2015 ALSA: hda - Fix noise problems on Thinkpad T440s ALSA: hda - Fixing speaker noise on the two latest thinkpad models ALSA: hda - Add inverted dmic for Packard Bell DOTS ALSA: hda - Fix playback noise with 24/32 bit sample size on BXT ALSA: rme96: Fix unexpected volume reset after rate changes
2015-12-10clocksource: Mmio: remove artificial 32bit limitationLinus Walleij1-1/+1
The EP93xx is registering a clocksource of 40 bits with clocksource_mmio_init() but this is not working because of this artificial limitation. It works fine to lift the uppe limit to 64 bits, and since cycle_t is u64, it should intuitively have been like that from the beginning. Fixes: 000bc17817bf "ARM: ep93xx: switch to GENERIC_CLOCKEVENTS" Reported-by: Alexander Sverdlin <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Cc: Daniel Lezcano <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2015-12-10irqchip/gic-v3: Add missing include for barrier.hMarc Zyngier2-0/+2
Both the 32bit and 64bit versions of the GICv3 header file are using barriers, but neglect to include barrier.h, leading to an interesting splat in some circumstances. Signed-off-by: Marc Zyngier <[email protected]> Cc: <[email protected]> Cc: Jason Cooper <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2015-12-10irqchip/gic-v3: Add missing struct device_node declarationMarc Zyngier1-0/+1
When the GICv3 header file is used in a C file that doesn't include any of the OF stuff, we end up with a bunch of ugly warnings. Let's keep GCC quiet by adding a forward declaration. Signed-off-by: Marc Zyngier <[email protected]> Cc: <[email protected]> Cc: Jason Cooper <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2015-12-10Revert "SCSI: Fix NULL pointer dereference in runtime PM"Ken Xue1-10/+10
This reverts commit 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime PM") The old commit may lead to a issue that blk_{pre|post}_runtime_suspend and blk_{pre|post}_runtime_resume may not be called in pairs. Take sr device as example, when sr device goes to runtime suspend, blk_{pre|post}_runtime_suspend will be called since sr device defined pm->runtime_suspend. But blk_{pre|post}_runtime_resume will not be called since sr device doesn't have pm->runtime_resume. so, sr device can not resume correctly anymore. More discussion can be found from below link. http://marc.info/?l=linux-scsi&m=144163730531875&w=2 Signed-off-by: Ken Xue <[email protected]> Acked-by: Alan Stern <[email protected]> Cc: Xiangliang Yu <[email protected]> Cc: James E.J. Bottomley <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Michael Terry <[email protected]> Cc: [email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2015-12-10netfilter: nf_dup: add missing dependencies with NF_CONNTRACKPablo Neira Ayuso2-0/+2
CONFIG_NF_CONNTRACK=m CONFIG_NF_DUP_IPV4=y results in: net/built-in.o: In function `nf_dup_ipv4': >> (.text+0xd434f): undefined reference to `nf_conntrack_untracked' Reported-by: kbuild test robot <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2015-12-10netfilter: nfnetlink: fix splat due to incorrect socket memory accounting in ↵Pablo Neira Ayuso1-2/+0
skbuff clones If we attach the sk to the skb from nfnetlink_rcv_batch(), then netlink_skb_destructor() will underflow the socket receive memory counter and we get warning splat when releasing the socket. $ cat /proc/net/netlink sk Eth Pid Groups Rmem Wmem Dump Locks Drops Inode ffff8800ca903000 12 0 00000000 -54144 0 0 2 0 17942 ^^^^^^ Rmem above shows an underflow. And here below the warning splat: [ 1363.815976] WARNING: CPU: 2 PID: 1356 at net/netlink/af_netlink.c:958 netlink_sock_destruct+0x80/0xb9() [...] [ 1363.816152] CPU: 2 PID: 1356 Comm: kworker/u16:1 Tainted: G W 4.4.0-rc1+ #153 [ 1363.816155] Hardware name: LENOVO 23259H1/23259H1, BIOS G2ET32WW (1.12 ) 05/30/2012 [ 1363.816160] Workqueue: netns cleanup_net [ 1363.816163] 0000000000000000 ffff880119203dd0 ffffffff81240204 0000000000000000 [ 1363.816169] ffff880119203e08 ffffffff8104db4b ffffffff813d49a1 ffff8800ca771000 [ 1363.816174] ffffffff81a42b00 0000000000000000 ffff8800c0afe1e0 ffff880119203e18 [ 1363.816179] Call Trace: [ 1363.816181] <IRQ> [<ffffffff81240204>] dump_stack+0x4e/0x79 [ 1363.816193] [<ffffffff8104db4b>] warn_slowpath_common+0x9a/0xb3 [ 1363.816197] [<ffffffff813d49a1>] ? netlink_sock_destruct+0x80/0xb9 skb->sk was only needed to lookup for the netns, however we don't need this anymore since 633c9a840d0b ("netfilter: nfnetlink: avoid recurrent netns lookups in call_batch") so this patch removes this manual socket assignment to resolve this problem. Reported-by: Arturo Borrero Gonzalez <[email protected]> Reported-by: Ben Hutchings <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Arturo Borrero Gonzalez <[email protected]>
2015-12-10pinctrl: freescale: add ZERO_OFFSET_VALID flag for vf610 pinctrlShawn Guo1-1/+1
To support i.MX7D Low Power State Retention IOMUXC, commit e7b37a522aa9 ("pinctrl: freescale: imx: allow mux_reg offset zero") changes the way of zero mux_reg offset support with a new flag ZERO_OFFSET_VALID. But, unfortunately, it forgot to add this flag for vf610 pinctrl which has zero mux_reg offset be valid as well, and hence breaks the vf610 support. Fix the regression by adding flag ZERO_OFFSET_VALID for vf610 pinctrl driver. Signed-off-by: Shawn Guo <[email protected]> Fixes: e7b37a522aa9 ("pinctrl: freescale: imx: allow mux_reg offset zero") Reported-by: Andrew Lunn <[email protected]> Tested-by: Andrew Lunn <[email protected]> Acked-by: Stefan Agner <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-12-10hwmon: (tmp102) Force wait for conversion time for the first valid dataNishanth Menon1-1/+15
TMP102 works based on conversions done periodically. However, as per the TMP102 data sheet[1] the first conversion is triggered immediately after we program the configuration register. The temperature data registers do not reflect proper data until the first conversion is complete (in our case HZ/4). The driver currently sets the last_update to be jiffies - HZ, just after the configuration is complete. When TMP102 driver registers with the thermal framework, it immediately tries to read the sensor temperature data. This takes place even before the conversion on the TMP102 is complete and results in an invalid temperature read. Depending on the value read, this may cause thermal framework to assume that a critical temperature event has occurred and attempts to shutdown the system. Instead of causing an invalid mid-conversion value to be read erroneously, we mark the last_update to be in-line with the current jiffies. This allows the tmp102_update_device function to skip update until the required conversion time is complete. Further, we ensure to return -EAGAIN result instead of returning spurious temperature (such as 0C) values to the caller to prevent any wrong decisions made with such values. NOTE: this allows the read functions not to be blocking and allows the callers to make the decision if they would like to block or try again later. At least the current user(thermal) seems to handle this by retrying later. A simpler alternative approach could be to sleep in the probe for the duration required, but that will result in latency that is undesirable and delay boot sequence un-necessarily. [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf Cc: Eduardo Valentin <[email protected]> Reported-by: Aparna Balasubramanian <[email protected]> Reported-by: Elvita Lobo <[email protected]> Reported-by: Yan Liu <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2015-12-10ses: Fix problems with simple enclosuresJames Bottomley1-1/+19
Simple enclosure implementations (mostly USB) are allowed to return only page 8 to every diagnostic query. That really confuses our implementation because we assume the return is the page we asked for and end up doing incorrect offsets based on bogus information leading to accesses outside of allocated ranges. Fix that by checking the page code of the return and giving an error if it isn't the one we asked for. This should fix reported bugs with USB storage by simply refusing to attach to enclosures that behave like this. It's also good defensive practise now that we're starting to see more USB enclosures. Reported-by: Andrea Gelmini <[email protected]> Cc: [email protected] Reviewed-by: Ewan D. Milne <[email protected]> Reviewed-by: Tomas Henzl <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2015-12-10dm btree: fix bufio buffer leaks in dm_btree_del() error pathJoe Thornber1-1/+15
If dm_btree_del()'s call to push_frame() fails, e.g. due to btree_node_validator finding invalid metadata, the dm_btree_del() error path must unlock all frames (which have active dm-bufio buffers) that were pushed onto the del_stack. Otherwise, dm_bufio_client_destroy() will BUG_ON() because dm-bufio buffers have leaked, e.g.: device-mapper: bufio: leaked buffer 3, hold count 1, list 0 Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected]
2015-12-10netfilter: nfnetlink: avoid recurrent netns lookups in call_batchPablo Neira Ayuso3-53/+47
Pass the net pointer to the call_batch callback functions so we can skip recurrent lookups. Signed-off-by: Pablo Neira Ayuso <[email protected]> Tested-by: Arturo Borrero Gonzalez <[email protected]>
2015-12-10btrfs: fix misleading warning when space cache failed to loadHolger Hoffstätte1-1/+1
When an inconsistent space cache is detected during loading we log a warning that users frequently mistake as instruction to invalidate the cache manually, even though this is not required. Fix the message to indicate that the cache will be rebuilt automatically. Signed-off-by: Holger Hoffstätte <[email protected]> Acked-by: Filipe Manana <[email protected]>
2015-12-10drm/i915: Do a better job at disabling primary plane in the noatomic case.Maarten Lankhorst1-1/+3
When disable_noatomic is called plane_mask is not correct yet, and plane_state->visible = true is left as true after disabling the primary plane. Other planes are already disabled as part of crtc sanitization, only the primary is left active. But the plane_mask is not updated here. It gets updated during fb takeover in modeset_gem_init, or set to the new value on resume. This means that to disable the primary plane 1 << drm_plane_index(primary) needs to be used. Afterwards because the crtc is no longer active it's forbidden to keep plane_state->visible set, or a WARN_ON in intel_plane_atomic_calc_changes triggers. There are other code points that rely on accurate plane_state->visible too, so make sure the bool is cleared. The other planes are already disabled in intel_sanitize_crtc, so they don't have to be handled here. Cc: [email protected] #v4.3, v4.2? Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92655 Tested-by: Tomas Mezzadra <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 54a4196188eab82e6f0a5f05716626e9f18b8fb6) Signed-off-by: Jani Nikula <[email protected]>
2015-12-10Btrfs: fix transaction handle leak in balanceFilipe Manana1-2/+1
If we fail to allocate a new data chunk, we were jumping to the error path without release the transaction handle we got before. Fix this by always releasing it before doing the jump. Fixes: 2c9fe8355258 ("btrfs: Fix lost-data-profile caused by balance bg") Signed-off-by: Filipe Manana <[email protected]>
2015-12-10Btrfs: fix unprotected list move from unused_bgs to deleted_bgs listFilipe Manana3-5/+8
As of my previous change titled "Btrfs: fix scrub preventing unused block groups from being deleted", the following warning at extent-tree.c:btrfs_delete_unused_bgs() can be hit when we mount the a filesysten with "-o discard": 10263 void btrfs_delete_unused_bgs(struct btrfs_fs_info *fs_info) 10264 { (...) 10405 if (trimming) { 10406 WARN_ON(!list_empty(&block_group->bg_list)); 10407 spin_lock(&trans->transaction->deleted_bgs_lock); 10408 list_move(&block_group->bg_list, 10409 &trans->transaction->deleted_bgs); 10410 spin_unlock(&trans->transaction->deleted_bgs_lock); 10411 btrfs_get_block_group(block_group); 10412 } (...) This happens because scrub can now add back the block group to the list of unused block groups (fs_info->unused_bgs). This is dangerous because we are moving the block group from the unused block groups list to the list of deleted block groups without holding the lock that protects the source list (fs_info->unused_bgs_lock). The following diagram illustrates how this happens: CPU 1 CPU 2 cleaner_kthread() btrfs_delete_unused_bgs() sees bg X in list fs_info->unused_bgs deletes bg X from list fs_info->unused_bgs scrub_enumerate_chunks() searches device tree using its commit root finds device extent for block group X gets block group X from the tree fs_info->block_group_cache_tree (via btrfs_lookup_block_group()) sets bg X to RO (again) scrub_chunk(bg X) sets bg X back to RW mode adds bg X to the list fs_info->unused_bgs again, since it's still unused and currently not in that list sets bg X to RO mode btrfs_remove_chunk(bg X) --> discard is enabled and bg X is in the fs_info->unused_bgs list again so the warning is triggered --> we move it from that list into the transaction's delete_bgs list, but we can have another task currently manipulating the first list (fs_info->unused_bgs) Fix this by using the same lock (fs_info->unused_bgs_lock) to protect both the list of unused block groups and the list of deleted block groups. This makes it safe and there's not much worry for more lock contention, as this lock is seldom used and only the cleaner kthread adds elements to the list of deleted block groups. The warning goes away too, as this was previously an impossible case (and would have been better a BUG_ON/ASSERT) but it's not impossible anymore. Reproduced with fstest btrfs/073 (using MOUNT_OPTIONS="-o discard"). Signed-off-by: Filipe Manana <[email protected]>
2015-12-10rfkill: copy the name into the rfkill structJohannes Berg1-3/+3
Some users of rfkill, like NFC and cfg80211, use a dynamic name when allocating rfkill, in those cases dev_name(). Therefore, the pointer passed to rfkill_alloc() might not be valid forever, I specifically found the case that the rfkill name was quite obviously an invalid pointer (or at least garbage) when the wiphy had been renamed. Fix this by making a copy of the rfkill name in rfkill_alloc(). Cc: [email protected] Signed-off-by: Johannes Berg <[email protected]>
2015-12-10dmaengine: at_xdmac: fix at_xdmac_prep_dma_memcpy()Cyrille Pitchen1-0/+1
This patch fixes at_xdmac_prep_dma_memcpy(). Indeed the data width field of the Channel Configuration register was not updated properly in the loop: the bits of the dwidth field were not cleared before adding their new value. Signed-off-by: Cyrille Pitchen <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Fixes: e1f7c9eee70 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Cc: [email protected] #4.1 and later Signed-off-by: Vinod Koul <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.