- 31 Jul, 2020 9 commits
-
-
Olga Kornievskaia authored
commit 65caafd0 upstream. Reverting commit d03727b2 "NFSv4 fix CLOSE not waiting for direct IO compeletion". This patch made it so that fput() by calling inode_dio_done() in nfs_file_release() would wait uninterruptably for any outstanding directIO to the file (but that wait on IO should be killable). The problem the patch was also trying to address was REMOVE returning ERR_ACCESS because the file is still opened, is supposed to be resolved by server returning ERR_FILE_OPEN and not ERR_ACCESS. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ben Skeggs authored
[ Upstream commit 0156e76d ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Tom Rix authored
[ Upstream commit 28b18e4e ] clang static analysis flags this garbage return drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return v; ^~~~~~~~ static inline u16 gm_phy_read( ... { u16 v; __gm_phy_read(hw, port, reg, &v); return v; } __gm_phy_read can return without setting v. So handle similar to skge.c's gm_phy_read, initialize v. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Xie He authored
[ Upstream commit 9dc829a1 ] When this driver transmits data, first this driver will remove a pseudo header of 1 byte, then the lapb module will prepend the LAPB header of 2 or 3 bytes, then this driver will prepend a length field of 2 bytes, then the underlying Ethernet device will prepend its own header. So, the header length required should be: -1 + 3 + 2 + "the header length needed by the underlying device". This patch fixes kernel panic when this driver is used with AF_PACKET SOCK_DGRAM sockets. Signed-off-by:
Xie He <xie.he.0141@gmail.com> Signed-off-by:
-
Max Filippov authored
[ Upstream commit 0d5ab144 ] Increment *pos in the cpuinfo_op.next to fix the following warning triggered by cat /proc/cpuinfo: seq_file: buggy .next function c_next did not update position index Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Max Filippov authored
[ Upstream commit 73f99413 ] Building xtensa kernel with gcc-10 produces the following warnings: arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types for built-in function ‘__sync_fetch_and_and_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types for built-in function ‘__sync_fetch_and_or_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] Fix declarations of these functions to avoid the warning. Signed-off-by:
-
Tom Rix authored
[ Upstream commit 5aee52c4 ] clang static analysis flags several null function pointer problems. drivers/scsi/scsi_transport_spi.c:374:1: warning: Called function pointer is null (null dereference) [core.CallAndMessage] spi_transport_max_attr(offset, "%d\n"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewing the store_spi_store_max macro if (i->f->set_##field) return -EINVAL; should be if (!i->f->set_##field) return -EINVAL; Link: https://lore.kernel.org/r/20200627133242.21618-1-trix@redhat.comReviewed-by:
James Bottomley <jejb@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Markus Theil authored
[ Upstream commit 0b467b63 ] Without this patch, eapol frames cannot be received in mesh mode, when 802.1X should be used. Initially only a MGTK is defined, which is found and set as rx->key, when there are no other keys set. ieee80211_drop_unencrypted would then drop these eapol frames, as they are data frames without encryption and there exists some rx->key. Fix this by differentiating between mesh eapol frames and other data frames with existing rx->key. Allow mesh mesh eapol frames only if they are for our vif address. With this patch in-place, ieee80211_rx_h_mesh_fwding continues after the ieee80211_drop_unencrypted check and notices, that these eapol frames have to be delivered locally, as they should. Signed-off-by:
Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20200625104214.50319-1-markus.theil@tu-ilmenau.de [small code cleanups] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Jacky Hu authored
[ Upstream commit 69339d08 ] uart0_pins is defined as: static const unsigned uart0_pins[] = {135, 136, 137, 138, 139}; which npins is wronly specified as 9 later { .name = "uart0", .pins = uart0_pins, .npins = 9, }, npins should be 5 instead of 9 according to the definition. Signed-off-by:
Jacky Hu <hengqing.hu@gmail.com> Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 22 Jul, 2020 31 commits
-
-
Greg Kroah-Hartman authored
-
Suraj Jitindar Singh authored
This patch is to fix the backport of the upstream patch: cc51e542 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ When this was backported to the 4.9 and 4.14 stable branches the line + c->x86_cache_bits = c->x86_phys_bits; was applied in the wrong place, being added to the identify_cpu_without_cpuid() function instead of the get_cpu_cap() function which it was correctly applied to in the 4.4 backport. This means that x86_cache_bits is not set correctly resulting in the following warning due to the cache bits being left uninitalised (zero). WARNING: CPU: 0 PID: 7566 at arch/x86/kvm/mmu.c:284 kvm_mmu_set_mmio_spte_mask+0x4e/0x60 [kvm Modules linked in: kvm_intel(+) kvm irqbypass ipv6 crc_ccitt binfmt_misc evdev lpc_ich mfd_core ioatdma pcc_cpufreq dca ena acpi_power_meter hwmon acpi_pad button ext4 crc16 mbcache jbd2 fscrypto nvme nvme_core dm_mirror dm_region_hash dm_log dm_mod dax Hardware name: Amazon EC2 i3.metal/Not Specified, BIOS 1.0 10/16/2017 task: ffff88ff77704c00 task.stack: ffffc9000edac000 RIP: 0010:kvm_mmu_set_mmio_spte_mask+0x4e/0x60 [kvm RSP: 0018:ffffc9000edafc60 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffff45 RDX: 000000000000002e RSI: 0008000000000001 RDI: 0008000000000001 RBP: ffffffffa036f000 R08: ffffffffffffff80 R09: ffffe8ffffccb3c0 R10: 0000000000000038 R11: 0000000000000000 R12: 0000000000005b80 R13: ffffffffa0370e40 R14: 0000000000000001 R15: ffff88bf7c0927e0 FS: 00007fa316f24740(0000) GS:ffff88bf7f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa316ea0000 CR3: 0000003f7e986004 CR4: 00000000003606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kvm_mmu_module_init+0x166/0x230 [kvm kvm_arch_init+0x5d/0x150 [kvm kvm_init+0x1c/0x2d0 [kvm ? hardware_setup+0x4a6/0x4a6 [kvm_intel vmx_init+0x23/0x6aa [kvm_intel ? hardware_setup+0x4a6/0x4a6 [kvm_intel do_one_initcall+0x3e/0x15d do_init_module+0x5b/0x1e5 load_module+0x19e6/0x1dc0 ? SYSC_init_module+0x13b/0x170 SYSC_init_module+0x13b/0x170 do_syscall_64+0x67/0x110 entry_SYSCALL_64_after_hwframe+0x41/0xa6 RIP: 0033:0x7fa316828f3a RSP: 002b:00007ffc9d65c1f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af RAX: ffffffffffffffda RBX: 00007fa316b08849 RCX: 00007fa316828f3a RDX: 00007fa316b08849 RSI: 0000000000071328 RDI: 00007fa316e37000 RBP: 0000000000b47e80 R08: 0000000000000003 R09: 0000000000000000 R10: 00007fa316822dba R11: 0000000000000246 R12: 0000000000b46340 R13: 0000000000b464c0 R14: 0000000000000000 R15: 0000000000040000 Code: e9 65 06 00 75 25 48 b8 00 00 00 00 00 00 00 40 48 09 c6 48 09 c7 48 89 35 f8 65 06 00 48 89 3d f9 65 06 00 c3 0f 0b 0f 0b eb d2 <0f> 0b eb d7 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 Fixes: 4.9.x ef3d45c9 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ Fixes: 4.14.x ec403483 x86/speculation/l1tf: Increase l1tf memory limit for Nehalem+ Cc: stable@vger.kernel.org # 4.9.x-4.14.x Signed-off-by:
Suraj Jitindar Singh <surajjs@amazon.com> Reviewed-by:
Samuel Mendoza-Jonas <samjonas@amazon.com> Reviewed-by:
Frank van der Linden <fllinden@amazon.com> Signed-off-by:
-
Marc Zyngier authored
commit 005c34ae upstream. The GIC driver uses a RMW sequence to update the affinity, and relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences to update it atomically. But these sequences only expand into anything meaningful if the BL_SWITCHER option is selected, which almost never happens. It also turns out that using a RMW and locks is just as silly, as the GIC distributor supports byte accesses for the GICD_TARGETRn registers, which when used make the update atomic by definition. Drop the terminally broken code and replace it by a byte write. Fixes: 04c8b0f8 ("irqchip/gic: Make locking a BL_SWITCHER only feature") Cc: stable@vger.kernel.org Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
-
Vincent Guittot authored
commit 01cfcde9 upstream. task_h_load() can return 0 in some situations like running stress-ng mmapfork, which forks thousands of threads, in a sched group on a 224 cores system. The load balance doesn't handle this correctly because env->imbalance never decreases and it will stop pulling tasks only after reaching loop_max, which can be equal to the number of running tasks of the cfs. Make sure that imbalance will be decreased by at least 1. misfit task is the other feature that doesn't handle correctly such situation although it's probably more difficult to face the problem because of the smaller number of CPUs and running tasks on heterogenous system. We can't simply ensure that task_h_load() returns at least one because it would imply to handle underflow in other places. Signed-off-by:
Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Valentin Schneider <valentin.schneider@arm.com> Reviewed-by:
Dietmar Eggemann <dietmar.eggemann@arm.com> Tested-by:
-
Will Deacon authored
commit 3a5a4366 upstream. Luis reports that, when reverse debugging with GDB, single-step does not function as expected on arm64: | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP | request by GDB won't execute the underlying instruction. As a consequence, | the PC doesn't move, but we return a SIGTRAP just like we would for a | regular successful PTRACE_SINGLESTEP request. The underlying problem is that when the CPU register state is restored as part of a reverse step, the SPSR.SS bit is cleared and so the hardware single-step state can transition to the "active-pending" state, causing an unexpected step exception to be taken immediately if a step operation is attempted. In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate accessible by the GPR regset, but it's a bit late for that now. Instead, simply prevent userspace from configuring the bit to a value which is inconsistent with the TIF_SINGLESTEP state for the task being traced. Cc: <stable@vger.kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Keno Fischer <keno@juliacomputing.com> Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.orgReported-by:
Luis Machado <luis.machado@linaro.org> Tested-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Michał Mirosław authored
commit b037d60a upstream. Uninterruptible context is not needed in the driver and causes lockdep warning because of mutex taken in of_alias_get_id(). Convert the lock to mutex to avoid the issue. Cc: stable@vger.kernel.org Fixes: 099343c6 ("ARM: at91: atmel-ssc: add device tree support") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/50f0d7fa107f318296afb49477c3571e4d6978c5.1592998403.git.mirq-linux@rere.qmqm.plSigned-off-by:
-
Krzysztof Kozlowski authored
commit f5e5677c upstream. NULL pointer exception happens occasionally on serial output initiated by login timeout. This was reproduced only if kernel was built with significant debugging options and EDMA driver is used with serial console. col-vf50 login: root Password: Login timed out after 60 seconds. Unable to handle kernel NULL pointer dereference at virtual address 00000044 Internal error: Oops: 5 [#1] ARM CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4 Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) (fsl_edma_tx_handler) from [<8016eb10>] (__handle_irq_event_percpu+0x64/0x304) (__handle_irq_event_percpu) from [<8016eddc>] (handle_irq_event_percpu+0x2c/0x7c) (handle_irq_event_percpu) from [<8016ee64>] (handle_irq_event+0x38/0x5c) (handle_irq_event) from [<801729e4>] (handle_fasteoi_irq+0xa4/0x160) (handle_fasteoi_irq) from [<8016ddcc>] (generic_handle_irq+0x34/0x44) (generic_handle_irq) from [<8016e40c>] (__handle_domain_irq+0x54/0xa8) (__handle_domain_irq) from [<80508bc8>] (gic_handle_irq+0x4c/0x80) (gic_handle_irq) from [<80100af0>] (__irq_svc+0x70/0x98) Exception stack(0x8459fe80 to 0x8459fec8) fe80: 72286b00 e3359f64 00000001 0000412d a0070013 85c98840 85c98840 a0070013 fea0: 8054e0d4 00000000 00000002 00000000 00000002 8459fed0 8081fbe8 8081fbec fec0: 60070013 ffffffff (__irq_svc) from [<8081fbec>] (_raw_spin_unlock_irqrestore+0x30/0x58) (_raw_spin_unlock_irqrestore) from [<8056cb48>] (uart_flush_buffer+0x88/0xf8) (uart_flush_buffer) from [<80554e60>] (tty_ldisc_hangup+0x38/0x1ac) (tty_ldisc_hangup) from [<8054c7f4>] (__tty_hangup+0x158/0x2bc) (__tty_hangup) from [<80557b90>] (disassociate_ctty.part.1+0x30/0x23c) (disassociate_ctty.part.1) from [<8011fc18>] (do_exit+0x580/0xba0) (do_exit) from [<801214f8>] (do_group_exit+0x3c/0xb4) (do_group_exit) from [<80121580>] (__wake_up_parent+0x0/0x14) Issue looks like race condition between interrupt handler fsl_edma_tx_handler() (called as result of fsl_edma_xfer_desc()) and terminating the transfer with fsl_edma_terminate_all(). The fsl_edma_tx_handler() handles interrupt for a transfer with already freed edesc and idle==true. Fixes: d6be34fb ("dma: Add Freescale eDMA engine driver support") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Robin Gong <yibin.gong@nxp.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1591877861-28156-2-git-send-email-krzk@kernel.orgSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Vishwas M authored
commit 14b0e83d upstream. This patch fixes a bug which does not let FAN mode to be changed from sysfs(pwm1_enable). i.e pwm1_enable can not be set to 3, it will always remain at 0. This is caused because the device driver handles the result of "read_u8_from_i2c(client, REG_FAN_CONF1, &conf_reg)" incorrectly. The driver thinks an error has occurred if the (result != 0). This has been fixed by changing the condition to (result < 0). Signed-off-by:
Vishwas M <vishwas.reddy.vr@gmail.com> Link: https://lore.kernel.org/r/20200707142747.118414-1-vishwas.reddy.vr@gmail.com Fixes: 9df7305b ("hwmon: Add driver for SMSC EMC2103 temperature monitor and fan controller") Cc: stable@vger.kernel.org Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Huacai Chen authored
Commit ed26aacf ("mips: Add udelay lpj numbers adjustment") has backported to 4.4~5.4, but the "struct cpufreq_freqs" (and also the cpufreq notifier machanism) of 4.4~4.19 are different from the upstream kernel. These differences cause build errors, and this patch can fix the build. Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Stable <stable@vger.kernel.org> # 4.4/4.9/4.14/4.19 Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
-
Frederic Weisbecker authored
commit e2a71bde upstream. When an expiration delta falls into the last level of the wheel, that delta has be compared against the maximum possible delay and reduced to fit in if necessary. However instead of comparing the delta against the maximum, the code compares the actual expiry against the maximum. Then instead of fixing the delta to fit in, it sets the maximum delta as the expiry value. This can result in various undesired outcomes, the worst possible one being a timer expiring 15 days ahead to fire immediately. Fixes: 500462a9 ("timers: Switch to a non-cascading wheel") Signed-off-by:
Frederic Weisbecker <frederic@kernel.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200717140551.29076-2-frederic@kernel.orgSigned-off-by:
-
Esben Haabendal authored
commit bf12fdf0 upstream. While e3a3c3a2 ("UIO: fix uio_pdrv_genirq with device tree but no interrupt") added support for using uio_pdrv_genirq for devices without interrupt for device tree platforms, the removal of uio_pdrv in 26dac3c4 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") broke the support for non device tree platforms. This change fixes this, so that uio_pdrv_genirq can be used without interrupt on all platforms. This still leaves the support that uio_pdrv had for custom interrupt handler lacking, as uio_pdrv_genirq does not handle it (yet). Fixes: 26dac3c4 ("uio: Remove uio_pdrv and use uio_pdrv_genirq instead") Signed-off-by:
Esben Haabendal <esben@geanix.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200701145659.3978-3-esben@geanix.comSigned-off-by:
-
David Pedersen authored
commit 17d51429 upstream. This fixes two finger trackpad scroll on the Lenovo XiaoXin Air 12. Without nomux, the trackpad behaves as if only one finger is present and moves the cursor when trying to scroll. Signed-off-by:
David Pedersen <limero1337@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200625133754.291325-1-limero1337@gmail.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Alexander Usyskin authored
commit e852c2c2 upstream. It's not needed to set driver to NULL in mei_cl_device_remove() which is bus_type remove() handler as this is done anyway in __device_release_driver(). Actually this is causing an endless loop in driver_detach() on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty. as the check is always true in __device_release_driver() if (dev->driver != drv) return; The non upstream patch is causing this behavior, titled: 'vfio -- release device lock before userspace requests' Nevertheless the fix is correct also for the upstream. Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-apw@canonical.com/ Cc: <stable@vger.kernel.org> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20200628225359.2185929-1-tomas.winkler@intel.comSigned-off-by:
-
Chirantan Ekbote authored
commit 31070f6c upstream. The ioctl encoding for this parameter is a long but the documentation says it should be an int and the kernel drivers expect it to be an int. If the fuse driver treats this as a long it might end up scribbling over the stack of a userspace process that only allocated enough space for an int. This was previously discussed in [1] and a patch for fuse was proposed in [2]. From what I can tell the patch in [2] was nacked in favor of adding new, "fixed" ioctls and using those from userspace. However there is still no "fixed" version of these ioctls and the fact is that it's sometimes infeasible to change all userspace to use the new one. Handling the ioctls specially in the fuse driver seems like the most pragmatic way for fuse servers to support them without causing crashes in userspace applications that call them. [1]: https://lore.kernel.org/linux-fsdevel/20131126200559.GH20559@hall.aurel32.net/T/ [2]: https://sourceforge.net/p/fuse/mailman/message/31771759/Signed-off-by:
Chirantan Ekbote <chirantan@chromium.org> Fixes: 59efec7b ("fuse: implement ioctl support") Cc: <stable@vger.kernel.org> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Alexander Lobakin authored
commit 897c44f0 upstream. rproc_serial_id_table lacks an exposure to module devicetable, so when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent is generated and no module autoloading occurs. Add missing MODULE_DEVICE_TABLE() annotation and move the existing one for VIRTIO_ID_CONSOLE right to the table itself. Fixes: 1b637046 ("virtio_console: Add support for remoteproc serial") Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Reviewed-by:
Amit Shah <amit@kernel.org> Link: https://lore.kernel.org/r/x7C_CbeJtoGMy258nwAXASYz3xgFMFpyzmUvOyZzRnQrgWCREBjaqBOpAUS7ol4NnZYvSVwmTsCG0Ohyfvta-ygw6HMHcoeKK0C3QFiAO_Q=@pm.meSigned-off-by:
-
AceLan Kao authored
commit da6902e5 upstream. Add support for Quectel Wireless Solutions Co., Ltd. EG95 LTE modem T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0195 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Jörgen Storvist authored
commit 08d4ef5c upstream. Add USB IDs for GosunCn GM500 series cellular modules. RNDIS config: usb-devices T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=305a ProdID=1404 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option MBIM config: usb-devices T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=305a ProdID=1405 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim ECM config: usb-devices T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 13 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=305a ProdID=1406 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber= C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Signed-off-by:
Jörgen Storvist <jorgen.storvist@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Igor Moura authored
commit 5d0136f8 upstream. Add PID for CH340 that's found on some ESP8266 dev boards made by LilyGO. The specific device that contains such serial converter can be seen here: https://github.com/LilyGO/LILYGO-T-OI. Apparently, it's a regular CH340, but I've confirmed with others that also bought this board that the PID found on this device (0x7522) differs from other devices with the "same" converter (0x7523). Simply adding its PID to the driver and rebuilding it made it work as expected. Signed-off-by:
Igor Moura <imphilippini@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
James Hilliard authored
commit 5c45d04c upstream. This is a UPB (Universal Powerline Bus) PIM (Powerline Interface Module) which allows for controlling multiple UPB compatible devices from Linux using the standard serial interface. Based on vendor application source code there are two different models of USB based PIM devices in addition to a number of RS232 based PIM's. The vendor UPB application source contains the following USB ID's: #define USB_PCS_VENDOR_ID 0x04b4 #define USB_PCS_PIM_PRODUCT_ID 0x5500 #define USB_SAI_VENDOR_ID 0x17dd #define USB_SAI_PIM_PRODUCT_ID 0x5500 The first set of ID's correspond to the PIM variant sold by Powerline Control Systems while the second corresponds to the Simply Automated Incorporated PIM. As the product ID for both of these match the default cypress HID->COM RS232 product ID it assumed that they both use an internal variant of this HID->COM RS232 converter hardware. However as the vendor ID for the Simply Automated variant is different we need to also add it to the cypress_M8 driver so that it is properly detected. Signed-off-by:
James Hilliard <james.hilliard1@gmail.com> Link: https://lore.kernel.org/r/20200616220403.1807003-1-james.hilliard1@gmail.com Cc: stable@vger.kernel.org [ johan: amend VID define entry ] Signed-off-by:
-
Johan Hovold authored
commit e7b931be upstream. The driver would happily overwrite its write buffer with user data in 256 byte increments due to a removed buffer-space sanity check. Fixes: 5fcf62b0 ("tty: iuu_phoenix: fix locking.") Cc: stable <stable@vger.kernel.org> # 2.6.31 Signed-off-by:
-
Zhang Qiang authored
commit 8778eb09 upstream. Add a missing spinlock protection for play_queue, because the play_queue may be destroyed when the "playback_work" work func and "f_audio_out_ep_complete" callback func operate this paly_queue at the same time. Fixes: c6994e6f ("USB: gadget: add USB Audio Gadget driver") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Zhang Qiang <qiang.zhang@windriver.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Peter Chen authored
commit 876d4e1e upstream. If wakeup event occurred by extcon event, it needs to call ci_irq again since the first ci_irq calling at extcon notifier only wakes up controller, but do noop for event handling, it causes the extcon use case can't work well from low power mode. Cc: <stable@vger.kernel.org> Fixes: 3ecb3e09 ("usb: chipidea: Use extcon framework for VBUS and ID detect") Reported-by:
Philippe Schenker <philippe.schenker@toradex.com> Tested-by:
Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20200707060601.31907-2-peter.chen@kernel.orgSigned-off-by:
-
Minas Harutyunyan authored
commit 4fdf228c upstream. To avoid lot of interrupts from dwc2 core, which can be asserted in specific conditions need to disable interrupts on HW level instead of disable IRQs on Kernel level, because of IRQ can be shared between drivers. Cc: stable@vger.kernel.org Fixes: a40a0031 ("usb: dwc2: add shutdown callback to platform variant") Tested-by:
Frank Mori Hess <fmh6jj@gmail.com> Reviewed-by:
Alan Stern <stern@rowland.harvard.edu> Reviewed-by:
Doug Anderson <dianders@chromium.org> Reviewed-by:
Minas Harutyunyan <hminas@synopsys.com> Signed-off-by:
-
Tom Rix authored
commit 211f0834 upstream. clang static analysis flags this error c67x00-sched.c:489:55: warning: Use of memory after it is freed [unix.Malloc] usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status); ^~~~~~~~~~~~ Problem happens in this block of code c67x00_release_urb(c67x00, urb); usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00), urb); spin_unlock(&c67x00->lock); usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb, urbp->status); In the call to c67x00_release_urb has this freeing of urbp urbp = urb->hcpriv; urb->hcpriv = NULL; list_del(&urbp->hep_node); kfree(urbp); And so urbp is freed before usb_hcd_giveback_urb uses it as its 3rd parameter. Since all is required is the status, pass the status directly as is done in c64x00_urb_dequeue Fixes: e9b29ffc ("USB: add Cypress c67x00 OTG controller HCD driver") Signed-off-by:
-
Takashi Iwai authored
commit 9b7e5208 upstream. USB MIDI driver has an error recovery mechanism to resubmit the URB in the delayed timer handler, and this may race with the standard start / stop operations. Although both start and stop operations themselves don't race with each other due to the umidi->mutex protection, but this isn't applied to the timer handler. For fixing this potential race, the following changes are applied: - Since the timer handler can't use the mutex, we apply the umidi->disc_lock protection at each input stream URB submission; this also needs to change the GFP flag to GFP_ATOMIC - Add a check of the URB refcount and skip if already submitted - Move the timer cancel call at disconnection to the beginning of the procedure; this assures the in-flight timer handler is gone properly before killing all pending URBs Reported-by: syzbot+0f4ecfe6a2c322c81728@syzkaller.appspotmail.com Reported-by: syzbot+5f1d24c49c1d2c427497@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200710160656.16819-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 6e8a914a upstream. LINE6 drivers create stream URBs with a fixed pipe without checking its validity, and this may lead to a kernel WARNING at the submission when a malformed USB descriptor is passed. For avoiding the kernel warning, perform the similar sanity checks for each pipe type at creating a URB. Reported-by: syzbot+c190f6858a04ea7fbc52@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/s5hv9iv4hq8.wl-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
commit e901b987 upstream. This patch adds a new helper function to perform a sanity check of the given URB to see whether it contains a valid endpoint. It's a light- weight version of what usb_submit_urb() does, but without the kernel warning followed by the stack trace, just returns an error code. Especially for a driver that doesn't parse the descriptor but fills the URB with the fixed endpoint (e.g. some quirks for non-compliant devices), this kind of check is preferable at the probe phase before actually submitting the urb. Tested-by:
Andrey Konovalov <andreyknvl@google.com> Acked-by:
-
Dmitry Torokhov authored
commit 6363d206 upstream. Neither the trackpad, nor the mouse want input core to generate autorepeat events for their buttons, so let's reset the bit (as hid-input sets it for these devices based on the usage vendor code). Cc: stable@vger.kernel.org Reported-by:
Yariv <oigevald+kernel@gmail.com> Tested-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Álvaro Fernández Rojas authored
commit 3d3fb3c5 upstream. Only v3.3-v5.0 have a different CS0 layout. Controllers before v3.3 use the same layout for every CS. Fixes: 27c5b17c ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20200522121524.4161539-3-noltari@gmail.comSigned-off-by:
-
Jin Yao authored
commit 0e0bf1ea upstream. As the code comments in perf_stat_process_counter() say, we calculate counter's data every interval, and the display code shows ps->res_stats avg value. We need to zero the stats for interval mode. But the current code only zeros the res_stats[0], it doesn't zero the res_stats[1] and res_stats[2], which are for ena and run of counter. This patch zeros the whole res_stats[] for interval mode. Fixes: 51fd2df1 ("perf stat: Fix interval output values") Signed-off-by:
Jin Yao <yao.jin@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jin Yao <yao.jin@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20200409070755.17261-1-yao.jin@linux.intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit d7adfe5f ] Fix dtschema validator warnings like: l2-cache@fffff000: $nodename:0: 'l2-cache@fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$' Fixes: 475dc86d ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC") Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
