- 23 May, 2018 40 commits
-
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Currently we fail to program the iboost stuff for HDMI/DVI. Let's remedy that. Cc: stable@vger.kernel.org Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements") Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1468328376-6380-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
David Weinehall <david.weinehall@linux.intel.com> (cherry picked from commit 8d8bb85e) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Give a proper name for the SKL DDI_BUF_TRANS iboost bit. Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1770565 Bspec says: "For DDIA with x4 capability (DDI_BUF_CTL DDIA Lane Capability Control = DDIA x4), the I_boost value has to be programmed in both tx_blnclegsctl_0 and tx_blnclegsctl_4." Currently we only program tx_blnclegsctl_0. Let's do the other one as well. Cc: stable@vger.kernel.org Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements") Cc: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
-
Jeffrey Hugo authored
load_module() creates W+X mappings via __vmalloc_node_range() (from layout_and_allocate()->move_module()->module_alloc()) by using PAGE_KERNEL_EXEC. These mappings are later cleaned up via "call_rcu_sched(&freeinit->rcu, do_free_init)" from do_init_module(). This is a problem because call_rcu_sched() queues work, which can be run after debug_checkwx() is run, resulting in a race condition. If hit, the race results in a nasty splat about insecure W+X mappings, which results in a poor user experience as these are not the mappings that debug_checkwx() is intended to catch. This issue is observed on multiple arm64 platforms, and has been artificially triggered on an x86 platform. Address the race by flushing the queued work before running the arch-defined mark_rodata_ro() which then calls debug_checkwx(). Link: http://lkml.kernel.org/r/1525103946-29526-1-git-send-email-jhugo@codeaurora.org Fixes: e1a58320 ("x86/mm: Warn on W^X mappings") BugLink: https://launchpad.net/bugs/1769696Signed-off-by:
Jeffrey Hugo <jhugo@codeaurora.org> Reported-by:
Timur Tabi <timur@codeaurora.org> Reported-by:
Jan Glauber <jan.glauber@caviumnetworks.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Laura Abbott <labbott@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (backported from commit ae646f0b) Signed-off-by:
Manoj Iyer <manoj.iyer@canonical.com> Acked-by:
-
Heiko Carstens authored
BugLink: http://bugs.launchpad.net/bugs/1761674 Description: kernel: fix rwlock implementation Symptom: Kernel hangs, due to deadlock on an rwlock. Problem: With upstream commit 94232a43 ("s390/rwlock: improve writer fairness") rwlock writer fairness was supposed to be implemented. If a writer tries to take an rwlock it sets unconditionally the writer bit within the lock word and waits until all readers have released the lock. This however can lead to a deadlock since rwlocks can be taken recursively by readers. If e.g. CPU 0 holds the lock as a reader, and CPU 1 wants to write-lock the lock, then CPU 1 sets the writer bit and afterwards busy waits for CPU 0 to release the lock. If now CPU 0 tries to read-lock the lock again (recursively) it will also busy wait until CPU 1 removes the writer bit, which will never happen, since it waits for the first reader on CPU 0 to release the lock. Solution: Revert the rwlock writer fairness semantics again. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Michal Kubeček authored
BugLink: http://bugs.launchpad.net/bugs/1766573 Commit 69b34fb9 ("netfilter: xt_LOG: add net namespace support for xt_LOG") disabled logging packets using the LOG target from non-init namespaces. The motivation was to prevent containers from flooding kernel log of the host. The plan was to keep it that way until syslog namespace implementation allows containers to log in a safe way. However, the work on syslog namespace seems to have hit a dead end somewhere in 2013 and there are users who want to use xt_LOG in all network namespaces. This patch allows to do so by setting /proc/sys/net/netfilter/nf_log_all_netns to a nonzero value. This sysctl is only accessible from init_net so that one cannot switch the behaviour from inside a container. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> (cherry picked from commit 2851940f) Signed-off-by:
-
Cyril Bur authored
BugLink: http://bugs.launchpad.net/bugs/1771439 Userspace can begin and suspend a transaction within the signal handler which means they might enter sys_rt_sigreturn() with the processor in suspended state. sys_rt_sigreturn() wants to restore process context (which may have been in a transaction before signal delivery). To do this it must restore TM SPRS. To achieve this, any transaction initiated within the signal frame must be discarded in order to be able to restore TM SPRs as TM SPRs can only be manipulated non-transactionally.. >From the PowerPC ISA: TM Bad Thing Exception [Category: Transactional Memory] An attempt is made to execute a mtspr targeting a TM register in other than Non-transactional state. Not doing so results in a TM Bad Thing: [12045.221359] Kernel BUG at c000000000050a40 [verbose debug info unavailable] [12045.221470] Unexpected TM Bad Thing exception at c000000000050a40 (msr 0x201033) [12045.221540] Oops: Unrecoverable exception, sig: 6 [#1] [12045.221586] SMP NR_CPUS=2048 NUMA PowerNV [12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv kvm uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses enclosure scsi_transport_sas bnx2x ipr mdio libcrc32c [12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 #34 [12045.222224] task: c0000000fce38600 ti: c0000000fceb4000 task.ti: c0000000fceb4000 [12045.222293] NIP: c000000000050a40 LR: c0000000000163bc CTR: 0000000000000000 [12045.222361] REGS: c0000000fceb7ac0 TRAP: 0700 Not tainted (4.7.0) [12045.222418] MSR: 9000000300201033 <SF,HV,ME,IR,DR,RI,LE,TM[SE]> CR: 28444280 XER: 20000000 [12045.222625] CFAR: c0000000000163b8 SOFTE: 0 PACATMSCRATCH: 900000014280f033 GPR00: 01100000b8000001 c0000000fceb7d40 c00000000139c100 c0000000fce390d0 GPR04: 900000034280f033 0000000000000000 0000000000000000 0000000000000000 GPR08: 0000000000000000 b000000000001033 0000000000000001 0000000000000000 GPR12: 0000000000000000 c000000002926400 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 00003ffff98cadd0 00003ffff98cb470 0000000000000000 GPR28: 900000034280f033 c0000000fceb7ea0 0000000000000001 c0000000fce390d0 [12045.223535] NIP [c000000000050a40] tm_restore_sprs+0xc/0x1c [12045.223584] LR [c0000000000163bc] tm_recheckpoint+0x5c/0xa0 [12045.223630] Call Trace: [12045.223655] [c0000000fceb7d80] [c000000000026e74] sys_rt_sigreturn+0x494/0x6c0 [12045.223738] [c0000000fceb7e30] [c0000000000092e0] system_call+0x38/0x108 [12045.223806] Instruction dump: [12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8 [12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020 [12045.224074] ---[ end trace cb8002ee240bae76 ]--- It isn't clear exactly if there is really a use case for userspace returning with a suspended transaction, however, doing so doesn't (on its own) constitute a bad frame. As such, this patch simply discards the transactional state of the context calling the sigreturn and continues. Reported-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
Cyril Bur <cyrilbur@gmail.com> Tested-by:
Simon Guo <wei.guo.simon@gmail.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> (cherry picked from commit 78a3e888) Signed-off-by:
Colin King <colin.king@canonical.com> Acked-by:
-
Ryan Hsu authored
BugLink: https://bugs.launchpad.net/bugs/1748345 Preparation for a new QCA9377 firmware release. The new firmware release requires more IRAM banks, hence update that on ath10k. The IRAM banks promotion won't break any backwards compatibility, as those IRAM banks were not getting used in previous firmware releases. Signed-off-by:
Ryan Hsu <ryanhsu@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> (backported from commit fc8b9263) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Signed-off-by:
Brad Figg <brad.figg@canonical.com>
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1752536 We ship this firmware but it fails to load because it is not present in the initrd. Add a MODULE_FIRMWARE statement to fix this. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Acked-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1768825Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Romain Izard authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 82a3f87f upstream. As the mctrl_gpio driver can be built as a module, it needs to have its license specified with MODULE_LICENSE. Otherwise, it cannot access required symbols exported through EXPORT_SYMBOL_GPL. Signed-off-by:
Romain Izard <romain.izard.pro@gmail.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Daniel Wagner <wagi@monom.org> Signed-off-by:
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 4f71a2e0 upstream. To be able to make use of the mctrl-gpio helper from a module these functions must be exported. This was forgotten in the commit introducing support interrupt handling for these functions (while it was done for mctrl_gpio_enable_ms, *sigh*). Fixes: ce59e48f ("serial: mctrl_gpio: implement interrupt handling") Signed-off-by:
-
Yazen Ghannam authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit da6fa7ef upstream. Recent AMD systems support using MWAIT for C1 state. However, MWAIT will not allow deeper cstates than C1 on current systems. play_dead() expects to use the deepest state available. The deepest state available on AMD systems is reached through SystemIO or HALT. If MWAIT is available, it is preferred over the other methods, so the CPU never reaches the deepest possible state. Don't try to use MWAIT to play_dead() on AMD systems. Instead, use CPUIDLE to enter the deepest state advertised by firmware. If CPUIDLE is not available then fallback to HALT. Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org Cc: Yazen Ghannam <Yazen.Ghannam@amd.com> Link: https://lkml.kernel.org/r/20180403140228.58540-1-Yazen.Ghannam@amd.comSigned-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 1a512c08 upstream. A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout (as seen from user space) a few years ago: Originally, __BITS_PER_LONG was defined as 64 on x32, so we did not have padding after the 64-bit __kernel_time_t fields, After __BITS_PER_LONG got changed to 32, applications would observe extra padding. In other parts of the uapi headers we seem to have a mix of those expecting either 32 or 64 on x32 applications, so we can't easily revert the path that broke these two structures. Instead, this patch decouples x32 from the other architectures and moves it back into arch specific headers, partially reverting the even older commit 73a2d096 ("x86: remove all now-duplicate header files"). It's not clear whether this ever made any difference, since at least glibc carries its own (correct) copy of both of these header files, so possibly no application has ever observed the definitions here. Based on a suggestion from H.J. Lu, I tried out the tool from https://github.com/hjl-tools/linux-header to find other such bugs, which pointed out the same bug in statfs(), which also has a separate (correct) copy in glibc. Fixes: f4b4aae1 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ilya Dryomov authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 9c55ad1c upstream. ceph_con_workfn() validates con->state before calling try_read() and then try_write(). However, try_read() temporarily releases con->mutex, notably in process_message() and ceph_con_in_msg_alloc(), opening the window for ceph_con_close() to sneak in, close the connection and release con->sock. When try_write() is called on the assumption that con->state is still valid (i.e. not STANDBY or CLOSED), a NULL sock gets passed to the networking stack: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: selinux_socket_sendmsg+0x5/0x20 Make sure con->state is valid at the top of try_write() and add an explicit BUG_ON for this, similar to try_read(). Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/23706Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Jason Dillaman <dillaman@redhat.com> Signed-off-by:
-
Nicolin Chen authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit c656941d upstream. When the desired ratio is less than 256, the savesub (tolerance) in the calculation would become 0. This will then fail the loop- search immediately without reporting any errors. But if the ratio is smaller enough, there is no need to calculate the tolerance because PM divisor alone is enough to get the ratio. So a simple fix could be just to set PM directly instead of going into the loop-search. Reported-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Nicolin Chen <nicoleotsuka@gmail.com> Tested-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit d2ffed51 upstream. When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count + 1 bytes for printing. Cfr. commits 4efe874a ("PCI: Don't read past the end of sysfs "driver_override" buffer") and bf563b01 ("driver core: platform: Don't read past the end of "driver_override" buffer"). Fixes: 3cf38571 ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 6a7228d9 upstream. The driver_override implementation is susceptible to a race condition when different threads are reading vs storing a different driver override. Add locking to avoid this race condition. Cfr. commits 62655397 ("driver core: platform: fix race condition with driver_override") and 9561475d ("PCI: Fix race condition with driver_override"). Fixes: 3cf38571 ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 5f536246 upstream. For AMBA devices with unconfigured driver override, the "driver_override" sysfs virtual file is empty, while it contains "(null)" for platform and PCI devices. Make AMBA consistent with other buses by dropping the test for a NULL pointer. Note that contrary to popular belief, sprintf() handles NULL pointers fine; they are printed as "(null)". Signed-off-by:
-
Mahesh Rajashekhara authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 505aa4b6 upstream. A drive being sanitized will return NOT READY / ASC 0x4 / ASCQ 0x1b ("LOGICAL UNIT NOT READY. SANITIZE IN PROGRESS"). Prevent spinning up the drive until this condition clears. [mkp: tweaked commit message] Signed-off-by:
Mahesh Rajashekhara <mahesh.rajashekhara@microsemi.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Dmitry Vyukov authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 3e14c6ab upstream. This WARNING proved to be noisy. The function still returns an error and callers should handle it. That's how most of kernel code works. Downgrade the WARNING to pr_err() and leave WARNINGs for kernel bugs. Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Reported-by: syzbot+209c0f67f99fec8eb14b@syzkaller.appspotmail.com Reported-by: syzbot+7fb6d9525a4528104e05@syzkaller.appspotmail.com Reported-by: syzbot+2e63711063e2d8f9ea27@syzkaller.appspotmail.com Reported-by: syzbot+de73361ee4971b6e6f75@syzkaller.appspotmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Joakim Tjernlund authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 7b70eb14 upstream. Currently it is possible to read and/or write to suspend EB's. Writing /dev/mtdX or /dev/mtdblockX from several processes may break the flash state machine. Taken from cfi_cmdset_0001 driver. Signed-off-by:
Joakim Tjernlund <joakim.tjernlund@infinera.com> Cc: <stable@vger.kernel.org> Reviewed-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
-
Joakim Tjernlund authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 46a16a22 upstream. Some Micron chips does not work well wrt Erase suspend for boot blocks. This avoids the issue by not allowing Erase suspend for the boot blocks for the 28F00AP30(1GBit) chip. Signed-off-by:
-
Joakim Tjernlund authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 6510bbc8 upstream. Currently it is possible to read and/or write to suspend EB's. Writing /dev/mtdX or /dev/mtdblockX from several processes may break the flash state machine. Signed-off-by:
-
Kailang Yang authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit ea04a1db upstream. Fill COEF to change EAPD to verb control. Assigned codec type. This is an additional fix over 92f974df ("ALSA: hda/realtek - New vendor ID for ALC233"). [ More notes: according to Kailang, the chip is 10ec:0235 bonding for ALC233b, which is equivalent with ALC255. It's only used for Lenovo. The chip needs no alc_process_coef_fw() for headset unlike ALC255. ] Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit f5e94b4c upstream. When get_synthdev() is called for a MIDI device, it returns the fixed midi_synth_dev without the use refcounting. OTOH, the caller is supposed to unreference unconditionally after the usage, so this would lead to unbalanced refcount. This patch corrects the behavior and keep up the refcount balance also for the MIDI synth device. Cc: <stable@vger.kernel.org> Signed-off-by:
-
David Henningsson authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit f853dcaa upstream. It looks like a simple mistake that this struct member was forgotten. Audio_tstamp isn't used much, and on some archs (such as x86) this ioctl is not used by default, so that might be the reason why this has slipped for so long. Fixes: 4eeaaeae ("ALSA: core: add hooks for audio timestamps") Signed-off-by:
David Henningsson <diwic@ubuntu.com> Reviewed-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by:
-
Tetsuo Handa authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit bcdd0ca8 upstream. syzbot is reporting crashes triggered by memory allocation fault injection at tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we have tried commit 5362544b ("tty: don't panic on OOM in tty_set_ldisc()"). But we reverted that attempt by commit a8983d01 ("Revert "tty: don't panic on OOM in tty_set_ldisc()"") due to reproducible crash. We should spend resource for finding and fixing race condition bugs rather than complicate error paths for 2 * sizeof(void *) bytes allocation failure. [1] https://syzkaller.appspot.com/bug?id=489d33fa386453859ead58ff5171d43772b13aa3Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by:
syzbot <syzbot+40b7287c2dc987c48c81@syzkaller.appspotmail.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jiri Slaby <jslaby@suse.com> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Tony Lindgren authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit b2d89ad9 upstream. At least on droid 4 with control channel in ADM mode, there is no response to Modem Status Command (MSC). Currently gsmtty_modem_update() expects to have data in dlci->modem_rx unless debug & 2 is set. This means that on droid 4, things only work if debug & 2 is set. Let's fix the issue by ignoring empty dlci->modem_rx for ADM mode. In the AMD mode, CMD_MSC will never respond and gsm_process_modem() won't get called to set dlci->modem_rx. And according to ts_127010v140000p.pdf, MSC is only relevant if basic option is chosen, so let's test for that too. Fixes: ea3d8465 ("tty: n_gsm: Allow ADM response in addition to UA for control dlci") Cc: linux-serial@vger.kernel.org Cc: Alan Cox <alan@llwyncelyn.cymru> Cc: Dan Williams <dcbw@redhat.com> Cc: Jiri Prchal <jiri.prchal@aksignal.cz> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Cc: Michael Scott <michael.scott@linaro.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Russ Gorby <russ.gorby@intel.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Tony Lindgren authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit e9ec2254 upstream. Commit ea3d8465 ("tty: n_gsm: Allow ADM response in addition to UA for control dlci") added support for DLCI to stay in Asynchronous Disconnected Mode (ADM). But we still get long delays waiting for commands to other DLCI to complete: --> 5) C: SABM(P) Q> 0) C: UIH(F) Q> 0) C: UIH(F) Q> 0) C: UIH(F) ... This happens because gsm_control_send() sets cretries timer to T2 that is by default set to 34. This will cause resend for T2 times for the control frame. In ADM mode, we will never get a response so the control frame, so retries are just delaying all the commands. Let's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM mode for the control DLCI. Then we can use that in gsm_control_send() to set retries to 1. This means the control frame will be sent once allowing the other end at an opportunity to switch from ADM to ABM mode. Note that retries will be decremented in gsm_control_retransmit() so we don't want to set it to 0 here. Fixes: ea3d8465 ("tty: n_gsm: Allow ADM response in addition to UA for control dlci") Cc: linux-serial@vger.kernel.org Cc: Alan Cox <alan@llwyncelyn.cymru> Cc: Dan Williams <dcbw@redhat.com> Cc: Jiri Prchal <jiri.prchal@aksignal.cz> Cc: Jiri Slaby <jslaby@suse.cz> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Cc: Michael Scott <michael.scott@linaro.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Russ Gorby <russ.gorby@intel.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Tetsuo Handa authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 903f9db1 upstream. syzbot is reporting kernel panic [1] triggered by memory allocation failure at tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get() and caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init() does not need to call panic() when tty_ldisc_get() failed. [1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187Signed-off-by:
syzbot <syzkaller@googlegroups.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Gerd Hoffmann authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit d02d2700 upstream. Wait until we have enough space in the virt queue to actually queue up our request. Avoids the guest spinning in case we have a non-zero amount of free entries but not enough for the request. Cc: stable@vger.kernel.org Reported-by:
Alain Magloire <amagloire@blackberry.com> Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180403095904.11152-1-kraxel@redhat.comSigned-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Michael S. Tsirkin authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit a7a69ec0 upstream. Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose” buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers until device unplug. Of course this means we might get an interrupt for a vq without an attached port now. Handle that by discarding the consumed buffer. Reported-by:
Tiwei Bie <tiwei.bie@intel.com> Fixes: b3258ff1 ("virtio: Decrement avail idx on buffer detach") Cc: stable@vger.kernel.org Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Michael S. Tsirkin authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 24a7e4d2 upstream. For cleanup it's helpful to be able to simply scan all vqs and discard all data. Add an iterator to do that. Cc: stable@vger.kernel.org Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 1d8d6428 upstream. The Dell Dock USB-audio device with 0bda:4014 is behaving notoriously bad, and we have already applied some workaround to avoid the firmware hiccup. Yet we still need to skip one thing, the Extension Unit at ID 4, which doesn't react correctly to the mixer ctl access. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1090658 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ravi Chandra Sadineni authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 83a62c51 upstream. On chromebooks we depend on wakeup count to identify the wakeup source. But currently USB devices do not increment the wakeup count when they trigger the remote wake. This patch addresses the same. Resume condition is reported differently on USB 2.0 and USB 3.0 devices. On USB 2.0 devices, a wake capable device, if wake enabled, drives resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). The upstream facing port then sets C_PORT_SUSPEND bit and reports a port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port has resumed before driving the resume signal from the host and C_PORT_SUSPEND is set, then the device attached to the given port might be the reason for the last system wakeup. Increment the wakeup count for the same. On USB 3.0 devices, a function may signal that it wants to exit from device suspend by sending a Function Wake Device Notification to the host (USB3.0 spec section 8.5.6.4) Thus on receiving the Function Wake, increment the wakeup count. Signed-off-by:
Ravi Chandra Sadineni <ravisadineni@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Kamil Lulko authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 3180dabe upstream. Add DELAY_INIT quirk to fix the following problem with HP v222w 16GB Mini: usb 1-3: unable to read config index 0 descriptor/start: -110 usb 1-3: can't read configurations, error -110 usb 1-3: can't set config #1, error -110 Signed-off-by:
Kamil Lulko <kamilx.lulko@intel.com> Signed-off-by:
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Kyle Roeschley authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 1e23aace upstream. Added the USB VID and PID for the USB serial console on some National Instruments devices. Signed-off-by:
Kyle Roeschley <kyle.roeschley@ni.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Vasyl Vavrychuk authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit 470b5d6f upstream. Arrow USB Blaster integrated on MAX1000 board uses the same vendor ID (0x0403) and product ID (0x6010) as the "original" FTDI device. This patch avoids picking up by ftdi_sio of the first interface of this USB device. After that this device can be used by Arrow user-space JTAG driver. Signed-off-by:
Vasyl Vavrychuk <vvavrychuk@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Collin May authored
BugLink: http://bugs.launchpad.net/bugs/1768825 commit fe710508 upstream. Add simple driver for libtransistor USB console. This device is implemented in software: https://github.com/reswitched/libtransistor/blob/development/lib/usb_serial.cSigned-off-by:
Collin May <collin@collinswebsite.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
