https://github.com/torvalds/linux

sort by:
Revision Author Date Message Commit Date
2c32c65 ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may falsely trigger a watchpoint exception, leading to potential data aborts during exception return and/or livelock. This patch resolves the issue in the following ways: - Replacing our uses of CLREX with a dummy STREX sequence instead (as we did for v6 CPUs). - Removing the clrex code from v7_exit_coherency_flush and derivatives, since this only exists as a minor performance improvement when non-cached exclusives are in use (Linux doesn't use these). Benchmarking on a variety of ARM cores revealed no measurable performance difference with this change applied, so the change is performed unconditionally and no new Kconfig entry is added. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 27 August 2014, 14:40:13 UTC
8586831 ARM: 8128/1: abort: don't clear the exclusive monitors The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors upon entry to the kernel, but this is redundant: - We clear the monitors on every exception return since commit 200b812d0084 ("Clear the exclusive monitor when returning from an exception"), so this is not necessary to ensure the monitors are cleared before returning from a fault handler. - Any dummy STREX will target a temporary scratch area in memory, and may succeed or fail without corrupting useful data. Its status value will not be used. - Any other STREX in the kernel must be preceded by an LDREX, which will initialise the monitors consistently and will not depend on the earlier state of the monitors. Therefore we have no reason to care about the initial state of the exclusive monitors when a data abort is taken, and clearing the monitors prior to exception return (as we already do) is sufficient. This patch removes the redundant clearing of the exclusive monitors from the early abort handlers. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 27 August 2014, 14:40:12 UTC
55f0fb6 ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations Kernel module build with GCOV profiling fails to load with the following error: $ insmod test_module.ko test_module: unknown relocation: 38 insmod: can't insert 'test_module.ko': invalid module format This happens because constructor pointers in the .init_array section have not supported R_ARM_TARGET1 relocation type. Documentation (ELF for the ARM Architecture) says: "The relocation must be processed either in the same way as R_ARM_REL32 or as R_ARM_ABS32: a virtual platform must specify which method is used." Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1 relocation type should be treated the same way as R_ARM_ABS32. Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> 27 August 2014, 14:40:11 UTC
f395dca x86: irq: Fix bug in setting IOAPIC pin attributes Commit 15a3c7cc9154321fc3 "x86, irq: Introduce two helper functions to support irqdomain map operation" breaks LPSS ACPI enumerated devices. On startup, IOAPIC driver preallocates IRQ descriptors and programs IOAPIC pins with default level and polarity attributes for all legacy IRQs. Later legacy IRQ users may fail to set IOAPIC pin attributes if the requested attributes conflicts with the default IOAPIC pin attributes. So change mp_irqdomain_map() to allow the first legacy IRQ user to reprogram IOAPIC pin with different attributes. Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Grant Likely <grant.likely@linaro.org> Cc: Prarit Bhargava <prarit@redhat.com> Link: http://lkml.kernel.org/r/1409118795-17046-1-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 27 August 2014, 09:02:16 UTC
844817e HID: picolcd: sanity check report size in raw_event() callback The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that raw_data that we hold in picolcd_pending structure are always kept within proper bounds. Cc: stable@vger.kernel.org Reported-by: Steven Vittitoe <scvitti@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 27 August 2014, 07:14:39 UTC
c54def7 HID: magicmouse: sanity check report size in raw_event() callback The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that magicmouse_emit_touch() gets only valid values of raw_id. Cc: stable@vger.kernel.org Reported-by: Steven Vittitoe <scvitti@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 27 August 2014, 07:14:39 UTC
1a22e77 ALSA: hda - Set up initial pins for Acer Aspire V5 Acer Aspire V5 doesn't set up the pins correctly at the cold boot while the pins are corrected after the warm reboot. This patch gives the proper pin configs statically in the driver as a workaround. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81561 Signed-off-by: Takashi Iwai <tiwai@suse.de> 27 August 2014, 06:19:05 UTC
bf81472 ARM: dts: microsom-ar8035: MDIO pad must be set open drain This patch is important for the MicroSOM implementation due to the following details - 1. VIH of the Atheros phy is 1.7V. 2. NVCC_ENET which is the power domain of the MDIO pad is driven by the PHY's LDO (i.e. either 1.8v or 2.5v). 3. The MicroSOM implements an onbouard 1.6kohm pull up to 3.3v (R3000). In the case the PHY's LDO was 1.8v then there would be only a 100mV margin for the signal to be acknowledged as high (1.8v-1.7v). Due to that setting the pad as an open drain will let the 1.6kohm pull that signal high to 3.3 that assures enough margins to the PHY to be acked as '1' logic. Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@freescale.com> 27 August 2014, 05:32:26 UTC
8fe7a26 tomoyo: Fix pathname calculation breakage. Commit 7177a9c4b509 ("fs: call rename2 if exists") changed "struct inode_operations"->rename == NULL if "struct inode_operations"->rename2 != NULL . TOMOYO needs to check for both ->rename and ->rename2 , or a system on (e.g.) ext4 filesystem won't boot. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> 27 August 2014, 02:52:09 UTC
0393689 usb: ehci/ohci-exynos: Fix PHY getting sequence Since we want to keep support for both older usb-phys as well as the newer generic phys, lets first get the generic PHYs and fallback to older USB-PHYs only when we fail to get the former. This should fix the issue with ehci-exynos and ohci-exynos, wherein in the absence of SAMSUNG_USB2PHY config symbol, we end up getting the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs are not configured properly. Reported-by: Sachin Kamat <sachin.kamat@samsung.com> Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Jingoo Han <jg1.han@samsung.com> Tested-by: Sachin Kamat <sachin.kamat@samsung.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 26 August 2014, 22:59:14 UTC
bdd405d usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1 If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" Cc: [3.8+] <stable@vger.kernel.org> Signed-off-by: Roger Quadros <rogerq@ti.com> Tested-by: Michael Welling <mwelling@emacinc.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 26 August 2014, 22:59:14 UTC
72ad366 thunderbolt: Clear hops before overwriting Zero hops in tb_path_activate before writing a new path. This fixes the following scenario: - Boot with a coldplugged device - Unplug device - Plug device back in - PCI hotplug fails The hotplug operation fails because our new path matches the (now defunct) path which was setup by the firmware for the coldplugged device. By writing zeros before writing our path configuration we can force thunderbolt to retrain the path. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 26 August 2014, 21:54:48 UTC
68e3702 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Martin Schwidefsky: - wire up the system calls seccomp, getrandom and memfd_create - use static system information as input to add_device_randomness - .. and three bug fixes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/sclp: remove unnecessary XTABS flag s390/3215: fix tty output containing tabs s390: wire up memfd_create syscall s390: add system information as device randomness s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL s390: wire up seccomp and getrandom syscalls 26 August 2014, 20:50:23 UTC
ac490f4 Documentation: this_cpu_ops.txt: Update description of this_cpu_ops Update the description for per cpu operations to clarify use cases of this_cpu operations and add considerations for remote access. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Signed-off-by: Christoph Lameter <cl@linux.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 August 2014, 20:49:57 UTC
270a009 scripts/kernel-doc: recognize __meminit Fix scripts/kernel-doc to recognize __meminit in a function prototype and to strip it, as done with many other attributes. Fixes this warning: Warning(..//mm/page_alloc.c:2973): cannot understand function prototype: 'void * __meminit alloc_pages_exact_nid(int nid, size_t size, gfp_t gfp_mask) ' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 26 August 2014, 20:49:57 UTC
f87d928 NFSv3: Fix another acl regression When creating a new object on the NFS server, we should not be sending posix setacl requests unless the preceding posix_acl_create returned a non-trivial acl. Doing so, causes Solaris servers in particular to return an EINVAL. Fixes: 013cdf1088d72 (nfs: use generic posix ACL infrastructure,,,) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1132786 Cc: stable@vger.kernel.org # 3.14+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> 26 August 2014, 20:17:48 UTC
412f6c4 NFSv4: Don't clear the open state when we just did an OPEN_DOWNGRADE If we did an OPEN_DOWNGRADE, then the right thing to do on success, is to apply the new open mode to the struct nfs4_state. Instead, we were unconditionally clearing the state, making it appear to our state machinery as if we had just performed a CLOSE. Fixes: 226056c5c312b (NFSv4: Use correct locking when updating nfs4_state...) Cc: stable@vger.kernel.org # 3.15+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> 26 August 2014, 20:17:48 UTC
aee7af3 NFSv4: Fix problems with close in the presence of a delegation In the presence of delegations, we can no longer assume that the state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open stateid share mode, and so we need to calculate the initial value for calldata->arg.fmode using the state->flags. Reported-by: James Drews <drews@engr.wisc.edu> Fixes: 88069f77e1ac5 (NFSv41: Fix a potential state leakage when...) Cc: stable@vger.kernel.org # 2.6.33+ Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> 26 August 2014, 20:17:48 UTC
8fd4643 ARM: dts: omap54xx-clocks: Fix the l3 and l4 clock rates Similarly to DRA7, OMAP5 has l3 and l4 clock rates incorrectly calculated. Fixed by using proper divider clock types for the clock nodes. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 26 August 2014, 20:04:00 UTC
5b6b80a USB: sisusb: add device id for Magic Control USB video I have a j5 create (JUA210) USB 2 video device and adding it device id to SIS USB video gets it to work. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 26 August 2014, 19:07:46 UTC
0a5f6e9 drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2) This is a port of cedb655a3a7764c3fd946077944383c9e0e68dd4 to older asics. Fixes a possible divide by 0 if the harvest register is invalid. v2: drop some additional harvest munging. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 26 August 2014, 16:21:06 UTC
054e01d drm/radeon: save/restore the PD addr on suspend/resume This fixes a problem with GPU resets and TLB flushes on SI/CIK. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 26 August 2014, 16:20:38 UTC
e15693e cfq-iosched: Fix wrong children_weight calculation cfq_group_service_tree_add() is applying new_weight at the beginning of the function via cfq_update_group_weight(). This actually allows weight to change between adding it to and subtracting it from children_weight, and triggers WARN_ON_ONCE() in cfq_group_service_tree_del(), or even causes oops by divide error during vfr calculation in cfq_group_service_tree_add(). The detailed scenario is as follows: 1. Create blkio cgroups X and Y as a child of X. Set X's weight to 500 and perform some I/O to apply new_weight. This X's I/O completes before starting Y's I/O. 2. Y starts I/O and cfq_group_service_tree_add() is called with Y. 3. cfq_group_service_tree_add() walks up the tree during children_weight calculation and adds parent X's weight (500) to children_weight of root. children_weight becomes 500. 4. Set X's weight to 1000. 5. X starts I/O and cfq_group_service_tree_add() is called with X. 6. cfq_group_service_tree_add() applies its new_weight (1000). 7. I/O of Y completes and cfq_group_service_tree_del() is called with Y. 8. I/O of X completes and cfq_group_service_tree_del() is called with X. 9. cfq_group_service_tree_del() subtracts X's weight (1000) from children_weight of root. children_weight becomes -500. This triggers WARN_ON_ONCE(). 10. Set X's weight to 500. 11. X starts I/O and cfq_group_service_tree_add() is called with X. 12. cfq_group_service_tree_add() applies its new_weight (500) and adds it to children_weight of root. children_weight becomes 0. Calcularion of vfr triggers oops by divide error. weight should be updated right before adding it to children_weight. Reported-by: Ruki Sekiya <sekiya.ruki@lab.ntt.co.jp> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Acked-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> 26 August 2014, 16:17:30 UTC
0d9509d drm/msm: Fix missing unlock on error in msm_fbdev_create() Add the missing unlock before return from function msm_fbdev_create() in the error handling case. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Rob Clark <robdclark@gmail.com> 26 August 2014, 14:43:31 UTC
12313c2 drm/msm: fix compile error for non-dt builds Signed-off-by: Rob Clark <robdclark@gmail.com> 26 August 2014, 14:43:31 UTC
119ecb7 drm/msm/mdp4: request vblank during modeset This avoids a problem seen with weston (for example) where the display gets stuck in "black screen" if starting weston first thing after boot. Possibly mdp5 needs something similar. The downstream android fbdev driver always requests DMA_E (or DMA_P) when display is active, rather than only enabling it on-demand as the drm driver does, which I believe has the same end result. Signed-off-by: Rob Clark <robdclark@gmail.com> 26 August 2014, 14:43:31 UTC
6814dbf drm/msm: avoid flood of kernel logs on faults 87e956e9 changed the fault handler to return -ENOSYS, which causes the iommu driver to print out a huge splat. Which wouldn't be quite so bad if nothing ever faulted. But seems like some EXA composite operations generate quite a lot of (seemingly harmless) faults. That is probably a userspace problem, but the huge increase in verbosity from iommu fault dumps makes things kind of unusable. We probably should actually log *some* message (not conditional on drm.debug). But ratelimit it. Signed-off-by: Rob Clark <robdclark@gmail.com> 26 August 2014, 14:43:31 UTC
d19d744 block: fix error handling in sg_io Before commit 2cada584b200 ("block: cleanup error handling in sg_io"), we had ret = 0 before entering the last big if block of sg_io. Since 2cada584b200, ret = -EFAULT, which breaks hdparm: /dev/sda: setting Advanced Power Management level to 0xc8 (200) HDIO_DRIVE_CMD failed: Bad address APM_level = 128 Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Fixes: 2cada584b200 ("block: cleanup error handling in sg_io") Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com> 26 August 2014, 14:20:01 UTC
4d4e2c0 video: da8xx-fb: preserve display width when changing HSYNC When looking at this driver for a client, I noticed the code that configures the HSYNC pulse clobbers the display width in the same register. It only preserves the MS part of the width in bit 3 and zeros the LS part of the width in bits 9 to 4. This doesn't matter during initialization as the width is configured afterwards, but subsequent use of the FBIPUT_HSYNC ioctl would clobber the width. Preserve bits 9 to 0 of LCD_RASTER_TIMING_0_REG when configuring the horizontal sync. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 26 August 2014, 12:36:51 UTC
f5ec6c4 drm: sti: Add missing dependency on RESET_CONTROLLER Add missing dependency on RESET_CONTROLLER in order to fix the following build error. drivers/gpu/drm/sti/sti_hdmi.c: In function 'sti_hdmi_probe' drivers/gpu/drm/sti/sti_hdmi.c:780:2: error: implicit declaration of function 'devm_reset_control_get' [-Werror=implicit-function-declaration] Benjamin Gaignard remark: I have change "depends on" to "select" but keep the original author name. Signed-off-by: Jingoo Han <jg1.han@samsung.com> 26 August 2014, 12:17:02 UTC
8e932cf drm: sti: Make of_device_id array const Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Kiran Padwal <kiran.padwal@smartplayin.com> 26 August 2014, 12:16:58 UTC
eacd9aa drm: sti: Fix return value check in sti_drm_platform_probe() In case of error, the function platform_device_register_resndata() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> 26 August 2014, 12:16:51 UTC
5024a2b drm: sti: hda: fix return value check in sti_hda_probe() In case of error, the function devm_ioremap_nocache() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> 26 August 2014, 12:16:46 UTC
88cfc3f drm: sti: hdmi: fix return value check in sti_hdmi_probe() In case of error, the function devm_ioremap_nocache() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> 26 August 2014, 12:16:39 UTC
31f32a2 drm: sti: tvout: fix return value check in sti_tvout_probe() In case of error, the function devm_ioremap_nocache() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> 26 August 2014, 12:16:32 UTC
62795a0 video: of: display_timing: double free on error The display_timings_release() function frees "disp" and we free it again on the next line. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 26 August 2014, 11:23:47 UTC
6c13185 drivers: video: fbdev: atmel_lcdfb.c: fix error return code Convert a zero return value on error to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> ( if@p1 (\(ret < 0\|ret != 0\)) { ... return ret; } | ret@p1 = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 26 August 2014, 10:04:15 UTC
2b6c53b video: ARM CLCD: Fix calculation of bits-per-pixel If the device-tree specifies a max-memory-bandwidth property then the CLCD driver uses that to calculate the bits-per-pixel supported, however, this calculation is faulty for two reasons. 1. It doesn't ensure that the result is a sane value, i.e. a power of 2 and <= 32 as the rest of the code assumes. 2. It uses the displayed resolution and calculates the average bandwidth across the whole frame. It should instead calculate the peak bandwidth based on the pixel clock. This patch fixes both the above. Signed-off-by: Jon Medhurst <tixy@linaro.org> Acked-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 26 August 2014, 09:50:27 UTC
754d561 fbdev: Remove __init from chips_hw_init() to fix build failure Fix build failure caused as follows: The function chipsfb_pci_init() references the function __init chips_hw_init(). This is often because chipsfb_pci_init lacks a __init annotation or the annotation of chips_hw_init is wrong. make: *** [drivers] Error 2 by removing the __init annotation from chips_hw_init(). The other thing that could have been done was annotating chipsfb_pci_init(). But that cannot be done since chipsfb_pci_init() is called from non __init functions. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 26 August 2014, 09:48:34 UTC
fc3e825 ARM: brcmstb: revert SMP support There were several issues (of varying degree of importance) pointed out with this code late in the review cycle, yet the code was still merged. Let's rip it out for now and look at resubmitting at a later time. This reverts most of commit 4fbe66d9903425156c193ae44c81c0f7557755c4. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Olof Johansson <olof@lixom.net> 26 August 2014, 01:46:31 UTC
4ce97db trace: Fix epoll hang when we race with new entries Epoll on trace_pipe can sometimes hang in a weird case. If the ring buffer is empty when we set waiters_pending but an event shows up exactly at that moment we can miss being woken up by the ring buffers irq work. Since ring_buffer_empty() is inherently racey we will sometimes think that the buffer is not empty. So we don't get woken up and we don't think there are any events even though there were some ready when we added the watch, which makes us hang. This patch fixes this by making sure that we are actually on the wait list before we set waiters_pending, and add a memory barrier to make sure ring_buffer_empty() is going to be correct. Link: http://lkml.kernel.org/p/1408989581-23727-1-git-send-email-jbacik@fb.com Cc: stable@vger.kernel.org # 3.10+ Cc: Martin Lau <kafai@fb.com> Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 26 August 2014, 00:18:11 UTC
1bfbd8e ACPI / LPSS: Add ACPI IDs for Intel Braswell Enable more identifiers for the existing devices for Intel Braswell and Cherryview. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 26 August 2014, 00:17:31 UTC
558e473 ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC There is platform refusing to respond QR_EC when SCI_EVT isn't set which is Acer Aspire V5-573G. By disallowing QR_EC to be issued before the previous one has been completed we are able to reduce the possibilities to trigger issues on such platforms. Note that this fix can only reduce the occurrence rate of this issue, but this issue may still occur when such a platform doesn't clear SCI_EVT before or immediately after completing the previous QR_EC transaction. This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. But this patch is still useful as it can help to reduce the number of scheduled QR_EC work items. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 26 August 2014, 00:15:51 UTC
3afcf2e ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set There is a platform refusing to respond QR_EC when SCI_EVT isn't set (Acer Aspire V5-573G). Currently, we rely on the behaviour that the EC firmware can respond something (for example, 0x00 to indicate "no outstanding events") to QR_EC even when SCI_EVT is not set, but the reporter has complained about AC/battery pluging/unpluging and video brightness change delay on that platform. This is because the work item that has issued QR_EC has to wait until timeout in this case, and the _Qxx method evaluation work item queued after QR_EC one is delayed. It sounds reasonable to fix this issue by: 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC driver's main state machine. 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation to a seperate IRQ handling thread. This patch fixes this issue using solution 1. By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to handle such platform in the EC driver's main state machine. This patch enhances the state machine in this way to survive with such malfunctioning EC firmware. Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed() Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 26 August 2014, 00:15:47 UTC
236105d ACPI: Run fixed event device notifications in process context Currently, notify callbacks for fixed button events are run from interrupt context. That is not necessary and after commit 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine) it causes netlink routines to be called from interrupt context which is not correct. Also, that is different from non-fixed device events (including non-fixed button events) whose notify callbacks are all executed from process context. For the above reasons, make fixed button device notify callbacks run in process context which will avoid the deadlock when using netlink to report button events to user space. Fixes: 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine) Link: https://lkml.org/lkml/2014/8/21/606 Reported-by: Benjamin Block <bebl@mageta.org> Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> [rjw: Function names, subject and changelog.] Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 25 August 2014, 23:29:24 UTC
fc2e0a8 ACPI / scan: Allow ACPI drivers to bind to PNP device objects We generally don't allow ACPI drivers to bind to ACPI device objects that companion "physical" device objects are created for to avoid situations in which two different drivers may attempt to handle one device at the same time. Recent ACPI device enumeration rework extended that approach to ACPI PNP devices by starting to use a scan handler for enumerating them. However, we previously allowed ACPI drivers to bind to ACPI device objects with existing PNP device companions and changing that led to functional regressions on some systems. For this reason, add a special check for PNP devices in acpi_device_probe() so that ACPI drivers can bind to ACPI device objects having existing PNP device companions as before. Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration) Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511 Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971 Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Reported-by: Dirk Griesbach <spamthis@freenet.de> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 25 August 2014, 23:29:21 UTC
cc82453 ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled Looks like MUSB cable removal can cause wake-up interrupts to stop working for device tree based booting at least for UART3 even as nothing is dynamically remuxed. This can be fixed by calling reconfigure_io_chain() for device tree based booting in hwmod code. Note that we already do that for legacy booting if the legacy mux is configured. My guess is that this is related to UART3 and MUSB ULPI hsusb0_data0 and hsusb0_data1 support for Carkit mode that somehow affect the configured IO chain for UART3 and require rearming the wake-up interrupts. In general, for device tree based booting, pinctrl-single calls the rearm hook that in turn calls reconfigure_io_chain so calling reconfigure_io_chain should not be needed from the hwmod code for other events. So let's limit the hwmod rearming of iochain only to HWMOD_FORCE_MSTANDBY where MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it. Cc: Paul Walmsley <paul@pwsan.com> Cc: stable@vger.kernel.org # v3.16 Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:35 UTC
c15adae ARM: dts: Enable UART wake-up events for beagleboard For device tree based booting, we need to use wake-up interrupts like we already do for some omaps. This fixes a PM regression on beagleboard compared to legacy booting. Tested-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:35 UTC
509a81f ARM: dts: Remove twl6030 clk32g "regulator" The kernel has never supported clk32g as a regulator since it is a clock and not a regulator. Fortunately nothing actually references this node so we can just remove it. Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:34 UTC
9a02ae4 ARM: OMAP2+: omap_device: remove warning that clk alias already exists When an alias for a clock already exists the warning is printed. For every module with a main_clk defined, a clk alias for fck is added. There are some components that have the same main_clk defined, so this is a really normal situation. For example the am33xx edma device has 4 components using the same main clock. So there are three warnings in the boot log for this already existing clock alias: platform 49000000.edma: alias fck already exists platform 49000000.edma: alias fck already exists platform 49000000.edma: alias fck already exists As this is only interesting for developers, this patch changes the message to a debug message. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:34 UTC
6953faf ARM: OMAP: fix %d confusingly prefixed with 0x in format string Fix %d confusingly prefixed with 0x in format string. Signed-off-by: Hans Wennborg <hans@hanshq.net> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:34 UTC
e49d519 ARM: dts: DRA7: fix interrupt-cells for GPIO GPIO modules are also interrupt sources. However, they require both the GPIO number and IRQ type to function properly. By declaring that GPIO uses interrupt-cells=<1>, we essentially do not allow users of the nodes to use the interrupt property appropritely. With this change, the following now works: interrupt-parent = <&gpio6>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>; Fixes: 6e58b8f1daaf ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board') Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:34 UTC
40ddbf5 mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc() commit 65b97cf6b8de introduced in v3.7 caused a regression by using a reversed CS_MASK thus causing omap_calculate_ecc to always fail. As the NAND base driver never checks for .calculate()'s return value, the zeroed ECC values are used as is without showing any error to the user. However, this won't work and the NAND device won't be guarded by any error code. Fix the issue by using the correct mask. Code was tested on omap3beagle using the following procedure - flash the primary bootloader (MLO) from the kernel to the first NAND partition using nandwrite. - boot the board from NAND. This utilizes OMAP ROM loader that relies on 1-bit Hamming code ECC. Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc) Cc: <stable@vger.kernel.org> [3.7+] Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:33 UTC
d5c1eb1 ARM: dts: omap3430-sdp: Revert to using software ECC for NAND For v3.14 and prior, 1-bit Hamming code ECC via software was used for NAND on this board. Commit c06c52701695 in v3.15 changed the behaviour to use 1-bit Hamming code via Hardware using a different ECC layout i.e. (ROM code layout) than what is used by software ECC. This ECC layout change causes NAND filesystems created in v3.14 and prior to be unusable in v3.15 and later. So revert back to using software ECC scheme. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:33 UTC
a3e83f0 ARM: OMAP2+: GPMC: Support Software ECC scheme via DT For v3.14 and prior, 1-bit Hamming code ECC via software was the default choice for some boards e.g. 3430sdp. Commit ac65caf514ec in v3.15 changed the behaviour to use 1-bit Hamming code via Hardware using a different ECC layout i.e. (ROM code layout) than what is used by software ECC. This ECC layout change causes NAND filesystems created in v3.14 and prior to be unusable in v3.15 and later. So don't mark "sw" scheme as deperecated and support it. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:33 UTC
7d5929c mtd: nand: omap: Revert to using software ECC by default For v3.12 and prior, 1-bit Hamming code ECC via software was the default choice. Commit c66d039197e4 in v3.13 changed the behaviour to use 1-bit Hamming code via Hardware using a different ECC layout i.e. (ROM code layout) than what is used by software ECC. This ECC layout change causes NAND filesystems created in v3.12 and prior to be unusable in v3.13 and later. So revert back to using software ECC by default if an ECC scheme is not explicitely specified. This defect can be observed on the following boards during legacy boot -omap3beagle -omap3touchbook -overo -am3517crane -devkit8000 -ldp -3430sdp Signed-off-by: Roger Quadros <rogerq@ti.com> Tested-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com> 25 August 2014, 23:15:32 UTC
52addcf Linux 3.17-rc2 25 August 2014, 22:36:20 UTC
f01bfc9 Merge tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client fixes from Trond Myklebust: "Highlights: - more fixes for read/write codepath regressions * sleeping while holding the inode lock * stricter enforcement of page contiguity when coalescing requests * fix up error handling in the page coalescing code - don't busy wait on SIGKILL in the file locking code" * tag 'nfs-for-3.17-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: nfs: Don't busy-wait on SIGKILL in __nfs_iocounter_wait nfs: can_coalesce_requests must enforce contiguity nfs: disallow duplicate pages in pgio page vectors nfs: don't sleep with inode lock in lock_and_join_requests nfs: fix error handling in lock_and_join_requests nfs: use blocking page_group_lock in add_request nfs: fix nonblocking calls to nfs_page_group_lock nfs: change nfs_page_group_lock argument 25 August 2014, 22:34:28 UTC
dd5957b Merge tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas Pull SH driver fix from Simon Horman: "Confine SH_INTC to platforms that need it" * tag 'renesas-sh-drivers-for-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: sh: intc: Confine SH_INTC to platforms that need it 25 August 2014, 22:29:33 UTC
497c01d Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus Pull MIPS fixes from Ralf Baechle: "Pretty much all across the field so with this we should be in reasonable shape for the upcoming -rc2" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: OCTEON: make get_system_type() thread-safe MIPS: CPS: Initialize EVA before bringing up VPEs from secondary cores MIPS: Malta: EVA: Rename 'eva_entry' to 'platform_eva_init' MIPS: EVA: Add new EVA header MIPS: scall64-o32: Fix indirect syscall detection MIPS: syscall: Fix AUDIT value for O32 processes on MIPS64 MIPS: Loongson: Fix COP2 usage for preemptible kernel MIPS: NL: Fix nlm_xlp_defconfig build error MIPS: Remove race window in page fault handling MIPS: Malta: Improve system memory detection for '{e, }memsize' >= 2G MIPS: Alchemy: Fix db1200 PSC clock enablement MIPS: BCM47XX: Fix reboot problem on BCM4705/BCM4785 MIPS: Remove duplicated include from numa.c MIPS: Add common plat_irq_dispatch declaration MIPS: MSP71xx: remove unused plat_irq_dispatch() argument MIPS: GIC: Remove useless parens from GICBIS(). MIPS: perf: Mark pmu interupt IRQF_NO_THREAD 25 August 2014, 22:28:57 UTC
01e9982 Merge tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull fix for ftrace function tracer/profiler conflict from Steven Rostedt: "The rewrite of the ftrace code that makes it possible to allow for separate trampolines had a design flaw with the interaction between the function and function_graph tracers. The main flaw was the simplification of the use of multiple tracers having the same filter (like function and function_graph, that use the set_ftrace_filter file to filter their code). The design assumed that the two tracers could never run simultaneously as only one tracer can be used at a time. The problem with this assumption was that the function profiler could be implemented on top of the function graph tracer, and the function profiler could run at the same time as the function tracer. This caused the assumption to be broken and when ftrace detected this failed assumpiton it would spit out a nasty warning and shut itself down. Instead of using a single ftrace_ops that switches between the function and function_graph callbacks, the two tracers can again use their own ftrace_ops. But instead of having a complex hierarchy of ftrace_ops, the filter fields are placed in its own structure and the ftrace_ops can carefully use the same filter. This change took a bit to be able to allow for this and currently only the global_ops can share the same filter, but this new design can easily be modified to allow for any ftrace_ops to share its filter with another ftrace_ops. The first four patches deal with the change of allowing the ftrace_ops to share the filter (and this needs to go to 3.16 as well). The fifth patch fixes a bug that was also caused by the new changes but only for archs other than x86, and only if those archs implement a direct call to the function_graph tracer which they do not do yet but will in the future. It does not need to go to stable, but needs to be fixed before the other archs update their code to allow direct calls to the function_graph trampoline" * tag 'trace-fixes-v3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace: Use current addr when converting to nop in __ftrace_replace_code() ftrace: Fix function_profiler and function tracer together ftrace: Fix up trampoline accounting with looping on hash ops ftrace: Update all ftrace_ops for a ftrace_hash_ops update ftrace: Allow ftrace_ops to use the hashes from other ops 25 August 2014, 22:11:53 UTC
a2fa672 staging: r8188eu: Add new USB ID The Elecom WDC-150SU2M uses this chip. Reported-by: Hiroki Kondo <kompiro@gmail.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 22:00:56 UTC
a90b858 x86: Fix non-PC platform kernel crash on boot due to NULL dereference Upstream commit: 95d76acc7518d5 ("x86, irq: Count legacy IRQs by legacy_pic->nr_legacy_irqs instead of NR_IRQS_LEGACY") removed reserved interrupts for the platforms that do not have a legacy IOAPIC. Which breaks the boot on Intel MID platforms such as Medfield: BUG: unable to handle kernel NULL pointer dereference at 0000003a IP: [<c107079a>] setup_irq+0xf/0x4d [ 0.000000] *pdpt = 0000000000000000 *pde = 9bbf32453167e510 The culprit is an uncoditional setting of IRQ2 which is used as cascade IRQ on legacy platforms. It seems we have to check if we have enough legacy IRQs reserved before we can call setup_irq(). The fix adds such check in native_init_IRQ() and in setup_default_timer_irq(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: David Cohen <david.a.cohen@linux.intel.com> Link: http://lkml.kernel.org/r/1405931920-12871-1-git-send-email-andriy.shevchenko@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> 25 August 2014, 20:36:57 UTC
8626d52 staging/rtl8188eu: add 0df6:0076 Sitecom Europe B.V. The stick is not recognized. This dongle uses r8188eu but usb-id is missing. 3.16.0 Signed-off-by: Holger Paradies <retabell@gmx.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 20:24:28 UTC
8e8248b mei: nfc: fix memory leak in error path NFC will leak buffer if send failed. Use single exit point that does the freeing Cc: stable@vger.kernel.org #3.10+ Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 20:16:23 UTC
73ab423 mei: reset client state on queued connect request If connect request is queued (e.g. device in pg) set client state to initializing, thus avoid preliminary exit in wait if current state is disconnected. This is regression from: commit e4d8270e604c3202131bac607969605ac397b893 Author: Alexander Usyskin <alexander.usyskin@intel.com> mei: set connecting state just upon connection request is sent to the fw CC: stable@vger.kernel.org # 3.15+ Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 20:16:23 UTC
9b2667f usb: dwc2: gadget: Set the default EP max packet value as 8 bytes Set the default EP max packet value as 8 bytes, because in the case of low-speed, 'ep_mps' is not set. Thus, the default value of 'ep_mps' should be considered for the case of low-speed. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 20:12:27 UTC
5cbcc35 usb: ehci: using wIndex + 1 for hub port The roothub's index per controller is from 0, but the hub port index per hub is from 1, this patch fixes "can't find device at roohub" problem for connecting test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test. This patch is for v3.12+. Cc: stable@vger.kernel.org Signed-off-by: Peter Chen <peter.chen@freescale.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 20:11:27 UTC
a7e69dd USB: storage: add quirk for Newer Technology uSCSI SCSI-USB converter The uSCSI from Newer Technology is a SCSI-USB converter with USB ID 06ca:2003. Like several other SCSI-USB products, it's a Shuttle Technology OEM device. Without a suitable entry in unusual-devs.h, the converter can only access the (single) device with SCSI ID 0. Copying the entry for device 04e6:0002 allows it to work with devices with other SCSI IDs too. There are currently six entries for Shuttle-developed SCSI-USB devices in unusual-devs.h (grep for euscsi): 04e6:0002 Shuttle eUSCSI Bridge USB_SC_DEVICE, USB_PR_DEVICE 04e6:000b Shuttle eUSCSI Bridge USB_SC_SCSI, USB_PR_BULK 04e6:000c Shuttle eUSCSI Bridge USB_SC_SCSI, USB_PR_BULK 050d:0115 Belkin USB SCSI Adaptor USB_SC_SCSI, USB_PR_BULK 07af:0004 Microtech USB-SCSI-DB25 USB_SC_DEVICE, USB_PR_DEVICE 07af:0005 Microtech USB-SCSI-HD50 USB_SC_DEVICE, USB_PR_DEVICE lsusb -v output for the uSCSI lists bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) This patch adds an entry for the uSCSI to unusual_devs.h. Signed-off-by: Mark Knibbs <markk@clara.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 17:46:11 UTC
563da3a MAINTAINERS: Add an entry for USB/IP driver This patch adds an entry in MAINTAINERS file for USB/IP driver. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 17:41:44 UTC
3f653c5 usbip: remove struct usb_device_id table This was used back when usbip-host was an interface device driver; after the conversion to device driver, the table remained unused. Remove it in order to stop receiving a warning about it. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 17:40:58 UTC
96c2737 usbip: move usbip kernel code out of staging At this point, USB/IP kernel code is fully functional and can be moved out of staging. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 17:40:06 UTC
588b48c usbip: move usbip userspace code out of staging At this point, USB/IP userspace code is fully functional and can be moved out of staging. Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 25 August 2014, 17:38:56 UTC
962af86 ARM: dts: hummingboard/cubox-i: change SPDIF output to be more descriptive Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@freescale.com> 25 August 2014, 11:11:21 UTC
f9908c1 ARM: dts: hummingboard/cubox-i: add USB OC pinctrl configuration Hummingboard has no over current hardware, so disable the over current detection for both ports. Cubox-i has over current hardware, so appropriately configure this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@freescale.com> 25 August 2014, 11:11:16 UTC
5abfe85 HID: logitech-dj: prevent false errors to be shown Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 Cc: stable@vger.kernel.org Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 25 August 2014, 07:59:51 UTC
7be141d Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "A couple of EFI fixes, plus misc fixes all around the map" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/arm64: Store Runtime Services revision firmware: Do not use WARN_ON(!spin_is_locked()) x86_32, entry: Clean up sysenter_badsys declaration x86/doc: Fix the 'tlb_single_page_flush_ceiling' sysconfig path x86/mm: Fix sparse 'tlb_single_page_flush_ceiling' warning and make the variable read-mostly x86/mm: Fix RCU splat from new TLB tracepoints 24 August 2014, 23:17:41 UTC
44744bb Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "A kprobes and a perf compat ioctl fix" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Handle compat ioctl kprobes: Skip kretprobe hit in NMI context to avoid deadlock 24 August 2014, 23:16:55 UTC
959dc25 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "A collection of fixes from this week, it's been pretty quiet and nothing really stands out as particularly noteworthy here -- mostly minor fixes across the field: - ODROID booting was fixed due to PMIC interrupts missing in DT - a collection of i.MX fixes - minor Tegra fix for regulators - Rockchip fix and addition of SoC-specific mailing list to make it easier to find posted patches" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: bus: arm-ccn: Fix warning message ARM: shmobile: koelsch: Remove non-existent i2c6 pinmux ARM: tegra: apalis/colibri t30: fix on-module 5v0 supplies MAINTAINERS: add new Rockchip SoC list ARM: dts: rockchip: readd missing mmc0 pinctrl settings ARM: dts: ODROID i2c improvements ARM: dts: Enable PMIC interrupts on ODROID ARM: dts: imx6sx: fix the pad setting for uart CTS_B ARM: dts: i.MX53: fix apparent bug in VPU clks ARM: imx: correct gpu2d_axi and gpu3d_axi clock setting ARM: dts: imx6: edmqmx6: change enet reset pin ARM: dts: vf610-twr: Fix pinctrl_esdhc1 pin definitions. ARM: imx: remove unnecessary ARCH_HAS_OPP select ARM: imx: fix TLB missing of IOMUXC base address during suspend ARM: imx6: fix SMP compilation again ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes 24 August 2014, 22:57:00 UTC
fa7f78e Merge tag 'gpio-v3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull gpio fixes from Linus Walleij: - a largeish fix for the IRQ handling in the new Zynq driver. The quite verbose commit message gives the exact details. - move some defines for gpiod flags outside an ifdef to make stub functions work again. - various minor fixes that we can accept for -rc1. * tag 'gpio-v3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio-lynxpoint: enable input sensing in resume gpio: move GPIOD flags outside #ifdef gpio: delete unneeded test before of_node_put gpio: zynq: Fix IRQ handlers gpiolib: devres: use correct structure type name in sizeof MAINTAINERS: Change maintainer for gpio-bcm-kona.c 24 August 2014, 22:54:23 UTC
5e30ca1 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "Intel and radeon fixes. Post KS/LC git requests from i915 and radeon stacked up. They are all fixes along with some new pci ids for radeon, and one maintainers file entry. - i915: display fixes and irq fixes - radeon: pci ids, and misc gpuvm, dpm and hdp cache" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (29 commits) MAINTAINERS: Add entry for Renesas DRM drivers drm/radeon: add additional SI pci ids drm/radeon: add new bonaire pci ids drm/radeon: add new KV pci id Revert "drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe" drm/radeon: fix active_cu mask on SI and CIK after re-init (v3) drm/radeon: fix active cu count for SI and CIK drm/radeon: re-enable selective GPUVM flushing drm/radeon: Sync ME and PFP after CP semaphore waits v4 drm/radeon: fix display handling in radeon_gpu_reset drm/radeon: fix pm handling in radeon_gpu_reset drm/radeon: Only flush HDP cache for indirect buffers from userspace drm/radeon: properly document reloc priority mask drm/i915: don't try to retrain a DP link on an inactive CRTC drm/i915: make sure VDD is turned off during system suspend drm/i915: cancel hotplug and dig_port work during suspend and unload drm/i915: fix HPD IRQ reenable work cancelation drm/i915: take display port power domain in DP HPD handler drm/i915: Don't try to enable cursor from setplane when crtc is disabled drm/i915: Skip load detect when intel_crtc->new_enable==true ... 24 August 2014, 22:48:12 UTC
d856f32 aio: fix reqs_available handling As reported by Dan Aloni, commit f8567a3845ac ("aio: fix aio request leak when events are reaped by userspace") introduces a regression when user code attempts to perform io_submit() with more events than are available in the ring buffer. Reverting that commit would reintroduce a regression when user space event reaping is used. Fixing this bug is a bit more involved than the previous attempts to fix this regression. Since we do not have a single point at which we can count events as being reaped by user space and io_getevents(), we have to track event completion by looking at the number of events left in the event ring. So long as there are as many events in the ring buffer as there have been completion events generate, we cannot call put_reqs_available(). The code to check for this is now placed in refill_reqs_available(). A test program from Dan and modified by me for verifying this bug is available at http://www.kvack.org/~bcrl/20140824-aio_bug.c . Reported-by: Dan Aloni <dan@kernelim.com> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org> Acked-by: Dan Aloni <dan@kernelim.com> Cc: Kent Overstreet <kmo@daterainc.com> Cc: Mateusz Guzik <mguzik@redhat.com> Cc: Petr Matousek <pmatouse@redhat.com> Cc: stable@vger.kernel.org # v3.16 and anything that f8567a3845ac was backported to Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 24 August 2014, 22:47:27 UTC
1ddb552 Merge tag 'fixes-for-v3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into work-linus Felipe writes: usb: fixes for v3.17-rc2 Here's our first set of fixes for v3.17-rc cycle. Most fixes are pretty minor changes like the signedness bug in dwc3, or the wrong string format on MUSB. The most interesting part is the addition of Intel Quark X1000 support to PCH UDC. Signed-of-by: Felipe Balbi <balbi@ti.com> 24 August 2014, 19:19:55 UTC
6817ae2 USB: whiteheat: Added bounds checking for bulk command response This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by: James Forshaw <forshaw@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 24 August 2014, 19:15:08 UTC
bf87bb1 bus: arm-ccn: Fix warning message A message warning a user about wrong vc value was printing out port instead. Reported-by: Drew Richardson <drew.richardson@arm.com> Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net> 24 August 2014, 18:28:30 UTC
12266db ARM: shmobile: koelsch: Remove non-existent i2c6 pinmux On r8a7791, i2c6 (aka iic3) doesn't need pinmux, but the koelsch dts refers to non-existent pinmux configuration data: pinmux core: sh-pfc does not support function i2c6 sh-pfc e6060000.pfc: invalid function i2c6 in map table Remove it to fix this. Fixes: commit 1d41f36a68c0f4e9b01d563ce33bab5201858b54 ("ARM: shmobile: koelsch dts: Add VDD MPU regulator for DVFS") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Olof Johansson <olof@lixom.net> 24 August 2014, 18:23:28 UTC
caa9eac ARM: tegra: apalis/colibri t30: fix on-module 5v0 supplies Working on Gigabit/PCIe support in U-Boot for Apalis T30 I realised that the current device tree source includes for our modules only happen to work due to referencing the on-carrier 5v0 supply from USB which is not at all available on-module. The modules actually contain TPS60150 charge pumps to generate the PMIC required 5 volts from the one and only 3.3 volt module supply. This patch fixes this. (Note: When back-porting this to v3.16 stable releases, simply drop the change to tegra30-apalis.dtsi; that file was added in v3.17) Cc: <stable@vger.kernel.org> #v3.16+ Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net> 24 August 2014, 18:21:19 UTC
9d0b1f3 Merge tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes Merge "ARM: rockchip: fix for 3.17" from Heiko Stubner: Pinctrl that got accidentially dropped when reorganizing the dts files and addition of the new Rockchip list to MAINTAINERS. * tag 'v3.17-rockchip-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: MAINTAINERS: add new Rockchip SoC list ARM: dts: rockchip: readd missing mmc0 pinctrl settings Signed-off-by: Olof Johansson <olof@lixom.net> 24 August 2014, 18:19:58 UTC
9e0af23 Btrfs: fix task hang under heavy compressed write This has been reported and discussed for a long time, and this hang occurs in both 3.15 and 3.16. Btrfs now migrates to use kernel workqueue, but it introduces this hang problem. Btrfs has a kind of work queued as an ordered way, which means that its ordered_func() must be processed in the way of FIFO, so it usually looks like -- normal_work_helper(arg) work = container_of(arg, struct btrfs_work, normal_work); work->func() <---- (we name it work X) for ordered_work in wq->ordered_list ordered_work->ordered_func() ordered_work->ordered_free() The hang is a rare case, first when we find free space, we get an uncached block group, then we go to read its free space cache inode for free space information, so it will file a readahead request btrfs_readpages() for page that is not in page cache __do_readpage() submit_extent_page() btrfs_submit_bio_hook() btrfs_bio_wq_end_io() submit_bio() end_workqueue_bio() <--(ret by the 1st endio) queue a work(named work Y) for the 2nd also the real endio() So the hang occurs when work Y's work_struct and work X's work_struct happens to share the same address. A bit more explanation, A,B,C -- struct btrfs_work arg -- struct work_struct kthread: worker_thread() pick up a work_struct from @worklist process_one_work(arg) worker->current_work = arg; <-- arg is A->normal_work worker->current_func(arg) normal_work_helper(arg) A = container_of(arg, struct btrfs_work, normal_work); A->func() A->ordered_func() A->ordered_free() <-- A gets freed B->ordered_func() submit_compressed_extents() find_free_extent() load_free_space_inode() ... <-- (the above readhead stack) end_workqueue_bio() btrfs_queue_work(work C) B->ordered_free() As if work A has a high priority in wq->ordered_list and there are more ordered works queued after it, such as B->ordered_func(), its memory could have been freed before normal_work_helper() returns, which means that kernel workqueue code worker_thread() still has worker->current_work pointer to be work A->normal_work's, ie. arg's address. Meanwhile, work C is allocated after work A is freed, work C->normal_work and work A->normal_work are likely to share the same address(I confirmed this with ftrace output, so I'm not just guessing, it's rare though). When another kthread picks up work C->normal_work to process, and finds our kthread is processing it(see find_worker_executing_work()), it'll think work C as a collision and skip then, which ends up nobody processing work C. So the situation is that our kthread is waiting forever on work C. Besides, there're other cases that can lead to deadlock, but the real problem is that all btrfs workqueue shares one work->func, -- normal_work_helper, so this makes each workqueue to have its own helper function, but only a wraper pf normal_work_helper. With this patch, I no long hit the above hang. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Chris Mason <clm@fb.com> 24 August 2014, 14:17:02 UTC
a284e9d MAINTAINERS: Add entry for Renesas DRM drivers Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@gmail.com> 24 August 2014, 06:37:47 UTC
db314f2 Merge branch 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux into drm-next This pull just contains some new pci ids. * 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: add additional SI pci ids drm/radeon: add new bonaire pci ids drm/radeon: add new KV pci id 24 August 2014, 05:47:46 UTC
4631dbf ext4: move i_size,i_disksize update routines to helper function Cc: stable@vger.kernel.org # needed for bug fix patches Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: Theodore Ts'o <tytso@mit.edu> 23 August 2014, 21:48:28 UTC
c99d1e6 ext4: fix BUG_ON in mb_free_blocks() If we suffer a block allocation failure (for example due to a memory allocation failure), it's possible that we will call ext4_discard_allocated_blocks() before we've actually allocated any blocks. In that case, fe_len and fe_start in ac->ac_f_ex will still be zero, and this will result in mb_free_blocks(inode, e4b, 0, 0) triggering the BUG_ON on mb_free_blocks(): BUG_ON(last >= (sb->s_blocksize << 3)); Fix this by bailing out of ext4_discard_allocated_blocks() if fs_len is zero. Also fix a missing ext4_mb_unload_buddy() call in ext4_discard_allocated_blocks(). Google-Bug-Id: 16844242 Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org 23 August 2014, 21:47:28 UTC
36de928 ext4: propagate errors up to ext4_find_entry()'s callers If we run into some kind of error, such as ENOMEM, while calling ext4_getblk() or ext4_dx_find_entry(), we need to make sure this error gets propagated up to ext4_find_entry() and then to its callers. This way, transient errors such as ENOMEM can get propagated to the VFS. This is important so that the system calls return the appropriate error, and also so that in the case of ext4_lookup(), we return an error instead of a NULL inode, since that will result in a negative dentry cache entry that will stick around long past the OOM condition which caused a transient ENOMEM error. Google-Bug-Id: #17142205 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org 23 August 2014, 21:47:19 UTC
c3d3af5 Merge tag 'usb-serial-3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into work-linus Johan writes: USB-serial fixes for v3.17-rc2 These updates fix the log level for some option log messages that started bothering people after a recent change. They also fix some issues reported against the zte_ev driver by moving most device ids back from the zte_ev driver to the option driver (and removing two duplicate ids). The zte_ev driver is planned to be removed in 3.18. Some new device ids are also added. Signed-off-by: Johan Hovold <johan@kernel.org> 23 August 2014, 15:42:00 UTC
00250b5 MAINTAINERS: add new Rockchip SoC list Add the new list that Rockchip-specific patches should also be directed to. Signed-off-by: Heiko Stuebner <heiko@sntech.de> 23 August 2014, 11:22:05 UTC
1302d32 ARM: dts: rockchip: readd missing mmc0 pinctrl settings During the restructuring of the Rockchip Cortex-A9 dtsi files it seems like the pinctrl settings vanished at some point from the mmc0 support. This of course renders them unusable, so readd the necessary pinctrl properties. Signed-off-by: Heiko Stuebner <heiko@sntech.de> 23 August 2014, 11:21:45 UTC
2136edf Merge tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes Merge "Allwinner DT changes, take 2" from Maxime Ripard: Only a single patch in here that fixes a DTC warning. * tag 'sunxi-dt-for-3.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux: ARM: dt: sun6i: Add #address-cells and #size-cells to i2c controller nodes Signed-off-by: Olof Johansson <olof@lixom.net> 23 August 2014, 05:57:57 UTC
39b5552 ftrace: Use current addr when converting to nop in __ftrace_replace_code() In __ftrace_replace_code(), when converting the call to a nop in a function it needs to compare against the "curr" (current) value of the ftrace ops, and not the "new" one. It currently does not affect x86 which is the only arch to do the trampolines with function graph tracer, but when other archs that do depend on this code implement the function graph trampoline, it can crash. Here's an example when ARM uses the trampolines (in the future): ------------[ cut here ]------------ WARNING: CPU: 0 PID: 9 at kernel/trace/ftrace.c:1716 ftrace_bug+0x17c/0x1f4() Modules linked in: omap_rng rng_core ipv6 CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.16.0-test-10959-gf0094b28f303-dirty #52 [<c02188f4>] (unwind_backtrace) from [<c021343c>] (show_stack+0x20/0x24) [<c021343c>] (show_stack) from [<c095a674>] (dump_stack+0x78/0x94) [<c095a674>] (dump_stack) from [<c02532a0>] (warn_slowpath_common+0x7c/0x9c) [<c02532a0>] (warn_slowpath_common) from [<c02532ec>] (warn_slowpath_null+0x2c/0x34) [<c02532ec>] (warn_slowpath_null) from [<c02cbac4>] (ftrace_bug+0x17c/0x1f4) [<c02cbac4>] (ftrace_bug) from [<c02cc44c>] (ftrace_replace_code+0x80/0x9c) [<c02cc44c>] (ftrace_replace_code) from [<c02cc658>] (ftrace_modify_all_code+0xb8/0x164) [<c02cc658>] (ftrace_modify_all_code) from [<c02cc718>] (__ftrace_modify_code+0x14/0x1c) [<c02cc718>] (__ftrace_modify_code) from [<c02c7244>] (multi_cpu_stop+0xf4/0x134) [<c02c7244>] (multi_cpu_stop) from [<c02c6e90>] (cpu_stopper_thread+0x54/0x130) [<c02c6e90>] (cpu_stopper_thread) from [<c0271cd4>] (smpboot_thread_fn+0x1ac/0x1bc) [<c0271cd4>] (smpboot_thread_fn) from [<c026ddf0>] (kthread+0xe0/0xfc) [<c026ddf0>] (kthread) from [<c020f318>] (ret_from_fork+0x14/0x20) ---[ end trace dc9ce72c5b617d8f ]--- [ 65.047264] ftrace failed to modify [<c0208580>] asm_do_IRQ+0x10/0x1c [ 65.054070] actual: 85:1b:00:eb Fixes: 7413af1fb70e7 "ftrace: Make get_ftrace_addr() and get_ftrace_addr_old() global" Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 23 August 2014, 01:04:35 UTC
5f151b2 ftrace: Fix function_profiler and function tracer together The latest rewrite of ftrace removed the separate ftrace_ops of the function tracer and the function graph tracer and had them share the same ftrace_ops. This simplified the accounting by removing the multiple layers of functions called, where the global_ops func would call a special list that would iterate over the other ops that were registered within it (like function and function graph), which itself was registered to the ftrace ops list of all functions currently active. If that sounds confusing, the code that implemented it was also confusing and its removal is a good thing. The problem with this change was that it assumed that the function and function graph tracer can never be used at the same time. This is mostly true, but there is an exception. That is when the function profiler uses the function graph tracer to profile. The function profiler can be activated the same time as the function tracer, and this breaks the assumption and the result is that ftrace will crash (it detects the error and shuts itself down, it does not cause a kernel oops). To solve this issue, a previous change allowed the hash tables for the functions traced by a ftrace_ops to be a pointer and let multiple ftrace_ops share the same hash. This allows the function and function_graph tracer to have separate ftrace_ops, but still share the hash, which is what is done. Now the function and function graph tracers have separate ftrace_ops again, and the function tracer can be run while the function_profile is active. Cc: stable@vger.kernel.org # 3.16 (apply after 3.17-rc4 is out) Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 23 August 2014, 01:04:34 UTC
back to top