- 13 Apr, 2018 21 commits
-
-
Wen Xiong authored
[ Upstream commit f36ea50c ] When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns "Input/output error". Looks block layer split the bio after calling bio_integrity_prep(bio). This patch fixes the issue. Below is how we debug this issue: (1)format nvme to 4K block # size with type 2 DIF (2)dd with block size bigger than 1024k. oflag=direct dd: error writing '/dev/nvme0n1': Input/output error We added some debug code in nvme device driver. It showed us the first op and the second op have the same bi and pi address. This is not correct. 1st op: nvme0n1 Op:Wr slba 0x505 length 0x100, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x505 Guard 0x00b1, AT 0x0000, RT physical 0x00000505 RT virtual 0x00002828 2nd op: nvme0n1 Op:Wr slba 0x605 length 0x1, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x605 ==> This op fails and subsequent 5 retires.. Guard 0x00b1, AT 0x0000, RT physical 0x00000605 RT virtual 0x00002828 With the fix, It showed us both of the first op and the second op have correct bi and pi address. 1st op: nvme2n1 Op:Wr slba 0x505 length 0x100, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x505 Guard 0x5ccb, AT 0x0000, RT physical 0x00000505 RT virtual 0x00002828 2nd op: nvme2n1 Op:Wr slba 0x605 length 0x1, PI ctrl=0x1400, dsmgmt=0x0, AT=0x0 & RT=0x605 Guard 0xab4c, AT 0x0000, RT physical 0x00000605 RT virtual 0x00003028 Signed-off-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rabin Vincent authored
[ Upstream commit 560d3889 ] cifs_relock_file() can perform a down_write() on the inode's lock_sem even though it was already performed in cifs_strict_readv(). Lockdep complains about this. AFAICS, there is no problem here, and lockdep just needs to be told that this nesting is OK. ============================================= [ INFO: possible recursive locking detected ] 4.11.0+ #20 Not tainted --------------------------------------------- cat/701 is trying to acquire lock: (&cifsi->lock_sem){++++.+}, at: cifs_reopen_file+0x7a7/0xc00 but task is already holding lock: (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&cifsi->lock_sem); lock(&cifsi->lock_sem); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by cat/701: #0: (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310 stack backtrace: CPU: 0 PID: 701 Comm: cat Not tainted 4.11.0+ #20 Call Trace: dump_stack+0x85/0xc2 __lock_acquire+0x17dd/0x2260 ? trace_hardirqs_on_thunk+0x1a/0x1c ? preempt_schedule_irq+0x6b/0x80 lock_acquire+0xcc/0x260 ? lock_acquire+0xcc/0x260 ? cifs_reopen_file+0x7a7/0xc00 down_read+0x2d/0x70 ? cifs_reopen_file+0x7a7/0xc00 cifs_reopen_file+0x7a7/0xc00 ? printk+0x43/0x4b cifs_readpage_worker+0x327/0x8a0 cifs_readpage+0x8c/0x2a0 generic_file_read_iter+0x692/0xd00 cifs_strict_readv+0x29f/0x310 generic_file_splice_read+0x11c/0x1c0 do_splice_to+0xa5/0xc0 splice_direct_to_actor+0xfa/0x350 ? generic_pipe_buf_nosteal+0x10/0x10 do_splice_direct+0xb5/0xe0 do_sendfile+0x278/0x3a0 SyS_sendfile64+0xc4/0xe0 entry_SYSCALL_64_fastpath+0x1f/0xbe Signed-off-by:
Rabin Vincent <rabinv@axis.com> Acked-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit f4b23de3 ] It turns out the Linux server has a bug in its implementation of supattr_exclcreat; it returns the set of all attributes, whether or not they are supported by minor version 1. In order to avoid a regression, we therefore apply the supported_attrs as a mask on top of whatever the server sent us. Reported-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Talat Batheesh authored
[ Upstream commit 89c55768 ] Inserting steering rules with illegal ring is an invalid operation, block it. Fixes: 82067281 ('net/mlx4_en: Manage flow steering rules with ethtool') Signed-off-by:
Talat Batheesh <talatb@mellanox.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Heiko Carstens authored
[ Upstream commit d04a4c76 ] The perf tool assumes that kernel symbols are never present at address zero. In fact it assumes if functions that map symbols to addresses return zero, that the symbol was not found. Given that s390's _text symbol historically is located at address zero this yields at least a couple of false errors and warnings in one of perf's test cases about not present symbols ("perf test 1"). To fix this simply move the _text symbol to address 0x200, just behind the initial psw and channel program located at the beginning of the kernel image. This is now hard coded within the linker script. I tried a nicer solution which moves the initial psw and channel program into an own section. However that would move the symbols within the "real" head.text section to different addresses, since the ".org" statements within head.S are relative to the head.text section. If there is a new section in front, everything else will be moved. Alternatively I could have adjusted all ".org" statements. But this current solution seems to be the easiest one, since nobody really cares where the _text symbol is actually located. Reported-by:
Zvonko Kosic <zkosic@linux.vnet.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Kirill Tkhai authored
[ Upstream commit 8896c23d ] alloc_pidmap() advances pid_namespace::last_pid. When first pid allocation fails, then next created process will have pid 2 and pid_ns_prepare_proc() won't be called. So, pid_namespace::proc_mnt will never be initialized (not to mention that there won't be a child reaper). I saw crash stack of such case on kernel 3.10: BUG: unable to handle kernel NULL pointer dereference at (null) IP: proc_flush_task+0x8f/0x1b0 Call Trace: release_task+0x3f/0x490 wait_consider_task.part.10+0x7ff/0xb00 do_wait+0x11f/0x280 SyS_wait4+0x7d/0x110 We may fix this by restore of last_pid in 0 or by prohibiting of futher allocations. Since there was a similar issue in Oleg Nesterov's commit 314a8ad0 ("pidns: fix free_pid() to handle the first fork failure"). and it was fixed via prohibiting allocation, let's follow this way, and do the same. Link: http://lkml.kernel.org/r/149201021004.4863.6762095011554287922.stgit@localhost.localdomainSigned-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Cc: Andrei Vagin <avagin@virtuozzo.com> Cc: Andreas Gruenbacher <agruenba@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Michael Kerrisk <mtk.manpages@googlemail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Paul Moore <paul@paul-moore.com> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@kernel.org> Cc: Serge Hallyn <serge@hallyn.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 146180c0 ] The "DIV_ROUND_UP(size, PAGE_SIZE)" operation can overflow if "size" is more than ULLONG_MAX - PAGE_SIZE. Link: http://lkml.kernel.org/r/20170322111950.GA11279@mwandaSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Jorgen Hansen <jhansen@vmware.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
J. Bruce Fields authored
[ Upstream commit efda760f ] As reported by David Jeffery: "a signal was sent to lockd while lockd was shutting down from a request to stop nfs. The signal causes lockd to call restart_grace() which puts the lockd_net structure on the grace list. If this signal is received at the wrong time, it will occur after lockd_down_net() has called locks_end_grace() but before lockd_down_net() stops the lockd thread. This leads to lockd putting the lockd_net structure back on the grace list, then exiting without anything removing it from the list." So, perform the final locks_end_grace() from the the lockd thread; this ensures it's serialized with respect to restart_grace(). Reported-by:
David Jeffery <djeffery@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit 48f5bccc ] When users set flow control using ethtool the bits are set properly in the CPGMAC_SL MACCONTROL register, but the FIFO depth in the respective Port n Maximum FIFO Blocks (Pn_MAX_BLKS) registers remains set to the minimum size reset value. When receive flow control is enabled on a port, the port's associated FIFO block allocation must be adjusted. The port RX allocation must increase to accommodate the flow control runout. The TRM recommends numbers of 5 or 6. Hence, apply required Port FIFO configuration to Pn_MAX_BLKS.Pn_TX_MAX_BLKS=0xF and Pn_MAX_BLKS.Pn_RX_MAX_BLKS=0x5 during interface initialization. Cc: Schuyler Patton <spatton@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Jim Baxter authored
[ Upstream commit aeca3a77 ] The zero padding that is added to NTB's does not zero the memory correctly. This is because the skb_put modifies the value of skb_out->len which results in the memset command not setting any memory to zero as (ctx->tx_max - skb_out->len) == 0. I have resolved this by storing the size of the memory to be zeroed before the skb_put and using this in the memset call. Signed-off-by:
Jim Baxter <jim_baxter@mentor.com> Reviewed-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit cf9806f3 ] We should unlock and re-enable IRQs if this allocation fails. Fixes: 25930707 ("ipmi: Add SMBus interface driver (SSIF) ") Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Kees Cook authored
[ Upstream commit df5303a8 ] Using memcpy() from a string that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. Instead, use strncpy() which will fill the trailing bytes with zeros. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
[ Upstream commit 9e4eb1ce ] Using memcpy() from a string that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. Instead, use strncpy() which will fill the trailing bytes with zeros. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
-
Luca Coelho authored
[ Upstream commit f8860ce8 ] If ieee80211_hw_restart() is called during authentication, the authentication process will continue, causing the driver to be called in a wrong state. This ultimately causes an oops in the iwlwifi driver (at least). This fixes bugzilla 195299 partly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195299Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit d90c9024 ] The sadb_x_sec_len is stored in the unit 'byte divided by eight'. So we have to multiply this value by eight before we can do size checks. Otherwise we may get a slab-out-of-bounds when we memcpy the user sec_ctx. Fixes: df71837d ("[LSM-IPSec]: Security association restriction.") Reported-by:
Andrey Konovalov <andreyknvl@google.com> Tested-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 55d69427 ] Let the target core check the CMD_T_ABORTED flag instead of the SRP target driver. Hence remove the transport_check_aborted_status() call. Since state == SRPT_STATE_CMD_RSP_SENT is something that really should not happen, do not try to recover if srpt_queue_response() is called for an I/O context that is in that state. This patch is a bug fix because the srpt_abort_cmd() call is misplaced - if that function is called from srpt_queue_response() it should either be called before the command state is changed or after the response has been sent. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Andy Grover <agrover@redhat.com> Cc: David Disseldorp <ddiss@suse.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 0048fdd0 ] If the server returns NFS4ERR_CONN_NOT_BOUND_TO_SESSION because we are trunking, then RECLAIM_COMPLETE must handle that by calling nfs4_schedule_session_recovery() and then retrying. Reported-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Josh Poimboeuf authored
[ Upstream commit 42fc6c6c ] Andrey Konovalov reported the following warning while fuzzing the kernel with syzkaller: WARNING: kernel stack regs at ffff8800686869f8 in a.out:4933 has bad 'bp' value c3fc855a10167ec0 The unwinder dump revealed that RBP had a bad value when an interrupt occurred in csum_partial_copy_generic(). That function saves RBP on the stack and then overwrites it, using it as a scratch register. That's problematic because it breaks stack traces if an interrupt occurs in the middle of the function. Replace the usage of RBP with another callee-saved register (R15) so stack traces are no longer affected. Reported-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: David S . Miller <davem@davemloft.net> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vlad Yasevich <vyasevich@gmail.com> Cc: linux-sctp@vger.kernel.org Cc: netdev <netdev@vger.kernel.org> Cc: syzkaller <syzkaller@googlegroups.com> Link: http://lkml.kernel.org/r/4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Pan Bian authored
[ Upstream commit 75892900 ] Function devm_regmap_init_mmio() returns an ERR_PTR on error. However, in function snvs_rtc_probe() its return value is checked against NULL. This patch fixes it by checking the return value with IS_ERR(). Signed-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Julia Cartwright authored
[ Upstream commit 3d05f3ae ] On mainline, there is no functional difference, just less code, and symmetric lock/unlock paths. On PREEMPT_RT builds, this fixes the following warning, seen by Alexander GQ Gerasiov, due to the sleeping nature of spinlocks. BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:993 in_atomic(): 0, irqs_disabled(): 1, pid: 58, name: kworker/u12:1 CPU: 5 PID: 58 Comm: kworker/u12:1 Tainted: G W 4.9.20-rt16-stand6-686 #1 Hardware name: Supermicro SYS-5027R-WRF/X9SRW-F, BIOS 3.2a 10/28/2015 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: dump_stack+0x47/0x68 ? migrate_enable+0x4a/0xf0 ___might_sleep+0x101/0x180 rt_spin_lock+0x17/0x40 add_stripe_bio+0x4e3/0x6c0 [raid456] ? preempt_count_add+0x42/0xb0 raid5_make_request+0x737/0xdd0 [raid456] Reported-by:
Alexander GQ Gerasiov <gq@redlab-i.ru> Tested-by:
Julia Cartwright <julia@ni.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 842be75c ] Due to the way I did the RX bitrate conversions in mac80211 with spatch, going setting flags to setting the value, many drivers now don't set the bandwidth value for 20 MHz, since with the flags it wasn't necessary to (there was no 20 MHz flag, only the others.) Rather than go through and try to fix up all the drivers, instead renumber the enum so that 20 MHz, which is the typical bandwidth, actually has the value 0, making those drivers all work again. If VHT was hit used with a driver not reporting it, e.g. iwlmvm, this manifested in hitting the bandwidth warning in cfg80211_calculate_bitrate_vht(). Reported-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
- 08 Apr, 2018 19 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit 2fe832c6 which is commit 53c81e95 upstream. Ben writes that there are a number of follow-on patches needed to fix this up, but they get complex to backport, and some custom fixes are needed, so let's just revert this and wait for a "real" set of patches to resolve this to be submitted if it is really needed. Reported-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Cc: Petr Vorel <pvorel@suse.cz> Cc: Alexey Kodanev <alexey.kodanev@oracle.com> Cc: David S. Miller <davem@davemloft.net> Cc: Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This fixes up commit 1d1cb762 which was commit 8e6ce7eb upstream. Ben writes: This goto should not have been changed, as no DMA mapping has been attempted at this point in the function. This seems to have been fixed upstream by commit 6a885b60 "liquidio: Introduce new octeon2/3 header". I leave it to you to work out how it should be fixed in 4.4-stable. Fix this up by hand, as the referenced patch isn't worthy of being backported. Reported-by:
-
Greg Kroah-Hartman authored
commit 11dd9e2c, which is commit c5a2a394 upstream had an error in it. Ben writes: The '!' needs to be deleted. This appears to have been fixed upstream by: commit 8aedbf58 Author: Fabien Parent <fparent@baylibre.com> Date: Thu Feb 23 19:01:56 2017 +0100 spi: davinci: Use SPI framework to handle DMA mapping which is not suitable for stable. So I'm just fixing this up directly. Reported-by:
-
Greg Kroah-Hartman authored
This reverts commit 9bf9e352 which was commit a4e84aae upstream. Ben writes: MQ IO schedulers were introduced in 4.11, so this shouldn't be needed in older branches. It also causes a performance regression (fixed upstream). Please revert this for 4.4 and 4.9. So let's revert it! Reported-by:
-
Greg Kroah-Hartman authored
This reverts commit 3f7dfb7f which was commit a8b149d3 upstream. The backport was not correct, so just drop it entirely. Reported-by:
-
Greg Kroah-Hartman authored
This reverts commit ffa0a825 which was commit 7be4b5dc upstream. It requires a driver that was not merged until 4.16, so remove it from this stable tree as it is pointless. Reported-by:
-
Greg Kroah-Hartman authored
This reverts commit 59df934a which was comit e153db03 upstream. It requires a driver that was not merged until 4.16, so remove it from this stable tree as it is pointless. Reported-by:
-
Greg Kroah-Hartman authored
This reverts commit 4fbe4220 which was commit fda78d7a upstream. The dependancy tree is just too messy here, just drop it from this kernel as it's not really needed here. Reported-by:
-
Dan Williams authored
commit 1d91c1d2 upstream. There are multiple problems with the dynamic sanity checking in array_index_nospec_mask_check(): * It causes unnecessary overhead in the 32-bit case since integer sized @index values will no longer cause the check to be compiled away like in the 64-bit case. * In the 32-bit case it may trigger with user controllable input when the expectation is that should only trigger during development of new kernel enabling. * The macro reuses the input parameter in multiple locations which is broken if someone passes an expression like 'index++' to array_index_nospec(). Reported-by:
Dan Williams <dan.j.williams@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/151881604278.17395.6605847763178076520.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
-
Will Deacon authored
commit 8fa80c50 upstream. For architectures providing their own implementation of array_index_mask_nospec() in asm/barrier.h, attempting to use WARN_ONCE() to complain about out-of-range parameters using WARN_ON() results in a mess of mutually-dependent include files. Rather than unpick the dependencies, simply have the core code in nospec.h perform the checking for us. Signed-off-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1517840166-15399-1-git-send-email-will.deacon@arm.comSigned-off-by:
-
Matthias Brugger authored
commit d61d263c upstream. The driver implementation returns support for private flags, while no private flags are present. When asked for the number of private flags it returns the number of statistic flag names. Fix this by returning EOPNOTSUPP for not implemented ethtool flags. Signed-off-by:
Matthias Brugger <mbrugger@suse.com> Signed-off-by:
-
Guoqing Jiang authored
commit 6f287ca6 upstream. We need to set "first = 0' at the end of rdev_for_each loop, so we can get the array's min_offset_diff correctly otherwise min_offset_diff just means the last rdev's offset diff. [only the first chunk, due to b506335e ("md/raid10: skip spare disk as 'first' disk") being already applied - gregkh] Suggested-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Guoqing Jiang <gqjiang@suse.com> Reviewed-by:
-
Keerthy authored
commit 1f166499 upstream. The PMICs have POWERHOLD set by default which prevents PMIC shutdown even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority. So to enable pmic power off this property lets one over ride the default value and enable pmic power off. Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Keerthy authored
commit 7c62de5f upstream. Add power hold and power controller properties to palmas node. This is needed to shutdown pmic correctly on boards with powerhold set. Signed-off-by:
-
Keerthy authored
commit 0ea66f76 upstream. GPIO7 is configured in POWERHOLD mode which has higher priority over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON bit is turned off. This property enables driver to over ride the POWERHOLD value to GPIO7 so as to turn off the PMIC in power off scenarios. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Mike Frysinger authored
commit 65d9982d upstream. ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined" since at least March 1984. The Linux kernel has treated it as SGR 22 "normal intensity" since it was added in Linux-0.96b in June 1992. Before that, it was simply ignored. Other terminal emulators have either ignored it, or treat it as double underline now. xterm for example added support in its 304 release (May 2014) [2] where it was previously ignoring it. Changing this behavior shouldn't be an issue: - It isn't a named capability in ncurses's terminfo database, so no script is using libtinfo/libcurses to look this up, or using tput to query & output the right sequence. - Any script assuming SGR 21 will reset intensity in all terminals already do not work correctly on non-Linux VTs (including running under screen/tmux/etc...). - If someone has written a script that only runs in the Linux VT, and they're using SGR 21 (instead of SGR 22), the output should still be readable. imo it's important to change this as the Linux VT's non-conformance is sometimes used as an argument for other terminal emulators to not implement SGR 21 at all, or do so incorrectly. [1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm [2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bcafbee00bc73b3f1eeb9dSigned-off-by:
Mike Frysinger <vapier@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Ondrej Zary authored
commit 04bb1719 upstream. The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g. VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all VAIO machines by the nomux blacklist, the data from touch sensor buttons and touchpad are combined. The protocol used by the buttons is probably similar to the touchpad protocol (both are Synaptics) so both devices get enabled. The controller combines the data, creating a mess which results in random button clicks, touchpad stopping working and lost sync error messages: psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 psmouse serio1: issuing reconnect request Add a new i8042_dmi_forcemux_table whitelist with VGN-CS. With MUX enabled, touch sensor buttons are detected as separate device (and left disabled as there's currently no driver), fixing all touchpad problems. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dennis Wassenberg authored
commit b56af54a upstream. Reset i8042 before probing because of insufficient BIOS initialisation of the i8042 serial controller. This makes Synaptics touchpad detection possible. Without resetting the Synaptics touchpad is not detected because there are always NACK messages from AUX port. Signed-off-by:
Dennis Wassenberg <dennis.wassenberg@secunet.com> Cc: stable@vger.kernel.org Signed-off-by:
-
