- 09 Nov, 2015 40 commits
-
-
David Howells authored
commit ab79efab upstream. In ovl_copy_up_locked(), newdentry is leaked if the function exits through out_cleanup as this just to out after calling ovl_cleanup() - which doesn't actually release the ref on newdentry. The out_cleanup segment should instead exit through out2 as certainly newdentry leaks - and possibly upper does also, though this isn't caught given the catch of newdentry. Without this fix, something like the following is seen: BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs] BUG: Dentry ffff880023ece640{i=0,n=bigfile} still in use (1) [unmount of tmpfs tmpfs] when unmounting the upper layer after an error occurred in copyup. An error can be induced by creating a big file in a lower layer with something like: dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000)) to create a large file (4.1G). Overlay an upper layer that is too small (on tmpfs might do) and then induce a copy up by opening it writably. Reported-by:
Ulrich Obergfell <uobergfe@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Howells authored
commit 0480334f upstream. Open the lower file with O_LARGEFILE in ovl_copy_up(). Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for catching 32-bit userspace dealing with a file large enough that it'll be mishandled if the application isn't aware that there might be an integer overflow. Inside the kernel, there shouldn't be any problems. Reported-by:
-
Konstantin Khlebnikov authored
commit 5ffdbe8b upstream. This fixes memory leak after umount. Kmemleak report: unreferenced object 0xffff8800ba791010 (size 8): comm "mount", pid 2394, jiffies 4294996294 (age 53.920s) hex dump (first 8 bytes): 20 1c 13 02 00 88 ff ff ....... backtrace: [<ffffffff811f8cd4>] create_object+0x124/0x2c0 [<ffffffff817a059b>] kmemleak_alloc+0x7b/0xc0 [<ffffffff811dffe6>] __kmalloc+0x106/0x340 [<ffffffffa0152bfc>] ovl_fill_super+0x55c/0x9b0 [overlay] [<ffffffff81200ac4>] mount_nodev+0x54/0xa0 [<ffffffffa0152118>] ovl_mount+0x18/0x20 [overlay] [<ffffffff81201ab3>] mount_fs+0x43/0x170 [<ffffffff81220d34>] vfs_kern_mount+0x74/0x170 [<ffffffff812233ad>] do_mount+0x22d/0xdf0 [<ffffffff812242cb>] SyS_mount+0x7b/0xc0 [<ffffffff817b6bee>] entry_SYSCALL_64_fastpath+0x12/0x76 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
-
Konstantin Khlebnikov authored
commit 0f95502a upstream. This fixes small memory leak after mount. Kmemleak report: unreferenced object 0xffff88003683fe00 (size 16): comm "mount", pid 2029, jiffies 4294909563 (age 33.380s) hex dump (first 16 bytes): 20 27 1f bb 00 88 ff ff 40 4b 0f 36 02 88 ff ff '......@K.6.... backtrace: [<ffffffff811f8cd4>] create_object+0x124/0x2c0 [<ffffffff817a059b>] kmemleak_alloc+0x7b/0xc0 [<ffffffff811dffe6>] __kmalloc+0x106/0x340 [<ffffffffa01b7a29>] ovl_fill_super+0x389/0x9a0 [overlay] [<ffffffff81200ac4>] mount_nodev+0x54/0xa0 [<ffffffffa01b7118>] ovl_mount+0x18/0x20 [overlay] [<ffffffff81201ab3>] mount_fs+0x43/0x170 [<ffffffff81220d34>] vfs_kern_mount+0x74/0x170 [<ffffffff812233ad>] do_mount+0x22d/0xdf0 [<ffffffff812242cb>] SyS_mount+0x7b/0xc0 [<ffffffff817b6bee>] entry_SYSCALL_64_fastpath+0x12/0x76 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:
-
Sasha Levin authored
commit 12669631 upstream. 63692df1 ("PCI: Allow numa_node override via sysfs") didn't check that the numa node provided by userspace is valid. Passing a node number too high would attempt to access invalid memory and trigger a kernel panic. Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs") Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Peter Zijlstra authored
commit 275d7d44 upstream. Poma (on the way to another bug) reported an assertion triggering: [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90 [<ffffffff81150822>] __module_address+0x32/0x150 [<ffffffff81150956>] __module_text_address+0x16/0x70 [<ffffffff81150f19>] symbol_put_addr+0x29/0x40 [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core] Laura Abbott <labbott@redhat.com> produced a patch which lead us to inspect symbol_put_addr(). This function has a comment claiming it doesn't need to disable preemption around the module lookup because it holds a reference to the module it wants to find, which therefore cannot go away. This is wrong (and a false optimization too, preempt_disable() is really rather cheap, and I doubt any of this is on uber critical paths, otherwise it would've retained a pointer to the actual module anyway and avoided the second lookup). While its true that the module cannot go away while we hold a reference on it, the data structure we do the lookup in very much _CAN_ change while we do the lookup. Therefore fix the comment and add the required preempt_disable(). Reported-by:
poma <pomidorabelisima@gmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Fixes: a6e6abd5 ("module: remove module_text_address()") Signed-off-by:
-
Cathy Avery authored
commit a54c8f0f upstream. xen-blkfront will crash if the check to talk_to_blkback() in blkback_changed()(XenbusStateInitWait) returns an error. The driver data is freed and info is set to NULL. Later during the close process via talk_to_blkback's call to xenbus_dev_fatal() the null pointer is passed to and dereference in blkfront_closing. Signed-off-by:
Cathy Avery <cathy.avery@oracle.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Laura Abbott authored
commit fd7cd061 upstream. We received several reports of systems rebooting and powering on after an attempted shutdown. Testing showed that setting XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT quirk allowed the system to shutdown as expected for LynxPoint-LP xHCI controllers. Set the quirk back. Note that the quirk was originally introduced for LynxPoint and LynxPoint-LP just for this same reason. See: commit 638298dc ("xhci: Fix spurious wakeups after S5 on Haswell") It was later limited to only concern HP machines as it caused regression on some machines, see both bug and commit: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 commit 6962d914 ("xhci: Limit the spurious wakeup fix only to HP machines") Later it was discovered that the powering on after shutdown was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP machine suffered from spontaneous resume from S3 (which should not be related to the SPURIOUS_WAKEUP quirk at all). An attempt to fix this then removed the SPURIOUS_WAKEUP flag usage completely. commit b45abacd ("xhci: no switching back on non-ULT Haswell") Current understanding is that LynxPoint-LP (Haswell ULT) machines need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and plain Lynxpoint (Haswell) machines may _not_ have the quirk set otherwise they again will restart. Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Cc: Takashi Iwai <tiwai@suse.de> Cc: Oliver Neukum <oneukum@suse.com> [Added more history to commit message -Mathias] Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 3b4739b8 upstream. If a host fails to wake up a isochronous SuperSpeed device from U1/U2 in time for a isoch transfer it will generate a "No ping response error" Host will then move to the next transfer descriptor. Handle this case in the same way as missed service errors, tag the current TD as skipped and handle it on the next transfer event. Signed-off-by:
-
Scot Doyle authored
commit f235f664 upstream. Since commit 27a4c827 fbcon: use the cursor blink interval provided by vt a PPC64LE kernel fails to boot when fbcon_add_cursor_timer uses an uninitialized ops->cur_blink_jiffies. Prevent by initializing in fbcon_init before the call to info->fbops->fb_set_par. Reported-and-tested-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
Scot Doyle <lkml14@scotdoyle.com> Signed-off-by:
-
Russell King authored
commit 625faa6a upstream. clk_add_alias() was not correctly handling the case where alias_dev_name was NULL: rather than producing an entry with a NULL dev_id pointer, it would produce a device name of (null). Fix this. Fixes: 25689998 ("clkdev: add clkdev_create() helper") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Hezi Shahmoon authored
commit 0729a049 upstream. Commit 00d8689b ("i2c: mv64xxx: rework offload support to fix several problems") completely reworked the offload support, but left a debugging-related "return false" at the beginning of the mv64xxx_i2c_can_offload() function. This has the unfortunate consequence that offloading is in fact never used, which wasn't really the intention. This commit fixes that problem by removing the bogus "return false". Fixes: 00d8689b ("i2c: mv64xxx: rework offload support to fix several problems") Signed-off-by:
Hezi Shahmoon <hezi@marvell.com> [Thomas: reworked commit log and title.] Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Bjørn Mork authored
commit f504ab18 upstream. New device IDs shamelessly lifted from the vendor driver. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Frederic Danis authored
commit f967fc8f upstream. This reverts commit 9119fba0. This commit prevents from sending "big" file using Bluetooth. When sending a lot of data quickly through the Bluetooth interface, and after a variable amount of data sent, transfer fails with error: kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00 Found on T100TA. After reverting this commit, send works fine for any file size. Signed-off-by:
Frederic Danis <frederic.danis@linux.intel.com> Fixes: 9119fba0 (serial: 8250_dma: don't bother DMA with small transfers) Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit 835da3f9 upstream. Compiling the nvme driver on 32-bit warns about a cast from a __u64 variable to a pointer: drivers/block/nvme-core.c: In function 'nvme_submit_io': drivers/block/nvme-core.c:1847:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (void __user *)io.addr, length, NULL, 0); The cast here is intentional and safe, so we can shut up the gcc warning by adding an intermediate cast to 'uintptr_t'. I had previously submitted a patch to fix this problem in the nvme driver, but it was accepted on the same day that two new warnings got added. For clarification, I also change the third instance of this cast to use uintptr_t instead of unsigned long now. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: d29ec824 ("nvme: submit internal commands through the block layer") Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Mike Snitzer authored
commit 4dcb8b57 upstream. btree_split_beneath()'s error path had an outstanding FIXME that speaks directly to the potential for _not_ cleaning up a previously allocated bufio-backed block. Fix this by releasing the previously allocated bufio block using unlock_block(). Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Joe Thornber <thornber@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit 3201ac45 upstream. If the CLEAN_SHUTDOWN flag is not set when a cache is loaded then all cache blocks are marked as dirty and a full writeback occurs. __commit_transaction() is responsible for setting/clearing CLEAN_SHUTDOWN (based the flags_mutator that is passed in). Fix this issue, of the cache's on-disk flags being wrong, by making sure __commit_transaction() does not reset the flags after the mutator has altered the flags in preparation for them being serialized to disk. before: sb_flags = mutator(le32_to_cpu(disk_super->flags)); disk_super->flags = cpu_to_le32(sb_flags); disk_super->flags = cpu_to_le32(cmd->flags); after: disk_super->flags = cpu_to_le32(cmd->flags); sb_flags = mutator(le32_to_cpu(disk_super->flags)); disk_super->flags = cpu_to_le32(sb_flags); Reported-by:
Bogdan Vasiliev <bogdan.vasiliev@gmail.com> Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Joe Thornber authored
commit 2871c69e upstream. Commit 4c7e3093 ("dm btree remove: fix bug in redistribute3") wasn't a complete fix for redistribute3(). The redistribute3 function takes 3 btree nodes and shares out the entries evenly between them. If the three nodes in total contained (MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in the center. Fix this issue by being more careful about calculating the target number of entries for the left and right nodes. Unit tested in userspace using this program: https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.cSigned-off-by:
-
Tejun Heo authored
commit b02176f3 upstream. bdi's are initialized in two steps, bdi_init() and bdi_register(), but destroyed in a single step by bdi_destroy() which, for a bdi embedded in a request_queue, is called during blk_cleanup_queue() which makes the queue invisible and starts the draining of remaining usages. A request_queue's user can access the congestion state of the embedded bdi as long as it holds a reference to the queue. As such, it may access the congested state of a queue which finished blk_cleanup_queue() but hasn't reached blk_release_queue() yet. Because the congested state was embedded in backing_dev_info which in turn is embedded in request_queue, accessing the congested state after bdi_destroy() was called was fine. The bdi was destroyed but the memory region for the congested state remained accessible till the queue got released. a13f35e8 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") changed the situation. Now, the root congested state which is expected to be pinned while request_queue remains accessible is separately reference counted and the base ref is put during bdi_destroy(). This means that the root congested state may go away prematurely while the queue is between bdi_dstroy() and blk_cleanup_queue(), which was detected by Andrey's KASAN tests. The root cause of this problem is that bdi doesn't distinguish the two steps of destruction, unregistration and release, and now the root congested state actually requires a separate release step. To fix the issue, this patch separates out bdi_unregister() and bdi_exit() from bdi_destroy(). bdi_unregister() is called from blk_cleanup_queue() and bdi_exit() from blk_release_queue(). bdi_destroy() is now just a simple wrapper calling the two steps back-to-back. While at it, the prototype of bdi_destroy() is moved right below bdi_setup_and_register() so that the counterpart operations are located together. Signed-off-by:
Tejun Heo <tj@kernel.org> Fixes: a13f35e8 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback") Reported-and-tested-by:
Andrey Konovalov <andreyknvl@google.com> Link: http://lkml.kernel.org/g/CAAeHK+zUJ74Zn17=rOyxacHU18SgCfC6bsYW=6kCY5GXJBwGfQ@mail.gmail.comReviewed-by:
Jan Kara <jack@suse.com> Reviewed-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
-
Lorenzo Pieralisi authored
commit e13d918a upstream. Commit dd006da2 ("arm64: mm: increase VA range of identity map") introduced a mechanism to extend the virtual memory map range to support arm64 systems with system RAM located at very high offset, where the identity mapping used to enable/disable the MMU requires additional translation levels to map the physical memory at an equal virtual offset. The kernel detects at boot time the tcr_el1.t0sz value required by the identity mapping and sets-up the tcr_el1.t0sz register field accordingly, any time the identity map is required in the kernel (ie when enabling the MMU). After enabling the MMU, in the cold boot path the kernel resets the tcr_el1.t0sz to its default value (ie the actual configuration value for the system virtual address space) so that after enabling the MMU the memory space translated by ttbr0_el1 is restored as expected. Commit dd006da2 ("arm64: mm: increase VA range of identity map") also added code to set-up the tcr_el1.t0sz value when the kernel resumes from low-power states with the MMU off through cpu_resume() in order to effectively use the identity mapping to enable the MMU but failed to add the code required to restore the tcr_el1.t0sz to its default value, when the core returns to the kernel with the MMU enabled, so that the kernel might end up running with tcr_el1.t0sz value set-up for the identity mapping which can be lower than the value required by the actual virtual address space, resulting in an erroneous set-up. This patchs adds code in the resume path that restores the tcr_el1.t0sz default value upon core resume, mirroring this way the cold boot path behaviour therefore fixing the issue. Cc: Catalin Marinas <catalin.marinas@arm.com> Fixes: dd006da2 ("arm64: mm: increase VA range of identity map") Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
commit 9702970c upstream. This reverts commit e306dfd0. With this patch applied, we were the only architecture making this sort of adjustment to the PC calculation in the unwinder. This causes problems for ftrace, where the PC values are matched against the contents of the stack frames in the callchain and fail to match any records after the address adjustment. Whilst there has been some effort to change ftrace to workaround this, those patches are not yet ready for mainline and, since we're the odd architecture in this regard, let's just step in line with other architectures (like arch/arm/) for now. Signed-off-by:
-
H. Nikolaus Schaller authored
commit 38850d78 upstream. Commit 8a603f91 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") unfortunately introduced a bug created but not found during discussion and patch simplification. Reported-by:
Efraim Yawitz <efraim.yawitz@gmail.com> Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Fixes: 8a603f91 ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h") Signed-off-by:
Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by:
-
H. Nikolaus Schaller authored
commit 8a603f91 upstream. If the host toolchain is not glibc based then the arm kernel build fails with HOSTCC arch/arm/vdso/vdsomunge arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or directory Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF cross-compiler. Reason: byteswap.h is a glibc only header. Solution: replace by private byte-swapping macros (taken from arch/mips/boot/elf2ecoff.c and kindly improved by Russell King) Tested to compile on Mac OS X 10.9.5 host. Signed-off-by:
-
Aaro Koskinen authored
commit 1bd5dfe4 upstream. Commit 685e2d08 ("ARM: OMAP1: Change interrupt numbering for sparse IRQ") turned on SPARSE_IRQ on OMAP1, but forgot to change the number of INT_DMA_LCD. This broke the boot at least on Nokia 770, where the device hangs during framebuffer initialization. Fix by defining INT_DMA_LCD like the other interrupts. Fixes: 685e2d08 ("ARM: OMAP1: Change interrupt numbering for sparse IRQ") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Linus Walleij authored
commit 83bf6b13 upstream. commit 1d8aca9d "ARM: ux500: fix MMC/SD card regression" fixed broken the level shifter: it should be default ON but became default OFF. Fixes: 1d8aca9d "ARM: ux500: fix MMC/SD card regression" Reported-and-tested-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Tomi Valkeinen authored
commit 7e381ec6 upstream. LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to be kept always powered (see commit 5a0f93c6 ("ARM: dts: Add am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled depending on whether an SD card is inserted or not. This patch sets LDO1 regulator to always-on. This patch has a side effect of fixing another issue, HDMI DDC not working when SD card is not inserted: Why this happens is that the tpd12s015 (HDMI level shifter/ESD protection chip) has LS_OE GPIO input, which needs to be enabled for the HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD. So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays off. The proper fix for the HDMI DDC issue would be to maybe have the pinctrl framework manage the pin specific power. Apparently this fixes also a third issue (copy paste from Kishon's patch): ldo1_reg in addition to being connected to the io lines is also connected to the card detect line. On card removal, omap_hsmmc driver does a regulator_disable causing card detect line to be pulled down. This raises a card insertion interrupt and once the MMC core detects there is no card inserted, it does a regulator disable which again raises a card insertion interrupt. This happens in a loop causing infinite MMC interrupts. Fixes: 5a0f93c6 ("ARM: dts: Add am57xx-beagle-x15") Cc: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by:
Louis McCarthy <compeoree@gmail.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Fabio Estevam authored
commit 178b2d09 upstream. The UART2 memory space starts at address 0x30890000 (UART2_URXD). Fix it so that UART2 can be used. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Fixes: 94967345 ("ARM: dts: add imx7d soc dtsi file") Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Alim Akhtar authored
commit b8bb9baa upstream. Since commit 2fad972d ("ARM: dts: Add mclk entry for Peach boards"), sound card detection is broken on peach boards and gives below errors: [ 3.630457] max98090 7-0010: MAX98091 REVID=0x51 [ 3.634233] max98090 7-0010: use default 2.8v micbias [ 3.640985] snow-audio sound: HiFi <-> 3830000.i2s mapping ok [ 3.645307] max98090 7-0010: Invalid master clock frequency [ 3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() failed: -22 [ 3.658914] snow-audio sound: snd_soc_register_card failed (-22) [ 3.664366] snow-audio: probe of sound failed with error -22 This patch adds missing assigned-clocks and assigned-clock-parents for pmu_system_controller node which is used as "mclk" for audio codec. Fixes: 2fad972d ("ARM: dts: Add mclk entry for Peach boards") Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Kukjin Kim <kgene@kernel.org> Signed-off-by:
-
Thomas Hebb authored
commit 1f744fd3 upstream. Currently, BG2Q shares a compatible with BG2. This is incorrect, since BG2 and BG2Q use different USB PLL dividers. In reality, BG2Q shares a divider with BG2CD. Change BG2Q's USB PHY compatible string to reflect that. Signed-off-by:
Thomas Hebb <tommyhebb@gmail.com> Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Marcin Wojtas authored
commit db347f1a upstream. This commit enables standby support on Armada 385 DB-AP board, because the PM initalization routine requires "marvell,armada380" compatible string for all Armada 38x-based platforms. Beside the compatible "marvell,armada38x" was wrong and should be fixed in the stable kernels too. [gregory.clement@free-electrons.com: add information, about the fixes] Fixes: e5ee1281 ("ARM: mvebu: Add Armada 385 Access Point Development Board support") Signed-off-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Florian Fainelli authored
commit d836ace6 upstream. DSA expects the host_dev pointer to be the device structure associated with the MDIO bus controller driver. First commit breaking that was c3a07134 ("mv643xx_eth: convert to use the Marvell Orion MDIO driver"), and then, it got completely under the radar for a while. Reported-by:
Frans van de Wiel <fvdw@fvdw.eu> Fixes: c3a07134 ("mv643xx_eth: convert to use the Marvell Orion MDIO driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 51a6256b upstream. On each next iteration of for_each_compatible_node() the reference counter for current device node is already decreased by the loop iterator. The manual call to of_node_get() is required only on loop break which is not happening here. The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to decreasing the counter below expected, initial value. Fixes: fe4034a3 ("ARM: EXYNOS: Add missing of_node_put() when parsing power domains") Signed-off-by:
-
Ilya Dryomov authored
commit 6d69bb53 upstream. Mapping an image with a long parent chain (e.g. image foo, whose parent is bar, whose parent is baz, etc) currently leads to a kernel stack overflow, due to the following recursion in the reply path: rbd_osd_req_callback() rbd_obj_request_complete() rbd_img_obj_callback() rbd_img_parent_read_callback() rbd_obj_request_complete() ... Limit the parent chain to 16 images, which is ~5K worth of stack. When the above recursion is eliminated, this limit can be lifted. Fixes: http://tracker.ceph.com/issues/12538Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Josh Durgin <jdurgin@redhat.com> Signed-off-by:
-
Ilya Dryomov authored
commit 1f2c6651 upstream. Currently we leak parent_spec and trigger a "parent reference underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails. The problem is we take the !parent out_err branch and that only drops refcounts; parent_spec that would've been freed had we called rbd_dev_unparent() remains and triggers rbd_warn() in rbd_dev_parent_put() - at that point we have parent_spec != NULL and parent_ref == 0, so counter ends up being -1 after the decrement. Redo rbd_dev_probe_parent() to fix this. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Ronny Hegewald authored
commit bae818ee upstream. rbd requires stable pages, as it performs a crc of the page data before they are send to the OSDs. But since kernel 3.9 (patch 1d1d1a76 "mm: only enforce stable page writes if the backing device requires it") it is not assumed anymore that block devices require stable pages. This patch sets the necessary flag to get stable pages back for rbd. In a ceph installation that provides multiple ext4 formatted rbd devices "bad crc" messages appeared regularly (ca 1 message every 1-2 minutes on every OSD that provided the data for the rbd) in the OSD-logs before this patch. After this patch this messages are pretty much gone (only ca 1-2 / month / OSD). Signed-off-by:
Ronny Hegewald <Ronny.Hegewald@online.de> [idryomov@gmail.com: require stable pages only in crc case, changelog] [idryomov@gmail.com: backport to 3.18-4.2: context] Signed-off-by:
-
Dan Carpenter authored
commit eda7d0f3 upstream. "num_read" is in byte units but we are write u16s so we end up write twice as much as intended. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Linus Walleij authored
commit 61fd5630 upstream. This accelerometer accidentally either emits a DRDY signal or an IRQ signal. Accidentally I activated the IRQ signal as I thought it was analogous to the interrupt generator on other ST accelerometers. This was wrong. After this patch generic_buffer gives a nice stream of accelerometer readings. Fixes: 3acddf74 "iio: st-sensors: add support for lis3lv02d accelerometer" Cc: Denis CIOCCA <denis.ciocca@st.com> Signed-off-by:
-
Alexandre Belloni authored
commit b94e2280 upstream. 0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset. Also improve the comment explaining the calculation. Reported-by:
Janusz Użycki <j.uzycki@elpromaelectronics.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
Marek Vasut <marex@denx.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Alex Deucher authored
commit 4cee6a90 upstream. So that the bl encoder will be null if the GPU does not control the backlight. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit ae93580e upstream. If driver backlight control is disabled, either by driver parameter or default per-asic setting, revert to the old behavior. Fixes a regression in commit: 4281f46eReviewed-by:
-
