aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge tag 'hwmon-for-linus-v4.4' of ↵Linus Torvalds2015-11-02
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon updates from Guenter Roeck: "New driver for MAX31790, added support for TMP75C, as well as cleanups and minor improvements in various drivers" * tag 'hwmon-for-linus-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (fam15h_power) Add max compute unit accumulated power hwmon: (fam15h_power) Enable power1_input on AMD Carrizo hwmon: (fam15h_power) Refactor attributes for dynamically added hwmon: (ina2xx) remove no longer used variable 'kind' hwmon: (nct6775) Introduce separate temperature labels for NCT6792 and NCT6793 hwmon: (nct6775) NCT6791D and NCT6792D have an additional temperature source hwmon: (ina2xx) give precedence to DT over checking for platform data. hwmon: (ina2xx) convert driver to using regmap hwmon: (coretemp) Increase limit of maximum core ID from 32 to 128. hwmon: (lm75) Add support for TMP75C hwmon: (ibmpowernv) Add OF compatibility table entry hwmon: (abx500) drop the use of IRQF_NO_SUSPEND hwmon: (max31790) Fix dereference of ERR_PTR hwmon: Driver for Maxim MAX31790
| * hwmon: (fam15h_power) Add max compute unit accumulated powerHuang Rui2015-10-31
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds a member in fam15h_power_data which specifies the maximum accumulated power in a compute unit. Signed-off-by: Huang Rui <ray.huang@amd.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (fam15h_power) Enable power1_input on AMD CarrizoHuang Rui2015-10-31
| | | | | | | | | | | | | | | | | | | | | | This patch enables power1_input attribute for Carrizo platform. Signed-off-by: Huang Rui <ray.huang@amd.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (fam15h_power) Refactor attributes for dynamically addedHuang Rui2015-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | Attributes depend on the CPU model the driver gets loaded on. Therefore, add those attributes dynamically at init time. This is more flexible to control the different attributes on different platforms. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Huang Rui <ray.huang@amd.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (ina2xx) remove no longer used variable 'kind'Marc Titinger2015-10-31
| | | | | | | | | | Signed-off-by: Marc Titinger <mtitinger@baylibre.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (nct6775) Introduce separate temperature labels for NCT6792 and NCT6793Guenter Roeck2015-10-30
| | | | | | | | | | | | | | | | | | NCT6792 and NCT6793 are mostly register compatible to NCT6791, but temperature sources are different and difficult to manage with a single temperature label array. Introduce separate temperature label arrays for those chips to reflect the differences. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (nct6775) NCT6791D and NCT6792D have an additional temperature sourceGuenter Roeck2015-10-30
| | | | | | | | | | | | | | | | Both NCT6791D and NCT6792D permit selection of a 'virtual' temperature register as temperature source. The virtual temperature registers are registers 0xea to 0xef in bank 0 and can be written by software. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (ina2xx) give precedence to DT over checking for platform data.Marc Titinger2015-10-29
| | | | | | | | | | | | | | when checking for the value of the shunt resistor. Signed-off-by: Marc Titinger <mtitinger@baylibre.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (ina2xx) convert driver to using regmapMarc Titinger2015-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | Any sysfs "show" read access from the client app will result in reading all registers (8 with ina226). Depending on the host this can limit the best achievable read rate. This changeset allows for individual register accesses through regmap. Tested with BeagleBone Black (Baylibre-ACME) and ina226. Signed-off-by: Marc Titinger <mtitinger@baylibre.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (coretemp) Increase limit of maximum core ID from 32 to 128.Lukasz Odzioba2015-10-14
| | | | | | | | | | | | | | | | | | | | | | | | A new limit selected arbitrarily as power of two greater than required minimum for Xeon Phi processor (72 for Knights Landing). Currently driver is not able to handle cores with core ID greater than 32. Such attempt ends up with the following error in dmesg: coretemp coretemp.0: Adding Core XXX failed Signed-off-by: Lukasz Odzioba <lukasz.odzioba@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (lm75) Add support for TMP75CBen Gardner2015-10-14
| | | | | | | | | | | | | | | | | | The TMP75C has a different control register layout and only supports 12-bit temperature samples (0.0625 deg C). The continuous sample rate is ~12 Hz. Signed-off-by: Ben Gardner <gardner.ben@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (ibmpowernv) Add OF compatibility table entryCédric Le Goater2015-10-14
| | | | | | | | | | | | | | Fix module autoload for IBM and Open power platforms. Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (abx500) drop the use of IRQF_NO_SUSPENDSudeep Holla2015-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The description in the driver states: "ABX500 does not provide auto ADC, so to monitor the required temperatures, a periodic work is used. It is more important to not wake up the CPU... If the chip gets too hot during a sleep state it's most likely due to external factors, such as the surrounding temperature and nothing can be done in S/W." So it makes no sense to keep IRQs enabled as it need not be wakeup source. This patch removes the use of IRQF_NO_SUSPEND flag Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: (max31790) Fix dereference of ERR_PTRSudip Mukherjee2015-10-14
| | | | | | | | | | | | | | | | | | max31790_update_device() return the error code in ERR_PTR. We were checking if it has returned error or not but before checking we have dereferenced it. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * hwmon: Driver for Maxim MAX31790Il Han2015-10-14
| | | | | | | | | | | | | | The driver supports the Maxim MAX31790. Signed-off-by: Il Han <corone.il.han@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* | mm: get rid of 'vmalloc_info' from /proc/meminfoLinus Torvalds2015-11-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that at least some versions of glibc end up reading /proc/meminfo at every single startup, because glibc wants to know the amount of memory the machine has. And while that's arguably insane, it's just how things are. And it turns out that it's not all that expensive most of the time, but the vmalloc information statistics (amount of virtual memory used in the vmalloc space, and the biggest remaining chunk) can be rather expensive to compute. The 'get_vmalloc_info()' function actually showed up on my profiles as 4% of the CPU usage of "make test" in the git source repository, because the git tests are lots of very short-lived shell-scripts etc. It turns out that apparently this same silly vmalloc info gathering shows up on the facebook servers too, according to Dave Jones. So it's not just "make test" for git. We had two patches to just cache the information (one by me, one by Ingo) to mitigate this issue, but the whole vmalloc information of of rather dubious value to begin with, and people who *actually* want to know what the situation is wrt the vmalloc area should just look at the much more complete /proc/vmallocinfo instead. In fact, according to my testing - and perhaps more importantly, according to that big search engine in the sky: Google - there is nothing out there that actually cares about those two expensive fields: VmallocUsed and VmallocChunk. So let's try to just remove them entirely. Actually, this just removes the computation and reports the numbers as zero for now, just to try to be minimally intrusive. If this breaks anything, we'll obviously have to re-introduce the code to compute this all and add the caching patches on top. But if given the option, I'd really prefer to just remove this bad idea entirely rather than add even more code to work around our historical mistake that likely nobody really cares about. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'fs-file-descriptor-optimization'Linus Torvalds2015-11-01
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge file descriptor allocation speedup. Eric Dumazet has a test-case for a fairly common network deamon load pattern: openign and closing a lot of sockets that each have very little work done on them. It turns out that in that case, the cost of just finding the correct file descriptor number can be a dominating factor. We've long had a trivial optimization for allocating file descriptors sequentially, but that optimization ends up being not very effective when other file descriptors are being closed concurrently, and the fd patterns are not some simple FIFO pattern. In such cases we ended up spending a lot of time just scanning the bitmap of open file descriptors in order to find the next file descriptor number to open. This trivial patch-series mitigates that by simply introducing a second-level bitmap of which words in the first bitmap are already fully allocated. That cuts down the cost of scanning by an order of magnitude in some pathological (but realistic) cases. The second patch is an even more trivial patch to avoid unnecessarily dirtying the cacheline for the close-on-exec bit array that normally ends up being all empty. * fs-file-descriptor-optimization: vfs: conditionally clear close-on-exec flag vfs: Fix pathological performance case for __alloc_fd()
| * | vfs: conditionally clear close-on-exec flagLinus Torvalds2015-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We clear the close-on-exec flag when opening and closing files, and the bit was almost always already clear before. Avoid dirtying the cacheline if the clearning isn't necessary. That avoids unnecessary cacheline dirtying and bouncing in multi-socket environments. Eric Dumazet has a file descriptor benchmark that goes 4% faster from this on his two-socket machine. It's probably partly superlinear improvement due to getting slightly less spinlock contention on the file_lock spinlock due to less work in the critical section. Tested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | vfs: Fix pathological performance case for __alloc_fd()Linus Torvalds2015-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Al Viro points out that: > > * [Linux-specific aside] our __alloc_fd() can degrade quite badly > > with some use patterns. The cacheline pingpong in the bitmap is probably > > inevitable, unless we accept considerably heavier memory footprint, > > but we also have a case when alloc_fd() takes O(n) and it's _not_ hard > > to trigger - close(3);open(...); will have the next open() after that > > scanning the entire in-use bitmap. And Eric Dumazet has a somewhat realistic multithreaded microbenchmark that opens and closes a lot of sockets with minimal work per socket. This patch largely fixes it. We keep a 2nd-level bitmap of the open file bitmaps, showing which words are already full. So then we can traverse that second-level bitmap to efficiently skip already allocated file descriptors. On his benchmark, this improves performance by up to an order of magnitude, by avoiding the excessive open file bitmap scanning. Tested-and-acked-by: Eric Dumazet <edumazet@google.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Linux 4.3Linus Torvalds2015-11-01
| | |
* | | Merge branch 'libnvdimm-fixes' of ↵Linus Torvalds2015-11-01
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull memremap fix from Dan Williams: "The new memremap() api introduced in the 4.3 cycle to unify/replace ioremap_cache() and ioremap_wt() is mishandling the highmem case. This patch has received a build success notification from a 0day-kbuild-robot run and has received an ack from Ard" From the commit message: "The impact of this bug is low for now since the pmem driver is the only user of memremap(), but this is important to fix before more conversions to memremap arrive in 4.4" * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: memremap: fix highmem support
| * | | memremap: fix highmem supportDan Williams2015-10-26
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently memremap checks if the range is "System RAM" and returns the kernel linear address. This is broken for highmem platforms where a range may be "System RAM", but is not part of the kernel linear mapping. Fallback to ioremap_cache() in these cases, to let the arch code attempt to handle it. Note that ARM ioremap will WARN when attempting to remap ram, and in that case the caller needs to be fixed. For this reason, existing ioremap_cache() usages for ARM are already trained to avoid attempts to remap ram. The impact of this bug is low for now since the pmem driver is the only user of memremap(), but this is important to fix before more conversions to memremap arrive in 4.4. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
* | | Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2015-11-01
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "This set of updates contains: - Another bugfix for the pathologic vm86 machinery. Clear thread.vm86 on fork to prevent corrupting the parent state. This comes along with an update to the vm86 selftest case - Fix another corner case in the ioapic setup code which causes a boot crash on some oddball systems - Fix the fallout from the dma allocation consolidation work, which leads to a NULL pointer dereference when the allocation code is called with a NULL device" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/vm86: Set thread.vm86 to NULL on fork/clone selftests/x86: Add a fork() to entry_from_vm86 to catch fork bugs x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest() x86/dma-mapping: Fix arch_dma_alloc_attrs() oops with NULL dev
| * | | x86/vm86: Set thread.vm86 to NULL on fork/cloneAndy Lutomirski2015-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thread.vm86 points to per-task information -- the pointer should not be copied on clone. Fixes: d4ce0f26c790 ("x86/vm86: Move fields from 'struct kernel_vm86_struct' to 'struct vm86'") Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Brian Gerst <brgerst@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Stas Sergeev <stsp@list.ru> Link: http://lkml.kernel.org/r/71c5d6985d70ec8197c8d72f003823c81b7dcf99.1446270067.git.luto@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | | selftests/x86: Add a fork() to entry_from_vm86 to catch fork bugsAndy Lutomirski2015-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mere possession of vm86 state is strange. Make sure that nothing gets corrupted if we fork after calling vm86(). Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Brian Gerst <brgerst@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Stas Sergeev <stsp@list.ru> Link: http://lkml.kernel.org/r/08f83295460a80e41dc5e3e81ec40d6844d316f5.1446270067.git.luto@kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | | x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest()Werner Pawlitschko2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4857c91f0d19 changed the way how irq affinity is setup in setup_ioapic_dest() from using the core helper function to unconditionally calling the irq_set_affinity() callback of the underlying irq chip. That results in a NULL pointer dereference for the rare case where the underlying irq chip is lapic_chip which has no irq_set_affinity() callback. lapic_chip is occasionally used for the timer interrupt (irq 0). The fix is simple: Check the availability of the callback instead of calling it unconditionally. Fixes: 4857c91f0d19 "x86/ioapic: Force affinity setting in setup_ioapic_dest()" Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org
| * | | x86/dma-mapping: Fix arch_dma_alloc_attrs() oops with NULL devVille Syrjälä2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6894258eda2f broke drivers that pass NULL as the device pointer to dma_alloc. The reason is that arch_dma_alloc_attrs() now calls dma_alloc_coherent_gfp_flags() which in turn calls dma_alloc_coherent_mask(), where the device pointer is dereferenced unconditionally. Fix things by moving the ISA DMA fallback device assignment before the call to dma_alloc_coherent_gfp_flags(). Fixes: 6894258eda2f ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}") Reported-and-tested-by: Meelis Roos <mroos@linux.ee> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Christoph Hellwig <hch@lst.de> Link: http://lkml.kernel.org/r/1445807503-8920-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | | | Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2015-11-01
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Thomas Gleixner: "The last round of minimalistic fixes for clocksource drivers: - Prevent multiple shutdown of the sh_mtu2 clocksource - Annotate a bunch of clocksource/schedclock functions with notrace to prevent an annoying ftrace recursion issue" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource/drivers/sh_mtu2: Fix multiple shutdown call issue clocksource/drivers/digicolor: Prevent ftrace recursion clocksource/drivers/fsl_ftm_timer: Prevent ftrace recursion clocksource/drivers/vf_pit_timer: Prevent ftrace recursion clocksource/drivers/prima2: Prevent ftrace recursion clocksource/drivers/samsung_pwm_timer: Prevent ftrace recursion clocksource/drivers/pistachio: Prevent ftrace recursion clocksource/drivers/arm_global_timer: Prevent ftrace recursion
| * | | | clocksource/drivers/sh_mtu2: Fix multiple shutdown call issueMagnus Damm2015-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the r7s72100 Genmai board the MTU2 driver currently triggers a common clock framework WARN_ON(enable_count) when disabling the clock due to the MTU2 driver after recent callback rework may call ->set_state_shutdown() multiple times. A similar issue was spotted for the TMU driver and fixed in: 452b132 clocksource/drivers/sh_tmu: Fix traceback spotted in -next On r7s72100 Genmai v4.3-rc7 built with shmobile_defconfig spits out the following during boot: sh_mtu2 fcff0000.timer: ch0: used for clock events ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:675 clk_core_disable+0x2c/0x6c() CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.0-rc7 #1 Hardware name: Generic R7S72100 (Flattened Device Tree) Backtrace: [<c00133d4>] (dump_backtrace) from [<c0013570>] (show_stack+0x18/0x1c) [<c0013558>] (show_stack) from [<c01c7aac>] (dump_stack+0x74/0x90) [<c01c7a38>] (dump_stack) from [<c00272fc>] (warn_slowpath_common+0x88/0xb4) [<c0027274>] (warn_slowpath_common) from [<c0027400>] (warn_slowpath_null+0x24/0x2c) [<c00273dc>] (warn_slowpath_null) from [<c03a9320>] (clk_core_disable+0x2c/0x6c) [<c03a92f4>] (clk_core_disable) from [<c03aa0a0>] (clk_disable+0x40/0x4c) [<c03aa060>] (clk_disable) from [<c0395d2c>] (sh_mtu2_disable+0x24/0x50) [<c0395d08>] (sh_mtu2_disable) from [<c0395d6c>] (sh_mtu2_clock_event_shutdown+0x14/0x1c) [<c0395d58>] (sh_mtu2_clock_event_shutdown) from [<c007d7d0>] (clockevents_switch_state+0xc8/0x114) [<c007d708>] (clockevents_switch_state) from [<c007d834>] (clockevents_shutdown+0x18/0x28) [<c007d81c>] (clockevents_shutdown) from [<c007dd58>] (clockevents_exchange_device+0x70/0x78) [<c007dce8>] (clockevents_exchange_device) from [<c007e578>] (tick_check_new_device+0x88/0xe0) [<c007e4f0>] (tick_check_new_device) from [<c007daf0>] (clockevents_register_device+0xac/0x120) [<c007da44>] (clockevents_register_device) from [<c0395be8>] (sh_mtu2_probe+0x230/0x350) [<c03959b8>] (sh_mtu2_probe) from [<c028b6f0>] (platform_drv_probe+0x50/0x98) Reported-by: Chris Brandt <chris.brandt@renesas.com> Fixes: 19a9ffb ("clockevents/drivers/sh_mtu2: Migrate to new 'set-state' interface") Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
| * | | | clocksource/drivers/digicolor: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. We should not trace digicolor_timer_sched_read() function. Fix this by adding the notrace attribute to this function. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | | clocksource/drivers/fsl_ftm_timer: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. We should not trace the ftm_read_sched_clock() function. Fix this by adding the notrace attribute to this function. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | | clocksource/drivers/vf_pit_timer: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. We should not trace the pit_read_sched_clock() function. Fix this by adding a notrace attribute to this function. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | | clocksource/drivers/prima2: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently prima2 timer can be used as a scheduler clock. We properly marked sirfsoc_read_sched_clock() as notrace but we then call another function sirfsoc_timer_read() that _wasn't_ notrace. Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. Fix this by adding notrace attribute to the sirfsoc_timer_read() function. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | | clocksource/drivers/samsung_pwm_timer: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently samsung_pwm_timer can be used as a scheduler clock. We properly marked samsung_read_sched_clock() as notrace but we then call another function samsung_clocksource_read() that _wasn't_ notrace. Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. Fix this by adding notrace attribute to the samsung_clocksource_read() function. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | | clocksource/drivers/pistachio: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently pistachio can be used as a scheduler clock. We properly marked pistachio_read_sched_clock() as notrace but we then call another function pistachio_clocksource_read_cycles() that _wasn't_ notrace. Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. Fix this by adding notrace attribute to the pistachio_clocksource_read_cycles() function. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
| * | | | clocksource/drivers/arm_global_timer: Prevent ftrace recursionJisheng Zhang2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently arm_global_timer can be used as a scheduler clock. We properly marked gt_sched_clock_read() as notrace but we then call another function gt_counter_read() that _wasn't_ notrace. Having a traceable function in the sched_clock() path leads to a recursion within ftrace and a kernel crash. Fix this by adding an extra notrace function to keep other users of gt_counter_read() traceable. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
* | | | | Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds2015-11-01
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Thomas Gleixner: "The last two one-liners for 4.3 from the irqchip space: - Regression fix for armada SoC which addresses the fallout from the set_irq_flags() cleanup - Add the missing propagation of the irq_set_type() callback to the parent interrupt controller of the tegra interrupt chip" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/tegra: Propagate IRQ type setting to parent irqchip/armada-370-xp: Fix regression by clearing IRQ_NOAUTOEN
| * | | | | irqchip/tegra: Propagate IRQ type setting to parentLucas Stach2015-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LIC doesn't deal with the different types of interrupts itself but needs to forward calls to set the appropriate type to its parent IRQ controller. Without this fix all IRQs routed through the LIC will stay at the initial EDGE type, while most of them should actually be level triggered. Fixes: 1eec582158e2 "irqchip: tegra: Add Tegra210 support" Signed-off-by: Lucas Stach <dev@lynxeye.de> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: <stable@vger.kernel.org> # 4.1 Link: http://lkml.kernel.org/r/1445787552-13062-1-git-send-email-dev@lynxeye.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | | | | irqchip/armada-370-xp: Fix regression by clearing IRQ_NOAUTOENThomas Petazzoni2015-10-25
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d17cab4451df1 ("irqchip: Kill off set_irq_flags usage") changed the code of armada_370_xp_mpic_irq_map() from using set_irq_flags() to irq_set_probe(). While the commit log seems to imply that there are no functional changes, there are indeed functional changes introduced by this commit: the IRQ_NOAUTOEN flag is no longer cleared. This functional change causes a regression on Armada XP, which no longer works properly after suspend/resume because per-CPU interrupts remain disabled. Due to how the hardware registers work, the irq-armada-370-xp cannot simply save/restore a bunch of registers at suspend/resume to make sure that the interrupts remain in the same state after resuming. Therefore, it relies on the kernel to say whether the interrupt is disabled or not, using the irqd_irq_disabled() function. This was all working fine while the IRQ_NOAUTOEN flag was cleared. With the change introduced by Rob Herring in d17cab4451df1, the IRQ_NOAUTOEN flag is now set for all interrupts. irqd_irq_disabled() returns false for per-CPU interrupts, and therefore our per-CPU interrupts are no longer re-enabled after resume. This commit works around this problem by clearing again the IRQ_NOAUTOEN flags, so that we are back to the situation we had before commit d17cab4451df1. This work around is proposed as a minimal fix for the problem, while a better long-term solution is being worked on. Fixes: d17cab4451df1 "irqchip: Kill off set_irq_flags usage" Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1445435295-19956-1-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* | | | | Merge tag 'armsoc-fixes' of ↵Linus Torvalds2015-11-01
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "This should be our final batch of fixes for 4.3: - A patch from Sudeep Holla that fixes annotation of wakeup sources properly, old unused format seems to have spread through copying. - Two patches from Tony for OMAP. One dealing with MUSB setup problems due to runtime PM being enabled too early on the parent device. The other fixes IRQ numbering for OMAP1" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: usb: musb: omap2430: Fix regression caused by driver core change ARM: OMAP1: fix incorrect INT_DMA_LCD ARM: dts: fix gpio-keys wakeup-source property
| * \ \ \ \ Merge tag 'omap-for-v4.3/fixes-rc7' of ↵Olof Johansson2015-10-30
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Two omap regression fixes: - Fix omap3 MUSB with DMA caused by driver core changes - Fix LCD DMA interrupt number for omap1 that did not get changed for sparse IRQ changes * tag 'omap-for-v4.3/fixes-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: usb: musb: omap2430: Fix regression caused by driver core change ARM: OMAP1: fix incorrect INT_DMA_LCD Signed-off-by: Olof Johansson <olof@lixom.net>
| | * | | | | usb: musb: omap2430: Fix regression caused by driver core changeTony Lindgren2015-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe") started automatically ensuring the parent device is enabled when the child gets probed. This however caused a regression for MUSB omap2430 interface as the runtime PM for the parent device needs the child initialized to access the MUSB hardware registers. Let's delay the enabling of PM runtime for the parent until the child has been properly initialized as suggested in an earlier patch by Grygorii Strashko <grygorii.strashko@ti.com>. In addition to delaying pm_runtime_enable, we now also need to make sure the parent is enabled during omap2430_musb_init. We also want to propagate an error from omap2430_runtime_resume if struct musb is not initialized. Note that we use pm_runtime_put_noidle here for both the child and parent to prevent an extra runtime_suspend/resume cycle. Let's also add some comments to avoid confusion between the two different devices. Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe") Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | | | | ARM: OMAP1: fix incorrect INT_DMA_LCDAaro Koskinen2015-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 685e2d08c54b ("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. Cc: stable@vger.kernel.org # v4.2+ Fixes: 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for sparse IRQ") Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | | | | | ARM: dts: fix gpio-keys wakeup-source propertySudeep Holla2015-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The keyboard driver for GPIO buttons(gpio-keys) checks for one of the two boolean properties to enable gpio buttons as wakeup source: 1. "wakeup-source" or 2. the legacy "gpio-key,wakeup" However juno, ste-snowball and emev2-kzm9d dts file have a undetected "wakeup" property to indictate the wakeup source. This patch fixes it by making use of "wakeup-source" property. Cc: Magnus Damm <magnus.damm@gmail.com> Acked-by: Simon Horman <horms@verge.net.au> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
* | | | | | | Merge tag 'scsi-fixes' of ↵Linus Torvalds2015-11-01
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is three essential bug fixes for various SCSI parts. The only affected users are SCSI multi-path via device handler (basically all the enterprise) and mvsas users. The dh bugs are an async entanglement in boot resulting in a serious WARN_ON trip and a use after free on remove leading to a crash with strict memory accounting. The mvsas bug manifests as a null deref oops but only on abort sequences; however, these can commonly occur with SATA attached devices, hence the fix" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi_dh: don't try to load a device handler during async probing scsi_dh: fix use-after-free when removing scsi device mvsas: Fix NULL pointer dereference in mvs_slot_task_free
| * | | | | | | scsi_dh: don't try to load a device handler during async probingChristoph Hellwig2015-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Request_module gets really unhappy when called from async probing, so revert to not auto load device handler modules during the SCSI bus scan. While autoloading would be really useful we never did this until 4.3-rc and it turns out that functionality doesn't actually work. Fixes: 566079 ("dm-mpath, scsi_dh: request scsi_dh modules in scsi_dh, not dm-mpath") Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Paul Mackerras <paulus@ozlabs.org> Tested-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: James Bottomley <JBottomley@Odin.com>
| * | | | | | | scsi_dh: fix use-after-free when removing scsi deviceJunichi Nomura2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit 1bab0de0274f ("dm-mpath, scsi_dh: don't let dm detach device handlers") removed reference counting of attached scsi device handler. As a result, handler data is freed immediately via scsi_dh->detach() in the context of scsi_remove_device() where activation request can be still in flight. This patch moves scsi_dh_handler_detach() to sdev releasing function, scsi_device_dev_release_usercontext(), at that point the device is already in quiesced state. Fixes: 1bab0de0274f ("dm-mpath, scsi_dh: don't let dm detach device handlers") Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Acked-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <JBottomley@Odin.com>
| * | | | | | | mvsas: Fix NULL pointer dereference in mvs_slot_task_freeDāvis Mosāns2015-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays NULL but it's later used in mvs_abort_task as slot which is passed to mvs_slot_task_free causing NULL pointer dereference. Just return from mvs_slot_task_free when passed with NULL slot. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891 Signed-off-by: Dāvis Mosāns <davispuh@gmail.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Cc: stable@vger.kernel.org Signed-off-by: James Bottomley <JBottomley@Odin.com>
* | | | | | | | Merge tag 'md/4.3-rc7-fixes' of git://neil.brown.name/mdLinus Torvalds2015-11-01
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull md bug fixes from Neil Brown: "Two more bug fixes for md. One bugfix for a list corruption in raid5 because of incorrect locking. Other for possible data corruption when a recovering device is failed, removed, and re-added. Both tagged for -stable" * tag 'md/4.3-rc7-fixes' of git://neil.brown.name/md: Revert "md: allow a partially recovered device to be hot-added to an array." md/raid5: fix locking in handle_stripe_clean_event()
| * | | | | | | | Revert "md: allow a partially recovered device to be hot-added to an array."NeilBrown2015-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57. This commit is poorly justified, I can find not discusison in email, and it clearly causes a problem. If a device which is being recovered fails and is subsequently re-added to an array, there could easily have been changes to the array *before* the point where the recovery was up to. So the recovery must start again from the beginning. If a spare is being recovered and fails, then when it is re-added we really should do a bitmap-based recovery up to the recovery-offset, and then a full recovery from there. Before this reversion, we only did the "full recovery from there" which is not corect. After this reversion with will do a full recovery from the start, which is safer but not ideal. It will be left to a future patch to arrange the two different styles of recovery. Reported-and-tested-by: Nate Dailey <nate.dailey@stratus.com> Signed-off-by: NeilBrown <neilb@suse.com> Cc: stable@vger.kernel.org (3.14+) Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.")
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-22 10:15:58 -0400