summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-23Linux 5.15.70v5.15.70Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20220921153646.931277075@linuxfoundation.org Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23ALSA: hda/sigmatel: Fix unused variable warning for beep power changeTakashi Iwai1-0/+2
commit 51bdc8bb82525cd70feb92279c8b7660ad7948dd upstream. The newly added stac_check_power_status() caused a compile warning when CONFIG_SND_HDA_INPUT_BEEP is disabled. Fix it. Fixes: 414d38ba8710 ("ALSA: hda/sigmatel: Keep power up while beep is enabled") Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20220905130630.2845-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()Tetsuo Handa1-0/+2
commit 43626dade36fa74d3329046f4ae2d7fdefe401c6 upstream. syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that cpuset_attach() is also called from cgroup_attach_task_all(). Add cpus_read_lock() like what cgroup_procs_write_start() does. Link: https://syzkaller.appspot.com/bug?extid=29d3a3b4d86c8136ad9e [1] Reported-by: syzbot <syzbot+29d3a3b4d86c8136ad9e@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 4f7e7236435ca0ab ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock") Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23KVM: SEV: add cache flush to solve SEV cache incoherency issuesMingwei Zhang8-3/+44
commit 683412ccf61294d727ead4a73d97397396e69a6b upstream. Flush the CPU caches when memory is reclaimed from an SEV guest (where reclaim also includes it being unmapped from KVM's memslots). Due to lack of coherency for SEV encrypted memory, failure to flush results in silent data corruption if userspace is malicious/broken and doesn't ensure SEV guest memory is properly pinned and unpinned. Cache coherency is not enforced across the VM boundary in SEV (AMD APM vol.2 Section 15.34.7). Confidential cachelines, generated by confidential VM guests have to be explicitly flushed on the host side. If a memory page containing dirty confidential cachelines was released by VM and reallocated to another user, the cachelines may corrupt the new user at a later time. KVM takes a shortcut by assuming all confidential memory remain pinned until the end of VM lifetime. Therefore, KVM does not flush cache at mmu_notifier invalidation events. Because of this incorrect assumption and the lack of cache flushing, malicous userspace can crash the host kernel: creating a malicious VM and continuously allocates/releases unpinned confidential memory pages when the VM is running. Add cache flush operations to mmu_notifier operations to ensure that any physical memory leaving the guest VM get flushed. In particular, hook mmu_notifier_invalidate_range_start and mmu_notifier_release events and flush cache accordingly. The hook after releasing the mmu lock to avoid contention with other vCPUs. Cc: stable@vger.kernel.org Suggested-by: Sean Christpherson <seanjc@google.com> Reported-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Mingwei Zhang <mizhang@google.com> Message-Id: <20220421031407.2516575-4-mizhang@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [OP: adjusted KVM_X86_OP_OPTIONAL() -> KVM_X86_OP_NULL, applied kvm_arch_guest_memory_reclaimed() call in kvm_set_memslot()] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23net: Find dst with sk's xfrm policy not ctl_sksewookseo4-2/+9
commit e22aa14866684f77b4f6b6cae98539e520ddb731 upstream. If we set XFRM security policy by calling setsockopt with option IPV6_XFRM_POLICY, the policy will be stored in 'sock_policy' in 'sock' struct. However tcp_v6_send_response doesn't look up dst_entry with the actual socket but looks up with tcp control socket. This may cause a problem that a RST packet is sent without ESP encryption & peer's TCP socket can't receive it. This patch will make the function look up dest_entry with actual socket, if the socket has XFRM policy(sock_policy), so that the TCP response packet via this function can be encrypted, & aligned on the encrypted TCP socket. Tested: We encountered this problem when a TCP socket which is encrypted in ESP transport mode encryption, receives challenge ACK at SYN_SENT state. After receiving challenge ACK, TCP needs to send RST to establish the socket at next SYN try. But the RST was not encrypted & peer TCP socket still remains on ESTABLISHED state. So we verified this with test step as below. [Test step] 1. Making a TCP state mismatch between client(IDLE) & server(ESTABLISHED). 2. Client tries a new connection on the same TCP ports(src & dst). 3. Server will return challenge ACK instead of SYN,ACK. 4. Client will send RST to server to clear the SOCKET. 5. Client will retransmit SYN to server on the same TCP ports. [Expected result] The TCP connection should be established. Cc: Maciej Żenczykowski <maze@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Sehee Lee <seheele@google.com> Signed-off-by: Sewook Seo <sewookseo@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23video: fbdev: pxa3xx-gcu: Fix integer overflow in pxa3xx_gcu_writeHyunwoo Kim1-1/+1
[ Upstream commit a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7 ] In pxa3xx_gcu_write, a count parameter of type size_t is passed to words of type int. Then, copy_from_user() may cause a heap overflow because it is used as the third argument of copy_from_user(). Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23mksysmap: Fix the mismatch of 'L0' symbols in System.mapYouling Tang1-1/+1
[ Upstream commit c17a2538704f926ee4d167ba625e09b1040d8439 ] When System.map was generated, the kernel used mksysmap to filter the kernel symbols, we need to filter "L0" symbols in LoongArch architecture. $ cat System.map | grep L0 9000000000221540 t L0 The L0 symbol exists in System.map, but not in .tmp_System.map. When "cmp -s System.map .tmp_System.map" will show "Inconsistent kallsyms data" error message in link-vmlinux.sh script. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23drm/panfrost: devfreq: set opp to the recommended one to configure regulatorClément Péron1-0/+11
[ Upstream commit d76034a427a2660b080bc155e4fd8f6393eefb48 ] Enabling panfrost GPU OPP with dynamic regulator will make OPP responsible to enable and configure it. Unfortunately OPP configure and enable the regulator when an OPP is asked to be set, which is not the case during panfrost_devfreq_init(). This leave the regulator unconfigured and if no GPU load is triggered, no OPP is asked to be set which make the regulator framework switching it off during regulator_late_cleanup() without noticing and therefore make the board hang as any access to GPU memory space make bus locks up. Call dev_pm_opp_set_opp() with the recommend OPP in panfrost_devfreq_init() to enable the regulator, this will properly configure and enable the regulator and will avoid any switch off by regulator_late_cleanup(). Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Clément Péron <peron.clem@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906153034.153321-5-peron.clem@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23MIPS: OCTEON: irq: Fix octeon_irq_force_ciu_mapping()Alexander Sverdlin1-0/+10
[ Upstream commit ba912afbd611d3a5f22af247721a071ad1d5b9e0 ] For irq_domain_associate() to work the virq descriptor has to be pre-allocated in advance. Otherwise the following happens: WARNING: CPU: 0 PID: 0 at .../kernel/irq/irqdomain.c:527 irq_domain_associate+0x298/0x2e8 error: virq128 is not allocated Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.78-... #1 ... Call Trace: [<ffffffff801344c4>] show_stack+0x9c/0x130 [<ffffffff80769550>] dump_stack+0x90/0xd0 [<ffffffff801576d0>] __warn+0x118/0x130 [<ffffffff80157734>] warn_slowpath_fmt+0x4c/0x70 [<ffffffff801b83c0>] irq_domain_associate+0x298/0x2e8 [<ffffffff80a43bb8>] octeon_irq_init_ciu+0x4c8/0x53c [<ffffffff80a76cbc>] of_irq_init+0x1e0/0x388 [<ffffffff80a452cc>] init_IRQ+0x4c/0xf4 [<ffffffff80a3cc00>] start_kernel+0x404/0x698 Use irq_alloc_desc_at() to avoid the above problem. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23afs: Return -EAGAIN, not -EREMOTEIO, when a file already lockedDavid Howells1-0/+1
[ Upstream commit 0066f1b0e27556381402db3ff31f85d2a2265858 ] When trying to get a file lock on an AFS file, the server may return UAEAGAIN to indicate that the lock is already held. This is currently translated by the default path to -EREMOTEIO. Translate it instead to -EAGAIN so that we know we can retry it. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeffrey E Altman <jaltman@auristor.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/166075761334.3533338.2591992675160918098.stgit@warthog.procyon.org.uk/ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23net: usb: qmi_wwan: add Quectel RM520Njerry.meng1-0/+1
[ Upstream commit e1091e226a2bab4ded1fe26efba2aee1aab06450 ] add support for Quectel RM520N which is based on Qualcomm SDX62 chip. 0x0801: DIAG + NMEA + AT + MODEM + RMNET T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0801 Rev= 5.04 S: Manufacturer=Quectel S: Product=RM520N-GL S: SerialNumber=384af524 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: jerry.meng <jerry-meng@foxmail.com> Acked-by: Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/tencent_E50CA8A206904897C2D20DDAE90731183C05@qq.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23ALSA: hda/tegra: Align BDL entry to 4KB boundaryMohan Kumar1-1/+2
[ Upstream commit 8d44e6044a0e885acdd01813768a0b27906d64fd ] AZA HW may send a burst read/write request crossing 4K memory boundary. The 4KB boundary is not guaranteed by Tegra HDA HW. Make SW change to include the flag AZX_DCAPS_4K_BDLE_BOUNDARY to align BDLE to 4K boundary. Signed-off-by: Mohan Kumar <mkumard@nvidia.com> Link: https://lore.kernel.org/r/20220905172420.3801-1-mkumard@nvidia.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23ALSA: hda/sigmatel: Keep power up while beep is enabledTakashi Iwai1-0/+22
[ Upstream commit 414d38ba871092aeac4ed097ac4ced89486646f7 ] It seems that the beep playback doesn't work well on IDT codec devices when the codec auto-pm is enabled. Keep the power on while the beep switch is enabled. Link: https://bugzilla.suse.com/show_bug.cgi?id=1200544 Link: https://lore.kernel.org/r/20220904072750.26164-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23wifi: mac80211_hwsim: check length for virtio packetsSoenke Huster1-1/+6
[ Upstream commit 8c0427842aaef161a38ac83b7e8d8fe050b4be04 ] An invalid packet with a length shorter than the specified length in the netlink header can lead to use-after-frees and slab-out-of-bounds in the processing of the netlink attributes, such as the following: BUG: KASAN: slab-out-of-bounds in __nla_validate_parse+0x1258/0x2010 Read of size 2 at addr ffff88800ac7952c by task kworker/0:1/12 Workqueue: events hwsim_virtio_rx_work Call Trace: <TASK> dump_stack_lvl+0x45/0x5d print_report.cold+0x5e/0x5e5 kasan_report+0xb1/0x1c0 __nla_validate_parse+0x1258/0x2010 __nla_parse+0x22/0x30 hwsim_virtio_handle_cmd.isra.0+0x13f/0x2d0 hwsim_virtio_rx_work+0x1b2/0x370 process_one_work+0x8df/0x1530 worker_thread+0x575/0x11a0 kthread+0x29d/0x340 ret_from_fork+0x22/0x30 </TASK> Discarding packets with an invalid length solves this. Therefore, skb->len must be set at reception. Change-Id: Ieaeb9a4c62d3beede274881a7c2722c6c6f477b6 Signed-off-by: Soenke Huster <soenke.huster@eknoes.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23rxrpc: Fix calc of resend ageDavid Howells1-1/+1
[ Upstream commit 214a9dc7d852216e83acac7b75bc18f01ce184c2 ] Fix the calculation of the resend age to add a microsecond value as microseconds, not nanoseconds. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23rxrpc: Fix local destruction being repeatedDavid Howells1-0/+3
[ Upstream commit d3d863036d688313f8d566b87acd7d99daf82749 ] If the local processor work item for the rxrpc local endpoint gets requeued by an event (such as an incoming packet) between it getting scheduled for destruction and the UDP socket being closed, the rxrpc_local_destroyer() function can get run twice. The second time it can hang because it can end up waiting for cleanup events that will never happen. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23scsi: lpfc: Return DID_TRANSPORT_DISRUPTED instead of DID_REQUEUEHannes Reinecke1-2/+2
[ Upstream commit c0a50cd389c3ed54831e240023dd12bafa56b3a6 ] When the driver hits an internal error condition returning DID_REQUEUE the I/O will be retried on the same ITL nexus. This will inhibit multipathing, resulting in endless retries even if the error could have been resolved by using a different ITL nexus. Return DID_TRANSPORT_DISRUPTED to allow for multipath to engage and route I/O to another ITL nexus. Link: https://lore.kernel.org/r/20220824060033.138661-1-hare@suse.de Reviewed-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23regulator: pfuze100: Fix the global-out-of-bounds access in ↵Xiaolei Wang1-1/+1
pfuze100_regulator_probe() [ Upstream commit 78e1e867f44e6bdc72c0e6a2609a3407642fb30b ] The pfuze_chip::regulator_descs is an array of size PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators is the pointer to the real regulators of a specific device. The number of real regulator is supposed to be less than the PFUZE100_MAX_REGULATOR, so we should use the size of 'regulator_num * sizeof(struct pfuze_regulator)' in memcpy(). This fixes the out of bounds access bug reported by KASAN. Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Link: https://lore.kernel.org/r/20220825111922.1368055-1-xiaolei.wang@windriver.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23ASoC: nau8824: Fix semaphore unbalance at error pathsTakashi Iwai1-7/+10
[ Upstream commit 5628560e90395d3812800a8e44a01c32ffa429ec ] The semaphore of nau8824 wasn't properly unlocked at some error handling code paths, hence this may result in the unbalance (and potential lock-up). Fix them to handle the semaphore up properly. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20220823081000.2965-3-tiwai@suse.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23arm64: dts: juno: Add missing MHU secure-irqJassi Brar1-1/+2
[ Upstream commit 422ab8fe15e30066d4c8e236b747c77069bfca45 ] The MHU secure interrupt exists physically but is missing in the DT node. Specify the interrupt in DT node to fix a warning on Arm Juno board: mhu@2b1f0000: interrupts: [[0, 36, 4], [0, 35, 4]] is too short Link: https://lore.kernel.org/r/20220801141005.599258-1-jassisinghbrar@gmail.com Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23video: fbdev: i740fb: Error out if 'pixclock' equals zeroZheyu Ma1-0/+3
commit 15cf0b82271b1823fb02ab8c377badba614d95d5 upstream. The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero in the function i740fb_check_var(). The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:444 [inline] RIP: 0010:i740fb_set_par+0x272f/0x3bb0 drivers/video/fbdev/i740fb.c:739 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1036 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1112 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1191 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Stefan Ghinea <stefan.ghinea@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23binder: remove inaccurate mmap_assert_locked()Carlos Llamas1-7/+0
Acquiring the mmap_lock during exit_mmap() was only added recently in v5.17 by commit 64591e8605d6 ("mm: protect free_pgtables with mmap_lock write lock in exit_mmap"). Soon after, asserts for holding this lock were added to the binder_alloc_set_vma() callback by the following two fix commits in mainline: commit b0cab80ecd54 ("android: binder: fix lockdep check on clearing vma") and commit a43cfc87caaf ("android: binder: stop saving a pointer to the VMA"). These two fix commits were picked for stable trees including v5.15 were unfortunately the mmap_lock is not held during exit_mmap() yet and this unmet dependency leads to the following BUG report: ------------[ cut here ]------------ kernel BUG at include/linux/mmap_lock.h:156! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 3 PID: 437 Comm: binder Not tainted 5.15.68 #5 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : binder_alloc_vma_close+0x6c/0x70 lr : binder_alloc_vma_close+0x6c/0x70 sp : ffff800008687a70 x29: ffff800008687a70 x28: ffff02a7ccf89d00 x27: ffff02a7c92f99e8 x26: 000000000000012a x25: ffff02a7c6284740 x24: ffff02a7ccf8a360 x23: ffff02a7c92f9980 x22: 1ffff000010d0f6c x21: ffff02a7c92f99e8 x20: ffff02a7c92f9980 x19: ffff02a7d16b79a8 x18: 0000ffffe1702d20 x17: 3334373239343932 x16: 34206e6163735f74 x15: 78656e5f616d756e x14: 0a30303030303030 x13: 7366666f5f6e6163 x12: ffff60550564a12b x11: 1fffe0550564a12a x10: ffff60550564a12a x9 : dfff800000000000 x8 : ffff02a82b250957 x7 : 0000000000000001 x6 : ffff60550564a12a x5 : ffff02a82b250950 x4 : dfff800000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff02a7ccf89d00 x0 : 0000000000000374 Call trace: binder_alloc_vma_close+0x6c/0x70 binder_vma_close+0x38/0xf4 remove_vma+0x4c/0x94 exit_mmap+0x14c/0x2bc __mmput+0x70/0x19c mmput+0x68/0x80 do_exit+0x484/0xeb0 do_group_exit+0x5c/0x100 [...] This patch removes the inaccurate assert specifically from v5.15 since it's the only release with such issue. Note the mmap_lock is technically not needed here as the mm->mm_users has dropped to zero at this point. More context: https://lore.kernel.org/all/YxpQaio7xm3z9TUw@google.com/. Fixes: b0cab80ecd54 ("android: binder: fix lockdep check on clearing vma") Fixes: a43cfc87caaf ("android: binder: stop saving a pointer to the VMA") Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: <stable@vger.kernel.org> # v5.15 Signed-off-by: Carlos Llamas <cmllamas@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vegaAlex Deucher2-22/+5
commit e3163bc8ffdfdb405e10530b140135b2ee487f89 upstream. This mirrors what we do for other asics and this way we are sure the sdma doorbell range is properly initialized. There is a comment about the way doorbells on gfx9 work that requires that they are initialized for other IPs before GFX is initialized. However, the statement says that it applies to multimedia as well, but the VCN code currently initializes doorbells after GFX and there are no known issues there. In my testing at least I don't see any problems on SDMA. This is a prerequisite for fixing the Unsupported Request error reported through AER during driver load. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216373 The error was unnoticed before and got visible because of the commit referenced below. This doesn't fix anything in the commit below, rather fixes the issue in amdgpu exposed by the commit. The reference is only to associate this commit with below one so that both go together. Fixes: 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()") Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23drm/amdgpu: move nbio ih_doorbell_range() into ih code for vegaAlex Deucher3-3/+8
commit dc1d85cb790f2091eea074cee24a704b2d6c4a06 upstream. This mirrors what we do for other asics and this way we are sure the ih doorbell range is properly initialized. There is a comment about the way doorbells on gfx9 work that requires that they are initialized for other IPs before GFX is initialized. In this case IH is initialized before GFX, so there should be no issue. This is a prerequisite for fixing the Unsupported Request error reported through AER during driver load. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216373 The error was unnoticed before and got visible because of the commit referenced below. This doesn't fix anything in the commit below, rather fixes the issue in amdgpu exposed by the commit. The reference is only to associate this commit with below one so that both go together. Fixes: 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()") Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23drm/amdgpu: Don't enable LTR if not supportedLijo Lazar3-3/+24
commit 6c20490663553cd7e07d8de8af482012329ab9d6 upstream. As per PCIE Base Spec r4.0 Section 6.18 'Software must not enable LTR in an Endpoint unless the Root Complex and all intermediate Switches indicate support for LTR.' This fixes the Unsupported Request error reported through AER during ASPM enablement. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216455 The error was unnoticed before and got visible because of the commit referenced below. This doesn't fix anything in the commit below, rather fixes the issue in amdgpu exposed by the commit. The reference is only to associate this commit with below one so that both go together. Fixes: 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()") Reported-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-23tools/include/uapi: Fix <asm/errno.h> for parisc and xtensaBen Hutchings1-2/+2
commit 95363747a6f39e88a3052fcf6ce6237769495ce0 upstream. tools/include/uapi/asm/errno.h currently attempts to include non-existent arch-specific errno.h header for xtensa. Remove this case so that <asm-generic/errno.h> is used instead, and add the missing arch-specific header for parisc. References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ia64&ver=5.8.3-1%7Eexp1&stamp=1598340829&raw=1 Signed-off-by: Ben Hutchings <benh@debian.org> Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Cc: <stable@vger.kernel.org> # 5.10+ Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23parisc: Allow CONFIG_64BIT with ARCH=pariscHelge Deller1-1/+11
commit 805ce8614958c925877ba6b6dc26cdf9f8800474 upstream. The previous patch triggered a build failure for the debian kernel, which has CONFIG_64BIT enabled, uses the CROSS_COMPILER environment variable and uses ARCH=parisc to configure the kernel for 64-bit support. This patch weakens the previous patch while keeping the recommended way to configure the kernel with: ARCH=parisc -> build 32-bit kernel ARCH=parisc64 -> build 64-bit kernel while adding the possibility for debian to configure a 64-bit kernel even if ARCH=parisc is set (PA8X00 CPU has to be selected and CONFIG_64BIT needs to be enabled). The downside of this patch is, that we now have a small window open again where people may get it wrong: if they enable CONFIG_64BIT and try to compile with a 32-bit compiler. Fixes: 3dcfb729b5f4 ("parisc: Make CONFIG_64BIT available for ARCH=parisc64 only") Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # 5.15+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23cifs: always initialize struct msghdr smb_msg completelyStefan Metzmacher2-13/+4
commit bedc8f76b3539ac4f952114b316bcc2251e808ce upstream. So far we were just lucky because the uninitialized members of struct msghdr are not used by default on a SOCK_STREAM tcp socket. But as new things like msg_ubuf and sg_from_iter where added recently, we should play on the safe side and avoid potention problems in future. Signed-off-by: Stefan Metzmacher <metze@samba.org> Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23cifs: don't send down the destination address to sendmsg for a SOCK_STREAMStefan Metzmacher1-2/+2
commit 17d3df38dc5f4cec9b0ac6eb79c1859b6e2693a4 upstream. This is ignored anyway by the tcp layer. Signed-off-by: Stefan Metzmacher <metze@samba.org> Cc: stable@vger.kernel.org Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23cifs: revalidate mapping when doing direct writesRonnie Sahlberg1-0/+3
commit 7500a99281dfed2d4a84771c933bcb9e17af279b upstream. Kernel bugzilla: 216301 When doing direct writes we need to also invalidate the mapping in case we have a cached copy of the affected page(s) in memory or else subsequent reads of the data might return the old/stale content before we wrote an update to the server. Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23of/device: Fix up of_dma_configure_id() stubThierry Reding1-2/+3
commit 40bfe7a86d84cf08ac6a8fe2f0c8bf7a43edd110 upstream. Since the stub version of of_dma_configure_id() was added in commit a081bd4af4ce ("of/device: Add input id to of_dma_configure()"), it has not matched the signature of the full function, leading to build failure reports when code using this function is built on !OF configurations. Fixes: a081bd4af4ce ("of/device: Add input id to of_dma_configure()") Cc: stable@vger.kernel.org Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://lore.kernel.org/r/20220824153256.1437483-1-thierry.reding@gmail.com Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-23parisc: ccio-dma: Add missing iounmap in error path in ccio_probe()Yang Yingliang1-0/+1
[ Upstream commit 38238be4e881a5d0abbe4872b4cd6ed790be06c8 ] Add missing iounmap() before return from ccio_probe(), if ccio_init_resources() fails. Fixes: d46c742f827f ("parisc: ccio-dma: Handle kmalloc failure in ccio_init_resources()") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23block: blk_queue_enter() / __bio_queue_enter() must return -EAGAIN for nowaitStefan Roesch1-2/+2
[ Upstream commit 56f99b8d06ef1ed1c9730948f9f05ac2b930a20b ] Today blk_queue_enter() and __bio_queue_enter() return -EBUSY for the nowait code path. This is not correct: they should return -EAGAIN instead. This problem was detected by fio. The following command exposed the above problem: t/io_uring -p0 -d128 -b4096 -s32 -c32 -F1 -B0 -R0 -X1 -n24 -P1 -u1 -O0 /dev/ng0n1 By applying the patch, the retry case is handled correctly in the slow path. Signed-off-by: Stefan Roesch <shr@fb.com> Fixes: bfd343aa1718 ("blk-mq: don't wait in blk_mq_queue_enter() if __GFP_WAIT isn't set") Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23drm/meson: Fix OSD1 RGB to YCbCr coefficientStuart Menefy1-1/+1
[ Upstream commit 6463d3930ba5b6addcfc8f80a4543976a2fc7656 ] VPP_WRAP_OSD1_MATRIX_COEF22.Coeff22 is documented as being bits 0-12, not 16-28. Without this the output tends to have a pink hue, changing it results in better color accuracy. The vendor kernel doesn't use this register. However the code which sets VIU2_OSD1_MATRIX_COEF22 also uses bits 0-12. There is a slightly different style of registers for configuring some of the other matrices, which do use bits 16-28 for this coefficient, but those have names ending in MATRIX_COEF22_30, and this is not one of those. Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> Fixes: 728883948b0d ("drm/meson: Add G12A Support for VIU setup") Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908155243.687143-1-stuart.menefy@mathembedded.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23drm/meson: Correct OSD1 global alpha valueStuart Menefy1-1/+1
[ Upstream commit 6836829c8ea453c9e3e518e61539e35881c8ed5f ] VIU_OSD1_CTRL_STAT.GLOBAL_ALPHA is a 9 bit field, so the maximum value is 0x100 not 0xff. This matches the vendor kernel. Signed-off-by: Stuart Menefy <stuart.menefy@mathembedded.com> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908155103.686904-1-stuart.menefy@mathembedded.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23gpio: mpc8xxx: Fix support for IRQ_TYPE_LEVEL_LOW flow_type in mpc85xxPali Rohár1-0/+1
[ Upstream commit 279c12df8d2efb28def9d037f288cbfb97c30fe2 ] Commit e39d5ef67804 ("powerpc/5xxx: extend mpc8xxx_gpio driver to support mpc512x gpios") implemented support for IRQ_TYPE_LEVEL_LOW flow type in mpc512x via falling edge type. Do same for mpc85xx which support was added in commit 345e5c8a1cc3 ("powerpc: Add interrupt support to mpc8xxx_gpio"). Fixes probing of lm90 hwmon driver on mpc85xx based board which use level interrupt. Without it kernel prints error and refuse lm90 to work: [ 15.258370] genirq: Setting trigger mode 8 for irq 49 failed (mpc8xxx_irq_set_type+0x0/0xf8) [ 15.267168] lm90 0-004c: cannot request IRQ 49 [ 15.272708] lm90: probe of 0-004c failed with error -22 Fixes: 345e5c8a1cc3 ("powerpc: Add interrupt support to mpc8xxx_gpio") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23NFSv4: Turn off open-by-filehandle and NFS re-export for NFSv4.0Trond Myklebust1-9/+18
[ Upstream commit 2a9d683b48c8a87e61a4215792d44c90bcbbb536 ] The NFSv4.0 protocol only supports open() by name. It cannot therefore be used with open_by_handle() and friends, nor can it be re-exported by knfsd. Reported-by: Chuck Lever III <chuck.lever@oracle.com> Fixes: 20fa19027286 ("nfs: add export operations") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23pinctrl: sunxi: Fix name for A100 R_PIOMichael Wu1-1/+1
[ Upstream commit 76648c867c6c03b8a468d9c9222025873ecc613d ] The name of A100 R_PIO driver should be sun50i-a100-r-pinctrl, not sun50iw10p1-r-pinctrl. Fixes: 473436e7647d6 ("pinctrl: sunxi: add support for the Allwinner A100 pin controller") Signed-off-by: Michael Wu <michael@allwinnertech.com> Acked-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20220819024541.74191-1-michael@allwinnertech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23pinctrl: rockchip: Enhance support for IRQ_TYPE_EDGE_BOTHJoão H. Spies1-2/+2
[ Upstream commit b871656aa4f54e04207f62bdd0d7572be1d86b36 ] Switching between falling/rising edges for IRQ_TYPE_EDGE_BOTH on pins that require debounce can cause the device to lose events due to a desync between pin state and irq type. This problem is resolved by switching between IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH instead. Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Signed-off-by: João H. Spies <jhlspies@gmail.com> Link: https://lore.kernel.org/r/20220808025121.110223-1-jhlspies@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23pinctrl: qcom: sc8180x: Fix wrong pin numbersMolly Sophia1-4/+4
[ Upstream commit 48ec73395887694f13c9452b4dcfb43710451757 ] The pin numbers for UFS_RESET and SDC2_* are not consistent in the pinctrl driver for sc8180x. So fix it. Signed-off-by: Molly Sophia <mollysophia379@gmail.com> Fixes: 97423113ec4b ("pinctrl: qcom: Add sc8180x TLMM driver") Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220807122645.13830-3-mollysophia379@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23pinctrl: qcom: sc8180x: Fix gpio_wakeirq_mapMolly Sophia1-1/+1
[ Upstream commit 6124cec530c7d8faab96d340ab2df5161e5d1c8a ] Currently in the wakeirq_map, gpio36 and gpio37 have the same wakeirq number, resulting in gpio37 being unable to trigger interrupts. It looks like that this is a typo in the wakeirq map. So fix it. Signed-off-by: Molly Sophia <mollysophia379@gmail.com> Fixes: 97423113ec4b ("pinctrl: qcom: Add sc8180x TLMM driver") Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220807122645.13830-2-mollysophia379@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23of: fdt: fix off-by-one error in unflatten_dt_nodes()Sergey Shtylyov1-1/+1
[ Upstream commit 2f945a792f67815abca26fa8a5e863ccf3fa1181 ] Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23tty: serial: atmel: Preserve previous USART mode if RS485 disabledSergiu Moga1-3/+1
[ Upstream commit 692a8ebcfc24f4a5bea0eb2967e450f584193da6 ] Whenever the atmel_rs485_config() driver method would be called, the USART mode is reset to normal mode before even checking if RS485 flag is set, thus resulting in losing the previous USART mode in the case where the checking fails. Some tools, such as `linux-serial-test`, lead to the driver calling this method when doing the setup of the serial port: after setting the port mode (Hardware Flow Control, Normal Mode, RS485 Mode, etc.), `linux-serial-test` tries to enable/disable RS485 depending on the commandline arguments that were passed. Example of how this issue could reveal itself: When doing a serial communication with Hardware Flow Control through `linux-serial-test`, the tool would lead to the driver roughly doing the following: - set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS bit in the ATMEL_US_MR register) through the atmel_set_termios() to enable Hardware Flow Control - disable RS485 through the atmel_config_rs485() method Thus, when the latter is called, the mode will be reset and the previously set bit is unset, leaving USART in normal mode instead of the expected Hardware Flow Control mode. This fix ensures that this reset is only done if the checking for RS485 succeeds and that the previous mode is preserved otherwise. Fixes: e8faff7330a35 ("ARM: 6092/1: atmel_serial: support for RS485 communications") Cc: stable <stable@kernel.org> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Link: https://lore.kernel.org/r/20220824142902.502596-1-sergiu.moga@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23serial: atmel: remove redundant assignment in rs485_configLino Sanfilippo1-3/+1
[ Upstream commit 60efd0513916f195dd85bfbf21653f74f9ab019c ] In uart_set_rs485_config() the serial core already assigns the passed serial_rs485 struct to the uart port. So remove the assignment from the drivers rs485_config() function to avoid redundancy. Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Link: https://lore.kernel.org/r/20220410104642.32195-10-LinoSanfilippo@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 692a8ebcfc24 ("tty: serial: atmel: Preserve previous USART mode if RS485 disabled") Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-23drm/tegra: vic: Fix build warning when CONFIG_PM=nYueHaibing1-2/+2
[ Upstream commit b5d5288a46876f6767950449aea310f71ac86277 ] drivers/gpu/drm/tegra/vic.c:326:12: error: ‘vic_runtime_suspend’ defined but not used [-Werror=unused-function] static int vic_runtime_suspend(struct device *dev) ^~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/tegra/vic.c:292:12: error: ‘vic_runtime_resume’ defined but not used [-Werror=unused-function] static int vic_runtime_resume(struct device *dev) ^~~~~~~~~~~~~~~~~~ Mark it as __maybe_unused. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Stable-dep-of: c7860cbee998 ("drm/tegra: Fix vmapping of prime buffers") Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-20Linux 5.15.69v5.15.69Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20220916100446.916515275@linuxfoundation.org Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-20Input: goodix - add compatible string for GT1158Jarrah Gosbell1-0/+1
commit 80b9ebd3e478cd41526cbf84f80c3e0eb885d1d3 upstream. Add compatible string for GT1158 missing from the previous patch. Fixes: 425fe4709c76 ("Input: goodix - add support for GT1158") Signed-off-by: Jarrah Gosbell <kernel@undef.tools> Link: https://lore.kernel.org/r/20220813043821.9981-1-kernel@undef.tools Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-20RDMA/irdma: Use s/g array in post send only when its validSindhu-Devale1-1/+2
commit 2c8844431d065ae15a6b442f5769b60aeaaa07af upstream. Send with invalidate verb call can pass in an uninitialized s/g array with 0 sge's which is filled into irdma WQE and causes a HW asynchronous event. Fix this by using the s/g array in irdma post send only when its valid. Fixes: 551c46e ("RDMA/irdma: Add user/kernel shared libraries") Signed-off-by: Sindhu-Devale <sindhu.devale@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Link: https://lore.kernel.org/r/20220906223244.1119-5-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-20usb: gadget: f_uac2: fix superspeed transferJing Leng1-2/+14
commit f511aef2ebe5377d4c263842f2e0c0b8e274e8e5 upstream. On page 362 of the USB3.2 specification ( https://usb.org/sites/default/files/usb_32_20210125.zip), The 'SuperSpeed Endpoint Companion Descriptor' shall only be returned by Enhanced SuperSpeed devices that are operating at Gen X speed. Each endpoint described in an interface is followed by a 'SuperSpeed Endpoint Companion Descriptor'. If users use SuperSpeed UDC, host can't recognize the device if endpoint doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed. Currently in the uac2 driver code: 1. ss_epout_desc_comp follows ss_epout_desc; 2. ss_epin_fback_desc_comp follows ss_epin_fback_desc; 3. ss_epin_desc_comp follows ss_epin_desc; 4. Only ss_ep_int_desc endpoint doesn't have 'SuperSpeed Endpoint Companion Descriptor' followed, so we should add it. Fixes: eaf6cbe09920 ("usb: gadget: f_uac2: add volume and mute support") Cc: stable <stable@kernel.org> Signed-off-by: Jing Leng <jleng@ambarella.com> Signed-off-by: Jack Pham <quic_jackp@quicinc.com> Link: https://lore.kernel.org/r/20220721014815.14453-1-quic_jackp@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-20usb: gadget: f_uac2: clean up some inconsistent indentingColin Ian King1-8/+8
commit 18d6b39ee8959c6e513750879b52fd215533cc87 upstream. There are bunch of statements where the indentation is not correct, clean these up. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210902224758.57600-1-colin.king@canonical.com Signed-off-by: Jack Pham <quic_jackp@quicinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-06 06:34:51 +0300