- 10 Nov, 2018 40 commits
-
-
Junichi Nomura authored
[ Upstream commit 2a708cff ] __dm_destroy() takes io_barrier SRCU lock (dm_get_live_table) and suspend_lock in reverse order. Doing so can cause AB-BA deadlock: __dm_destroy dm_swap_table --------------------------------------------------- mutex_lock(suspend_lock) dm_get_live_table() srcu_read_lock(io_barrier) dm_sync_table() synchronize_srcu(io_barrier) .. waiting for dm_put_live_table() mutex_lock(suspend_lock) .. waiting for suspend_lock Fix this by taking the locks in proper order. Signed-off-by:
Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Fixes: ab7c7bb6 ("dm: hold suspend_lock while suspending device during device deletion") Acked-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Uwe Kleine-König authored
[ Upstream commit 9911a2d5 ] The code in pinctrl-imx.c only works correctly if in the imx_pinctrl_soc_info passed to imx_pinctrl_probe we have: info->pins[i].number = i conf_reg(info->pins[i]) = 4 * i (which conf_reg(pin) being the offset of the pin's configuration register). When the imx25 specific part was introduced in b4a87c9b ("pinctrl: pinctrl-imx: add imx25 pinctrl driver") we had: info->pins[i].number = i + 1 conf_reg(info->pins[i]) = 4 * i . Commit 34027ca2 ("pinctrl: imx25: fix numbering for pins") tried to fix that but made the situation: info->pins[i-1].number = i conf_reg(info->pins[i-1]) = 4 * i which is hardly better but fixed the error seen back then. So insert another reserved entry in the array to finally yield: info->pins[i].number = i conf_reg(info->pins[i]) = 4 * i Fixes: 34027ca2 ("pinctrl: imx25: fix numbering for pins") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Filipe Manana authored
[ Upstream commit b659ef02 ] Commit 3a8b36f3 ("Btrfs: fix data loss in the fast fsync path") added a performance regression for that causes an unnecessary sync of the log trees (fs/subvol and root log trees) when 2 consecutive fsyncs are done against a file, without no writes or any metadata updates to the inode in between them and if a transaction is committed before the second fsync is called. Huang Ying reported this to lkml (https://lkml.org/lkml/2015/3/18/99) after a test sysbench test that measured a -62% decrease of file io requests per second for that tests' workload. The test is: echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor mkfs -t btrfs /dev/sda2 mount -t btrfs /dev/sda2 /fs/sda2 cd /fs/sda2 for ((i = 0; i < 1024; i++)); do fallocate -l 67108864 testfile.$i; done sysbench --test=fileio --max-requests=0 --num-threads=4 --max-time=600 \ --file-test-mode=rndwr --file-total-size=68719476736 --file-io-mode=sync \ --file-num=1024 run A test on kvm guest, running a debug kernel gave me the following results: Without 3a8b36f3: 16.01 reqs/sec With 3a8b36f3: 3.39 reqs/sec With 3a8b36f3 and this patch: 16.04 reqs/sec Reported-by:
Huang Ying <ying.huang@intel.com> Tested-by:
Huang, Ying <ying.huang@intel.com> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lorenzo Pieralisi authored
[ Upstream commit feb28979 ] Commit d2be00c0 ("of/pci: Free resources on failure in of_pci_get_host_bridge_resources()") fixed the error path so it frees everything on the "resources" list. That list includes the bus_range, so we should not free it again. Remove the superfluous free of bus_range. [bhelgaas: changelog] Fixes: d2be00c0 ("of/pci: Free resources on failure in of_pci_get_host_bridge_resources()") Reported-by:
Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Joerg Roedel authored
[ Upstream commit d97eb896 ] When an interrupt is migrated away from a cpu it will stay in its vector_irq array until smp_irq_move_cleanup_interrupt succeeded. The cfg->move_in_progress flag is cleared already when the IPI was sent. When the interrupt is destroyed after migration its 'struct irq_desc' is freed and the vector_irq arrays are cleaned up. But since cfg->move_in_progress is already 0 the references at cpus before the last migration will not be cleared. So this would leave a reference to an already destroyed irq alive. When the cpu is taken down at this point, the check_irq_vectors_for_cpu_disable() function finds a valid irq number in the vector_irq array, but gets NULL for its descriptor and dereferences it, causing a kernel panic. This has been observed on real systems at shutdown. Add a check to check_irq_vectors_for_cpu_disable() for a valid 'struct irq_desc' to prevent this issue. Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Jiang Liu <jiang.liu@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Yinghai Lu <yinghai@kernel.org> Cc: alnovak@suse.com Cc: joro@8bytes.org Link: http://lkml.kernel.org/r/20150204132754.GA10078@suse.de Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Paul E. McKenney authored
[ Upstream commit c0135d07 ] If the scheduling-clock interrupt sets the current tasks need_qs flag, but if the current CPU passes through a quiescent state in the meantime, then rcu_preempt_qs() will fail to clear the need_qs flag, which can fool RCU into thinking that additional rcu_read_unlock_special() processing is needed. This commit therefore clears the need_qs flag before checking for additional processing. For this problem to occur, we need rcu_preempt_data.passed_quiesce equal to true and current->rcu_read_unlock_special.b.need_qs also equal to true. This condition can occur as follows: 1. CPU 0 is aware of the current preemptible RCU grace period, but has not yet passed through a quiescent state. Among other things, this means that rcu_preempt_data.passed_quiesce is false. 2. Task A running on CPU 0 enters a preemptible RCU read-side critical section. 3. CPU 0 takes a scheduling-clock interrupt, which notices the RCU read-side critical section and the need for a quiescent state, and thus sets current->rcu_read_unlock_special.b.need_qs to true. 4. Task A is preempted, enters the scheduler, eventually invoking rcu_preempt_note_context_switch() which in turn invokes rcu_preempt_qs(). Because rcu_preempt_data.passed_quiesce is false, control enters the body of the "if" statement, which sets rcu_preempt_data.passed_quiesce to true. 5. At this point, CPU 0 takes an interrupt. The interrupt handler contains an RCU read-side critical section, and the rcu_read_unlock() notes that current->rcu_read_unlock_special is nonzero, and thus invokes rcu_read_unlock_special(). 6. Once in rcu_read_unlock_special(), the fact that current->rcu_read_unlock_special.b.need_qs is true becomes apparent, so rcu_read_unlock_special() invokes rcu_preempt_qs(). Recursively, given that we interrupted out of that same function in the preceding step. 7. Because rcu_preempt_data.passed_quiesce is now true, rcu_preempt_qs() does nothing, and simply returns. 8. Upon return to rcu_read_unlock_special(), it is noted that current->rcu_read_unlock_special is still nonzero (because the interrupted rcu_preempt_qs() had not yet gotten around to clearing current->rcu_read_unlock_special.b.need_qs). 9. Execution proceeds to the WARN_ON_ONCE(), which notes that we are in an interrupt handler and thus duly splats. The solution, as noted above, is to make rcu_read_unlock_special() clear out current->rcu_read_unlock_special.b.need_qs after calling rcu_preempt_qs(). The interrupted rcu_preempt_qs() will clear it again, but this is harmless. The worst that happens is that we clobber another attempt to set this field, but this is not a problem because we just got done reporting a quiescent state. Reported-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> [ paulmck: Fix embarrassing build bug noted by Sasha Levin. ] Tested-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jeff Layton authored
[ Upstream commit 5d05e54a ] Chuck pointed out a problem that crept in with commit 6ffa30d3 (nfs: don't call blocking operations while !TASK_RUNNING). Linux counts tasks in uninterruptible sleep against the load average, so this caused the system's load average to be pinned at at least 1 when there was a NFSv4.1+ mount active. Not a huge problem, but it's probably worth fixing before we get too many complaints about it. This patch converts the code back to use TASK_INTERRUPTIBLE sleep, simply has it flush any signals on each loop iteration. In practice no one should really be signalling this thread at all, so I think this is reasonably safe. With this change, there's also no need to game the hung task watchdog so we can also convert the schedule_timeout call back to a normal schedule. Cc: <stable@vger.kernel.org> Reported-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> Tested-by:
Chuck Lever <chuck.lever@oracle.com> Fixes: commit 6ffa30d3 (“nfs: don't call blocking . . .”) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Daniel Borkmann authored
[ Upstream commit 025331df ] When allocating rtnl dump messages, struct ifla_port_vsi is never dumped, so we can save header plus payload in rtnl_port_size(). Infact, attribute IFLA_PORT_VSI_TYPE and struct ifla_port_vsi are not used anywhere in the kernel. We only need to keep the nla policy should applications in user space be filling this out. Same NLA_BINARY issue exists as was fixed in 364d5716 ("rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY") and others, but then again IFLA_PORT_VSI_TYPE is not used anywhere, so just add a comment that it's unused. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 7e08da50 ] Currently quota format that supports 64-bit usage sets maximum quota limit as 2^64-1. However quota core code uses signed numbers to track usage and even limits themselves are stored in long long. Checking of maximum allowable limits worked by luck until commit 14bf61ff (quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space units) because variable we compared with was unsigned. After that commit the type we compared against changed to signed and thus checks for maximum limits with the newest VFS quota format started to refuse any non-negative value. Later the problem was inadvertedly fixed by commit b10a0819 (quota: Store maximum space limit in bytes) because we started to compare against unsigned type as well. Fix possible future problems of this kind by setting maximum limits to 2^63-1 to avoid overflow issues. Reported-by:
Carlos Carvalho <carlos@fisica.ufpr.br> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Heiko Stübner authored
[ Upstream commit a5e1baf7 ] Lockdep reported a possible deadlock between the cpuclk lock and for example the i2c driver. CPU0 CPU1 ---- ---- lock(clk_lock); local_irq_disable(); lock(&(&i2c->lock)->rlock); lock(clk_lock); <Interrupt> lock(&(&i2c->lock)->rlock); *** DEADLOCK *** The generic clock-types of the core ccf already use spin_lock_irqsave when touching clock registers, so do the same for the cpuclk. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Michael Turquette <mturquette@linaro.org> [mturquette@linaro.org: removed initialization of "flags"] Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Abhilash Kesavan authored
[ Upstream commit 25217fef ] The arndale-octa board was giving "imprecise external aborts" during boot-up with MCPM enabled. CCI enablement of the boot cluster was found to be the cause of these aborts (possibly because the secure f/w was not allowing it). Hence, disable CCI for the arndale-octa board. Signed-off-by:
Abhilash Kesavan <a.kesavan@samsung.com> Tested-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by:
Kevin Hilman <khilman@linaro.org> Tested-by:
Tyler Baker <tyler.baker@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Abhilash Kesavan authored
[ Upstream commit 896ddd60 ] The arm-cci driver completes the probe sequence even if the cci node is marked as disabled. Add a check in the driver to honour the cci status in the device tree. Signed-off-by:
Abhilash Kesavan <a.kesavan@samsung.com> Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Tested-by:
Sudeep Holla <sudeep.holla@arm.com> Tested-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Namhyung Kim authored
[ Upstream commit 813ccd15 ] Currently the symbol structure is allocated with symbol_conf.priv_size to carry sideband information like annotation, map browser on TUI and sort-by-name tree node. So retrieving these information from symbol needs to care about the details of such placement. However the annotation code just assumes that the symbol is placed after the struct annotation. But actually there's other info between them. So accessing those struct will lead to an undefined behavior (usually a crash) after they write their info to the same location. To reproduce the problem, please follow the steps below: 1. run perf report (TUI of course) with -v option 2. open map browser (by pressing right arrow key for any entry) 3. search any function (by pressing '/' key and input whatever..) 4. return to the hist browser (by pressing 'q' or left arrow key) 5. open annotation window for the same entry (by pressing 'a' key) Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1421234288-22758-1-git-send-email-namhyung@kernel.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vineet Gupta authored
[ Upstream commit ea1fe3a8 ] This is due to duplicated unistd inclusion (via uClibc headers + kernel headers) Also seen on ARM uClibc based tools ------- ARC build ---------->8------------- CC util/evlist.o In file included from ~/arc/k.org/arch/arc/include/uapi/asm/unistd.h:25:0, from util/../perf-sys.h:10, from util/../perf.h:15, from util/event.h:7, from util/event.c:3: ~/arc/k.org/include/uapi/asm-generic/unistd.h:906:0: warning: "__NR_fcntl64" redefined [enabled by default] #define __NR_fcntl64 __NR3264_fcntl ^ In file included from ~/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/sys/syscall.h:24:0, from util/../perf-sys.h:6, ----------------->8------------------- ------- ARM build ---------->8------------- CC FPIC plugin_scsi.o In file included from util/../perf-sys.h:9:0, from util/../perf.h:15, from util/cache.h:7, from perf.c:12: ~/arc/k.org/arch/arm/include/uapi/asm/unistd.h:28:0: warning: "__NR_restart_syscall" redefined [enabled by default] In file included from ~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/syscall.h:25:0, from util/../perf-sys.h:6, from util/../perf.h:15, from util/cache.h:7, from perf.c:12: ~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/sysnum.h:17:0: note: this is the location of the previous definition ----------------->8------------------- Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421156604-30603-4-git-send-email-vgupta@synopsys.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Alexey Brodkin authored
[ Upstream commit db1806ed ] ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers statfs defines f_type to be U32 which causes perf build breakage http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h ----------->8--------------- CC fs/fs.o fs/fs.c: In function 'fs__valid_mount': fs/fs.c:82:24: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] else if (st_fs.f_type != magic) ^ cc1: all warnings being treated as errors ----------->8--------------- Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: Cody P Schafer <dev@codyps.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com> Link: http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgupta@synopsys.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Namhyung Kim authored
[ Upstream commit 260d819e ] When thread__init_map_groups() fails, a new thread should be removed from the rbtree since it's gonna be freed. Also update last match cache only if the function succeeded. Reported-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhyung@kernel.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kan Liang authored
[ Upstream commit 33636732 ] cycles:p and cycles:pp do not work on SLM since commit: 86a04461 ("perf/x86: Revamp PEBS event selection") UOPS_RETIRED.ALL is not a PEBS capable event, so it should not be used to count cycle number. Actually SLM calls intel_pebs_aliases_core2() which uses INST_RETIRED.ANY_P to count the number of cycles. It's a PEBS capable event. But inv and cmask must be set to count cycles. Considering SLM allows all events as PEBS with no flags, only INST_RETIRED.ANY_P, inv=1, cmask=16 needs to handled specially. Signed-off-by:
Kan Liang <kan.liang@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421084541-31639-1-git-send-email-kan.liang@intel.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Stephane Eranian authored
[ Upstream commit 433678bd ] This patch fixes a problem with the initialization of the sysfs_show() routine for the RAPL PMU. The current code was wrongly relying on the EVENT_ATTR_STR() macro which uses the events_sysfs_show() function in the x86 PMU code. That function itself was relying on the x86_pmu data structure. Yet RAPL and the core PMU (x86_pmu) have nothing to do with each other. They should therefore not interact with each other. The x86_pmu structure is initialized at boot time based on the host CPU model. When the host CPU is not supported, the x86_pmu remains uninitialized and some of the callbacks it contains are NULL. The false dependency with x86_pmu could potentially cause crashes in case the x86_pmu is not initialized while the RAPL PMU is. This may, for instance, be the case in virtualized environments. This patch fixes the problem by using a private sysfs_show() routine for exporting the RAPL PMU events. Signed-off-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/20150113225953.GA21525@thinkpad Cc: vincent.weaver@maine.edu Cc: jolsa@redhat.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Steven Rostedt (Red Hat) authored
[ Upstream commit ce1039bd ] Commit 5f893b26 "tracing: Move enabling tracepoints to just after rcu_init()" broke the enabling of system call events from the command line. The reason was that the enabling of command line trace events was moved before PID 1 started, and the syscall tracepoints require that all tasks have the TIF_SYSCALL_TRACEPOINT flag set. But the swapper task (pid 0) is not part of that. Since the swapper task is the only task that is running at this early in boot, no task gets the flag set, and the tracepoint never gets reached. Instead of setting the swapper task flag (there should be no reason to do that), re-enabled trace events again after the init thread (PID 1) has been started. It requires disabling all command line events and re-enabling them, as just enabling them again will not reset the logic to set the TIF_SYSCALL_TRACEPOINT flag, as the syscall tracepoint will be fooled into thinking that it was already set, and wont try setting it again. For this reason, we must first disable it and re-enable it. Link: http://lkml.kernel.org/r/1421188517-18312-1-git-send-email-mpe@ellerman.id.au Link: http://lkml.kernel.org/r/20150115040506.216066449@goodmis.org Reported-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Colin Ian King authored
[ Upstream commit ef6899cd ] static code analysis from cppcheck reports: [drivers/video/fbdev/broadsheetfb.c:673]: (error) Memory leak: sector_buffer sector_buffer is not being kfree'd on each call to broadsheet_spiflash_rewrite_sector(), so free it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Wenyou Yang authored
[ Upstream commit b8659752 ] Appearance: On some SAMA5D4EK boards, after power up, the Eth1 doesn't work. Reason: The PIOE2 pin is connected to the NAND_Tree# of KSZ8081, But it outputs LOW during the reset period, which cause the NAND_Tree# enabled. Add phy_fixup() to disable NAND_Tree by overriding the Operation Mode Strap Override register(i.e. Register 16h) to clear the NAND_Tree bit. Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Alexander Stein authored
[ Upstream commit 55eb9c34 ] atmel_lcdfb needs also uses hclk clock, but AT91SAM9263 doesn't have that specific clock, so use lcd_clk twice. The same was done in arch/arm/mach-at91/at91sam9263.c Signed-off-by:
Alexander Stein <alexanders83@web.de> Acked-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Bo Shen authored
[ Upstream commit 04582fd0 ] The MICBIAS is a supply, should route to MIC while not IN1L. Signed-off-by:
Bo Shen <voice.shen@atmel.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Bo Shen authored
[ Upstream commit 0068b2e1 ] The second property of reg is the length, so correct it for timer. Signed-off-by:
Bo Shen <voice.shen@atmel.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Johannes Thumshirn authored
[ Upstream commit 7b7c5491 ] Currently it is not possible to have a kernel with built-in MCB attached devices. This results out of the fact that mcb-pci requests PCI BAR 0, then parses the chameleon table and calls the driver's probe function before releasing BAR 0 again. When building the kernel with modules this is not a problem (and therefore it wasn't detected by my tests yet). A solution is to only remap the 1st 0x200 bytes of a Chameleon PCI device. 0x200 bytes is the maximum size of a Chameleon v2 Table. Also this patch stops disabling the PCI device on successful registration of MCB devices. Signed-off-by:
Johannes Thumshirn <johannes.thumshirn@men.de> Suggested-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chanwoo Choi authored
[ Upstream commit 31ec77ac ] This patch adds new s3c24xx_serial_drv_data structure for Exynos5433 SoC because Exynos5433 has different fifo size from existing Exynos4 SoC. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.cz> Cc: linux-serial@vger.kernel.org Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Acked-by:
Inki Dae <inki.dae@samsung.com> Acked-by:
Geunsik Lim <geunsik.lim@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Peter Hurley authored
[ Upstream commit 2ce3c10c ] This reverts commit c4dc3046. This fix is superseded by commit 52bce7f8 , 'pty, n_tty: Simplify input processing on final close'. The final close now waits for input processing to complete before destroying the pty, so poll() does not need to special case this condition. Cc: Francesco Ruggeri <fruggeri@arista.com> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vince Hsu authored
[ Upstream commit f56e67f0 ] The commit 1290a958 ("usb: phy: propagate __of_usb_find_phy()'s error on failure") changed the condition to return -EPROBE_DEFER to host driver. Originally the Tegra host driver depended on the returned -EPROBE_DEFER to get the phy device later when booting. Now we have to do that explicitly. Signed-off-by:
Vince Hsu <vinceh@nvidia.com> Tested-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Darrick J. Wong authored
[ Upstream commit 36d1ffdb ] The Apricorn SATA dongle will occasionally return "USBSUSBSUSB" in response to SCSI commands when running in UAS mode. Therefore, disable UAS mode on this dongle. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Alan Stern authored
[ Upstream commit c401e7b4 ] The USB stack uses error code -ENOSPC to indicate that the periodic schedule is too full, with insufficient bandwidth to accommodate a new allocation. It uses -EFBIG to indicate that an isochronous transfer could not be linked into the schedule because it would exceed the number of isochronous packets the host controller driver can handle (generally because the new transfer would extend too far into the future). ehci-hcd uses the wrong error code at one point. This patch fixes it, along with a misleading comment and debugging message. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christoph Hellwig authored
[ Upstream commit 70a0f2c1 ] The blk-mq ->queue_rq method is always called from process context, but might have preemption disabled. This means we still always have to use GFP_ATOMIC for memory allocations, and thus need to revert part of commit 3c356bde ("scsi: stop passing a gfp_mask argument down the command setup path"). Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Sasha Levin <sasha.levin@oracle.com> Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Tested-by:
Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vivek Gautam authored
[ Upstream commit e93e5454 ] DP PHY now require pmu-system-controller to handle PMU register to control PHY's power isolation. Adding the same to dp-phy node. Signed-off-by:
Vivek Gautam <gautam.vivek@samsung.com> Reviewed-by:
Jingoo Han <jg1.han@samsung.com> Tested-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by:
Kukjin Kim <kgene@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Trond Myklebust authored
[ Upstream commit 4e379d36 ] Remove an incorrect check for NFS_DELEGATION_NEED_RECLAIM in can_open_delegated(). We are allowed to cache opens even in a situation where we're doing reboot recovery. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chuck Lever authored
[ Upstream commit 7a01edf0 ] Detect server trunking across transport protocols. Otherwise, an RDMA mount and a TCP mount of the same server will end up with separate nfs_clients using the same clientid4. Reported-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Trond Myklebust authored
[ Upstream commit 55b9df93 ] While we normally expect the NFSv4 client to always send the same client owner to all servers, there are a couple of situations where that is not the case: 1) In NFSv4.0, switching between use of '-omigration' and not will cause the kernel to switch between using the non-uniform and uniform client strings. 2) In NFSv4.1, or NFSv4.0 when using uniform client strings, if the uniquifier string is suddenly changed. This patch will catch those situations by checking the client owner id in the trunking detection code, and will do the right thing if it notices that the strings differ. Cc: Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Trond Myklebust authored
[ Upstream commit ceb3a16c ] Ensure that we cache the NFSv4/v4.1 client owner_id so that we can verify it when we're doing trunking detection. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lennart Sorensen authored
[ Upstream commit afc9d590 ] Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external crystal is not enabled at power up. Instead the CPU falls back to using an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually 20MHz on boards so far (which gives an emulated frequency of 32.786KHz), but can also be 19.2 or 27MHz which result in much larger drift. Since this is used to drive the master counter at 32.768KHz * 375 / 2 = 6.144MHz, the emulated speed for 20MHz is of by 570ppm, or about 43 seconds per day, and more than the 500ppm NTP is able to tolerate. Checking the CTRL_CORE_BOOTSTRAP register can determine if the CPU is using the real 32.768KHz crystal or the emulated SYSCLK1/610, and by known that the real counter frequency can be determined and used. The real speed is then SYSCLK1 / 610 * 375 / 2 or SYSCLK1 * 75 / 244. Signed-off-by:
Len Sorensen <lsorense@csclub.uwaterloo.ca> Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabien Proriol authored
[ Upstream commit 65de7654 ] When xilinx-xadc is used with hwmon driver to read voltage, offset used for temperature is always applied whatever the channel. iio_channel_read must return an error to avoid offset for channel without IIO_CHAN_INFO_OFFSET property. Signed-off-by:
Fabien Proriol <fabien.proriol@jdsu.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vignesh R authored
[ Upstream commit 0bc09f9c ] Prior to DRA74x silicon rev 1.1, pcie_pcs register bits 8-15 and bits 16-23 were used to configure RC delay count for phy1 and phy2 respectively. phyid was used as index to distinguish the phys and to configure the delay values appropriately. As of DRA74x silicon rev 1.1, pcie_pcs register definition has changed. Bits 16-23 are used to configure delay values for *both* phy1 and phy2. Hence phyid is no longer required. So, drop id field from ti_pipe3 structure and its subsequent references for configuring pcie_pcs register. Also, pcie_pcs register now needs to be configured with delay value of 0x96 at bit positions 16-23. See register description of CTRL_CORE_PCIE_PCS in ARM572x TRM, SPRUHZ6, October 2014, section 18.5.2.2, table 18-1804. This is needed to ensure Gen2 cards are enumerated consistently. DRA72x silicon behaves same way as DRA74x rev 1.1 as far as this functionality is considered. Test results on DRA74x and DRA72x EVMs: Before patch ------------ DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to silicon errata) DRA74x ES 1.1: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect programming of register DRA72x: Gen1 cards work, Gen2 cards do not work sometimes due to incorrect programming of register After patch ----------- DRA74x ES 1.0: Gen1 cards work, Gen2 cards do not work (expected result due to silicon errata) DRA74x ES 1.1: Gen1 cards work, Gen2 cards work consistently. DRA72x: Gen1 and Gen2 cards enumerate consistently. Signed-off-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hans de Goede authored
[ Upstream commit 37240034 ] The allwinner SDK uses a value of 3 for the disconnect threshold setting on sun6i, do the same in the kernel. In my previous experience with sun5i problems getting the threshold right is important to avoid usb2 devices being unplugged sometimes going unnoticed. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-