summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-12regulator: tps6287x: Force writing VSEL bitMatti Vaittinen1-0/+1
[ Upstream commit 1ace99d7c7c4c801c0660246f741ff846a9b8e3c ] The data-sheet for TPS6287x-Q1 https://www.ti.com/lit/ds/symlink/tps62873-q1.pdf states at chapter 9.3.6.1 Output Voltage Range: "Note that every change to the VRANGE[1:0] bits must be followed by a write to the VSET register, even if the value of the VSET[7:0] bits does not change." The current implementation of the driver uses the regulator_set_voltage_sel_pickable_regmap() helper which further uses regmap_update_bits() to write the VSET-register. The regmap_update_bits() will not access the hardware if the new register value is same as old. It is worth noting that this is true also when the register is marked volatile, which I can't say is wrong because 'read-mnodify-write'-cycle with a volatile register is in any case something user should carefully consider. The 'range_applied_by_vsel'-flag in regulator desc was added to force the vsel register upodates by using regmap_write_bits(). This variant will always unconditionally write the bits to the hardware. It is worth noting that the vsel is now forced to be written to the hardware, whether the range was changed or not. This may cause a performance drop if users are wrtiting same voltage value repeteadly. It would be possible to read the range register to determine if it was changed, but this would be a performance issue for users who don't use reg cache for vsel. Always write the VSET register to the hardware regardless the cache. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 7b0518fbf2be ("regulator: Add support for TI TPS6287x regulators") Link: https://msgid.link/r/ZktD50C5twF1EuKu@fedora Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12regulator: pickable ranges: don't always cache vselMatti Vaittinen2-13/+33
[ Upstream commit f4f4276f985a5aac7b310a4ed040b47e275e7591 ] Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range is changed, the new voltage setting is not taking effect until the vsel register is written. Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this behaviour and to force the vsel value to be written to hardware if range was changed, even if the old selector was same as the new one. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 1ace99d7c7c4 ("regulator: tps6287x: Force writing VSEL bit") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12rpcrdma: fix handling for RDMA_CM_EVENT_DEVICE_REMOVALDan Aloni1-1/+5
[ Upstream commit 4836da219781ec510c4c0303df901aa643507a7a ] Under the scenario of IB device bonding, when bringing down one of the ports, or all ports, we saw xprtrdma entering a non-recoverable state where it is not even possible to complete the disconnect and shut it down the mount, requiring a reboot. Following debug, we saw that transport connect never ended after receiving the RDMA_CM_EVENT_DEVICE_REMOVAL callback. The DEVICE_REMOVAL callback is irrespective of whether the CM_ID is connected, and ESTABLISHED may not have happened. So need to work with each of these states accordingly. Fixes: 2acc5cae2923 ('xprtrdma: Prevent dereferencing r_xprt->rx_ep after it is freed') Cc: Sagi Grimberg <sagi.grimberg@vastdata.com> Signed-off-by: Dan Aloni <dan.aloni@vastdata.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12sunrpc: fix NFSACL RPC retry on soft mountDan Aloni1-0/+1
[ Upstream commit 0dc9f430027b8bd9073fdafdfcdeb1a073ab5594 ] It used to be quite awhile ago since 1b63a75180c6 ('SUNRPC: Refactor rpc_clone_client()'), in 2012, that `cl_timeout` was copied in so that all mount parameters propagate to NFSACL clients. However since that change, if mount options as follows are given: soft,timeo=50,retrans=16,vers=3 The resultant NFSACL client receives: cl_softrtry: 1 cl_timeout: to_initval=60000, to_maxval=60000, to_increment=0, to_retries=2, to_exponential=0 These values lead to NFSACL operations not being retried under the condition of transient network outages with soft mount. Instead, getacl call fails after 60 seconds with EIO. The simple fix is to pass the existing client's `cl_timeout` as the new client timeout. Cc: Chuck Lever <chuck.lever@oracle.com> Cc: Benjamin Coddington <bcodding@redhat.com> Link: https://lore.kernel.org/all/20231105154857.ryakhmgaptq3hb6b@gmail.com/T/ Fixes: 1b63a75180c6 ('SUNRPC: Refactor rpc_clone_client()') Signed-off-by: Dan Aloni <dan.aloni@vastdata.com> Reviewed-by: Benjamin Coddington <bcodding@redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12nfs: keep server info for remountsMartin Kaiser1-3/+6
[ Upstream commit b322bf9e983addedff0894c55e92d58f4d16d92a ] With newer kernels that use fs_context for nfs mounts, remounts fail with -EINVAL. $ mount -t nfs -o nolock 10.0.0.1:/tmp/test /mnt/test/ $ mount -t nfs -o remount /mnt/test/ mount: mounting 10.0.0.1:/tmp/test on /mnt/test failed: Invalid argument For remounts, the nfs server address and port are populated by nfs_init_fs_context and later overwritten with 0x00 bytes by nfs23_parse_monolithic. The remount then fails as the server address is invalid. Fix this by not overwriting nfs server info in nfs23_parse_monolithic if we're doing a remount. Fixes: f2aedb713c28 ("NFS: Add fs_context support.") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12NFSv4: Fixup smatch warning for ambiguous returnBenjamin Coddington1-7/+5
[ Upstream commit 37ffe06537af3e3ec212e7cbe941046fce0a822f ] Dan Carpenter reports smatch warning for nfs4_try_migration() when a memory allocation failure results in a zero return value. In this case, a transient allocation failure error will likely be retried the next time the server responds with NFS4ERR_MOVED. We can fixup the smatch warning with a small refactor: attempt all three allocations before testing and returning on a failure. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: c3ed222745d9 ("NFSv4: Fix free of uninitialized nfs4_label on referral lookup.") Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ASoC: tas2781: Fix wrong loading calibrated data sequenceShenghao Ding3-82/+32
[ Upstream commit b195acf5266d2dee4067f89345c3e6b88d925311 ] Calibrated data will be set to default after loading DSP config params, which will cause speaker protection work abnormally. Reload calibrated data after loading DSP config params. Remove declaration of unused API which load calibrated data in wrong sequence, changed the copyright year and correct file name in license header. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://msgid.link/r/20240518141546.1742-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ASoC: tas2552: Add TX path for capturing AUDIO-OUT dataShenghao Ding1-2/+13
[ Upstream commit 7078ac4fd179a68d0bab448004fcd357e7a45f8d ] TAS2552 is a Smartamp with I/V sense data, add TX path to support capturing I/V data. Fixes: 38803ce7b53b ("ASoC: codecs: tas*: merge .digital_mute() into .mute_stream()") Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://msgid.link/r/20240518033515.866-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12nfc: nci: Fix uninit-value in nci_rx_workRyosuke Yasuoka1-1/+14
[ Upstream commit e4a87abf588536d1cdfb128595e6e680af5cf3ed ] syzbot reported the following uninit-value access issue [1] nci_rx_work() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded. Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet") Reported-and-tested-by: syzbot+d7b4dc6cd50410152534@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d7b4dc6cd50410152534 [1] Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12selftests: net: kill smcrouted in the cleanup logic in amt.shTaehee Yoo1-1/+7
[ Upstream commit cc563e749810f5636451d4b833fbd689899ecdb9 ] The amt.sh requires smcrouted for multicasting routing. So, it starts smcrouted before forwarding tests. It must be stopped after all tests, but it isn't. To fix this issue, it kills smcrouted in the cleanup logic. Fixes: c08e8baea78e ("selftests: add amt interface selftest script") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ipv6: sr: fix missing sk_buff release in seg6_input_coreAndrea Mayer1-5/+6
[ Upstream commit 5447f9708d9e4c17a647b16a9cb29e9e02820bd9 ] The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails. Fixes: af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12net: Always descend into dsa/ folder with CONFIG_NET_DSA enabledFlorian Fainelli1-1/+3
[ Upstream commit b1fa60ec252fba39130107074becd12d0b3f83ec ] Stephen reported that he was unable to get the dsa_loop driver to get probed, and the reason ended up being because he had CONFIG_FIXED_PHY=y in his kernel configuration. As Masahiro explained it: "obj-m += dsa/" means everything under dsa/ must be modular. If there is a built-in object under dsa/ with CONFIG_NET_DSA=m, you cannot do "obj-$(CONFIG_NET_DSA) += dsa/". You need to change it back to "obj-y += dsa/". This was the case here whereby CONFIG_NET_DSA=m, and so the obj-$(CONFIG_FIXED_PHY) += dsa_loop_bdinfo.o rule is not executed and the DSA loop mdio_board info structure is not registered with the kernel, and eventually the device is simply not found. To preserve the intention of the original commit of limiting the amount of folder descending, conditionally descend into drivers/net/dsa when CONFIG_NET_DSA is enabled. Fixes: 227d72063fcc ("dsa: simplify Kconfig symbols and dependencies") Reported-by: Stephen Langstaff <stephenlangstaff1@gmail.com> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12x86/kconfig: Select ARCH_WANT_FRAME_POINTERS again when UNWINDER_FRAME_POINTER=yMasahiro Yamada1-4/+1
[ Upstream commit 66ee3636eddcc82ab82b539d08b85fb5ac1dff9b ] It took me some time to understand the purpose of the tricky code at the end of arch/x86/Kconfig.debug. Without it, the following would be shown: WARNING: unmet direct dependencies detected for FRAME_POINTER because 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection") removed 'select ARCH_WANT_FRAME_POINTERS'. The correct and more straightforward approach should have been to move it where 'select FRAME_POINTER' is located. Several architectures properly handle the conditional selection of ARCH_WANT_FRAME_POINTERS. For example, 'config UNWINDER_FRAME_POINTER' in arch/arm/Kconfig.debug. Fixes: 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/20240204122003.53795-1-masahiroy@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ubsan: Restore dependency on ARCH_HAS_UBSANKees Cook1-0/+1
[ Upstream commit 890a64810d59b1a58ed26efc28cfd821fc068e84 ] While removing CONFIG_UBSAN_SANITIZE_ALL, ARCH_HAS_UBSAN wasn't correctly depended on. Restore this, as we do not want to attempt UBSAN builds unless it's actually been tested on a given architecture. Reported-by: Masahiro Yamada <masahiroy@kernel.org> Closes: https://lore.kernel.org/all/20240514095427.541201-1-masahiroy@kernel.org Fixes: 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") Link: https://lore.kernel.org/r/20240514233747.work.441-kees@kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12perf/arm-dmc620: Fix lockdep assert in ->event_init()Namhyung Kim1-3/+6
[ Upstream commit a4c5a457c6107dfe9dc65a104af1634811396bac ] for_each_sibling_event() checks leader's ctx but it doesn't have the ctx yet if it's the leader. Like in perf_event_validate_size(), we should skip checking siblings in that case. Acked-by: Mark Rutland <mark.rutland@arm.com> Fixes: f3c0eba28704 ("perf: Add a few assertions") Reported-by: Greg Thelen <gthelen@google.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Tuan Phan <tuanphan@os.amperecomputing.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20240514180050.182454-1-namhyung@kernel.org Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12xen/x86: add extra pages to unpopulated-alloc if availableRoger Pau Monne1-0/+33
[ Upstream commit a6aa4eb994ee9ced905743817c5de8451d26b911 ] Commit 262fc47ac174 ('xen/balloon: don't use PV mode extra memory for zone device allocations') removed the addition of the extra memory ranges to the unpopulated range allocator, using those only for the balloon driver. This forces the unpopulated allocator to attach hotplug ranges even when spare memory (as part of the extra memory ranges) is available. Furthermore, on PVH domains it defeats the purpose of commit 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH'), as extra memory ranges would only be used to map foreign memory if the kernel is built without XEN_UNPOPULATED_ALLOC support. Fix this by adding a helpers that adds the extra memory ranges to the list of unpopulated pages, and zeroes the ranges so they are not also consumed by the balloon driver. This should have been part of 38620fc4e893, hence the fixes tag. Note the current logic relies on unpopulated_init() (and hence arch_xen_unpopulated_init()) always being called ahead of balloon_init(), so that the extra memory regions are consumed by arch_xen_unpopulated_init(). Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20240429155053.72509-1-roger.pau@citrix.com Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12regulator: bd71828: Don't overwrite runtime voltagesMatti Vaittinen1-56/+2
[ Upstream commit 0f9f7c63c415e287cd57b5c98be61eb320dedcfc ] Some of the regulators on the BD71828 have common voltage setting for RUN/SUSPEND/IDLE/LPSR states. The enable control can be set for each state though. The driver allows setting the voltage values for these states via device-tree. As a side effect, setting the voltages for SUSPEND/IDLE/LPSR will also change the RUN level voltage which is not desired and can break the system. The comment in code reflects this behaviour, but it is likely to not make people any happier. The right thing to do is to allow setting the enable/disable state at SUSPEND/IDLE/LPSR via device-tree, but to disallow setting state specific voltages for those regulators. BUCK1 is a bit different. It only shares the SUSPEND and LPSR state voltages. The former behaviour of allowing to silently overwrite the SUSPEND state voltage by LPSR state voltage is also changed here so that the SUSPEND voltage is prioritized over LPSR voltage. Prevent setting PMIC state specific voltages for regulators which do not support it. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 522498f8cb8c ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators") Link: https://msgid.link/r/e1883ae1e3ae5668f1030455d4750923561f3d68.1715848512.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12blk-cgroup: Properly propagate the iostat update up the hierarchyWaiman Long1-1/+18
[ Upstream commit 9d230c09964e6e18c8f6e4f0d41ee90eef45ec1c ] During a cgroup_rstat_flush() call, the lowest level of nodes are flushed first before their parents. Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), iostat propagation was still done to the parent. Grandparent, however, may not get the iostat update if the parent has no blkg_iostat_set queued in its lhead lockless list. Fix this iostat propagation problem by queuing the parent's global blkg->iostat into one of its percpu lockless lists to make sure that the delta will always be propagated up to the grandparent and so on toward the root blkcg. Note that successive calls to __blkcg_rstat_flush() are serialized by the cgroup_rstat_lock. So no special barrier is used in the reading and writing of blkg->iostat.lqueued. Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Reported-by: Dan Schatzberg <schatzberg.dan@gmail.com> Closes: https://lore.kernel.org/lkml/ZkO6l%2FODzadSgdhC@dschatzberg-fedora-PF3DHTBV/ Signed-off-by: Waiman Long <longman@redhat.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/20240515143059.276677-1-longman@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12blk-cgroup: fix list corruption from reorder of WRITE ->lqueuedMing Lei1-0/+10
[ Upstream commit d0aac2363549e12cc79b8e285f13d5a9f42fd08e ] __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier. Cc: Tejun Heo <tj@kernel.org> Cc: Waiman Long <longman@redhat.com> Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20240515013157.443672-3-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12blk-cgroup: fix list corruption from resetting io statMing Lei1-23/+35
[ Upstream commit 6da6680632792709cecf2b006f2fe3ca7857e791 ] Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. Cc: Tejun Heo <tj@kernel.org> Cc: Waiman Long <longman@redhat.com> Cc: Jay Shin <jaeshin@redhat.com> Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Signed-off-by: Ming Lei <ming.lei@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> Reviewed-by: Waiman Long <longman@redhat.com> Link: https://lore.kernel.org/r/20240515013157.443672-2-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()Sungwoo Kim1-1/+1
[ Upstream commit a5b862c6a221459d54e494e88965b48dcfa6cc44 ] l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: 6ed58ec520ad ("Bluetooth: Use LE buffers for LE traffic") Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12Bluetooth: ISO: Handle PA sync when no BIGInfo reports are generatedIulia Tanasescu3-81/+74
[ Upstream commit d356c924e7a3adbea1e3e4ff4e098bcd9b99a82d ] In case of a Broadcast Source that has PA enabled but no active BIG, a Broadcast Sink needs to establish PA sync and parse BASE from PA reports. This commit moves the allocation of a PA sync hcon from the BIGInfo advertising report event to the PA sync established event. After the first complete PA report, the hcon is notified to the ISO layer. A child socket is allocated and enqueued in the parent's accept queue. BIGInfo reports also need to be processed, to extract the encryption field and inform userspace. After the first BIGInfo report is received, the PA sync hcon is notified again to the ISO layer. Since a socket will be found this time, the socket state will transition to BT_CONNECTED and the userspace will be woken up using sk_state_change. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Stable-dep-of: a5b862c6a221 ("Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocationsMohamed Ahmed3-25/+29
[ Upstream commit 959314c438caf1b62d787f02d54a193efda38880 ] Allow PTE kind and tile mode on BO create with VM_BIND, and add a GETPARAM to indicate this change. This is needed to support modifiers in NVK and ensure correctness when dealing with the nouveau GL driver. The userspace modifiers implementation this is for can be found here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795 Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240509204352.7597-1-mohamedahmedegypt2001@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ALSA: hda/realtek: Drop doubly quirk entry for 103c:8a2eTakashi Iwai1-1/+0
[ Upstream commit d731b1ed15052580b7b2f40559021012d280f1d9 ] There are two quirk entries for SSID 103c:8a2e. Drop the latter one that isn't applied in anyway. As both point to the same quirk action, there is no actual behavior change. Fixes: aa8e3ef4fe53 ("ALSA: hda/realtek: Add quirks for various HP ENVY models") Link: https://lore.kernel.org/r/20240513064010.17546-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ASoC: rt715-sdca-sdw: Fix wrong complete waiting in rt715_dev_resume()Bard Liao1-2/+2
[ Upstream commit c8bdf9e727acb6e1b37febf422ef1751e5a2c7d1 ] enumeration_complete will be completed when a peripheral is attached. And initialization_complete will be completed when a peripheral is initialized. rt715_dev_resume() should wait for initialization_complete instead of enumeration_complete. the issue exists since commit 20d17057f0a8 ("ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver"), but the commit can only apply to commit f892e66fcabc ("ASoC: rt-sdw*: add __func__ to all error logs"). Fixes: f892e66fcabc ("ASoC: rt-sdw*: add __func__ to all error logs") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20240509163658.68062-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ASoC: mediatek: mt8192: fix register configuration for tdmHsin-Te Yuan1-2/+2
[ Upstream commit a85ed162f0efcfdd664954414a05d1d560cc95dc ] For DSP_A, data is a BCK cycle behind LRCK trigger edge. For DSP_B, this delay doesn't exist. Fix the delay configuration to match the standard. Fixes: 52fcd65414abfc ("ASoC: mediatek: mt8192: support tdm in platform driver") Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20240509-8192-tdm-v1-1-530b54645763@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ALSA: hda: cs35l56: Fix lifetime of cs_dsp instanceRichard Fitzgerald1-3/+5
[ Upstream commit d344873c4cbde249b7152d36a273bcc45864001e ] The cs_dsp instance is initialized in the driver probe() so it should be freed in the driver remove(). Also fix a missing call to cs_dsp_remove() in the error path of cs35l56_hda_common_probe(). The call to cs_dsp_remove() was being done in the component unbind callback cs35l56_hda_unbind(). This meant that if the driver was unbound and then re-bound it would be using an uninitialized cs_dsp instance. It is best to initialize the cs_dsp instance in probe() so that it can return an error if it fails. The component binding API doesn't have any error handling so there's no way to handle a failure if cs_dsp was initialized in the bind. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier") Link: https://lore.kernel.org/r/20240508100811.49514-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ALSA: hda: hda_component: Initialize shared data during bind callbackRichard Fitzgerald3-7/+18
[ Upstream commit ec6f32bc924d1c00cbcd5672510758f7088f2513 ] Move the initialization of the shared struct hda_component array into hda_component_manager_bind(). The purpose of the manager bind() callback is to allow it to perform initialization before binding in the component drivers. This is the correct place to initialize the shared data. The original implementation initialized the shared data in hda_component_manager_init(). This is only done once during probe() of the manager driver. So if the component binding was unbound and then rebound, the shared data would not be re-initialized. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: fd895a74dc1d ("ALSA: hda: realtek: Move hda_component implementation to module") Link: https://lore.kernel.org/r/20240508100347.47283-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ALSA: hda/cs_dsp_ctl: Use private_free for control cleanupRichard Fitzgerald1-16/+31
[ Upstream commit 172811e3a557d8681a5e2d0f871dc04a2d17eb13 ] Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 3233b978af23 ("ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls") Link: https://lore.kernel.org/r/20240508095627.44476-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12KVM: arm64: Destroy mpidr_data for 'late' vCPU creationOliver Upton1-9/+41
[ Upstream commit ce5d2448eb8fe83aed331db53a08612286a137dd ] A particularly annoying userspace could create a vCPU after KVM has computed mpidr_data for the VM, either by racing against VGIC initialization or having a userspace irqchip. In any case, this means mpidr_data no longer fully describes the VM, and attempts to find the new vCPU with kvm_mpidr_to_vcpu() will fail. The fix is to discard mpidr_data altogether, as it is only a performance optimization and not required for correctness. In all likelihood KVM will recompute the mappings when KVM_RUN is called on the new vCPU. Note that reads of mpidr_data are not guarded by a lock; promote to RCU to cope with the possibility of mpidr_data being invalidated at runtime. Fixes: 54a8006d0b49 ("KVM: arm64: Fast-track kvm_mpidr_to_vcpu() when mpidr_data is available") Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240508071952.2035422-1-oliver.upton@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12KVM: PPC: Book3S HV nestedv2: Fix an error handling path in ↵Christophe JAILLET1-2/+2
gs_msg_ops_kvmhv_nestedv2_config_fill_info() [ Upstream commit b52e8cd3f835869370f8540f1bc804a47a47f02b ] The return value of kvmppc_gse_put_buff_info() is not assigned to 'rc' and 'rc' is uninitialized at this point. So the error handling can not work. Assign the expected value to 'rc' to fix the issue. Fixes: 19d31c5f1157 ("KVM: PPC: Add support for nestedv2 guests") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/a7ed4cc12e0a0bbd97fac44fe6c222d1c393ec95.1706441651.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12KVM: PPC: Book3S HV nestedv2: Cancel pending DEC exceptionVaibhav Jain1-1/+1
[ Upstream commit 7be6ce7043b4cf293c8826a48fd9f56931cef2cf ] This reverts commit 180c6b072bf3 ("KVM: PPC: Book3S HV nestedv2: Do not cancel pending decrementer exception") [1] which prevented canceling a pending HDEC exception for nestedv2 KVM guests. It was done to avoid overhead of a H_GUEST_GET_STATE hcall to read the 'DEC expiry TB' register which was higher compared to handling extra decrementer exceptions. However recent benchmarks indicate that overhead of not handling 'DECR' expiry for Nested KVM Guest(L2) is higher and results in much larger exits to Pseries Host(L1) as indicated by the Unixbench-arithoh bench[2] Metric | Current upstream | Revert [1] | Difference % ======================================================================== arithoh-count (10) | 3244831634 | 3403089673 | +04.88% kvm_hv:kvm_guest_exit | 513558 | 152441 | -70.32% probe:kvmppc_gsb_recv | 28060 | 28110 | +00.18% N=1 As indicated by the data above that reverting [1] results in substantial reduction in number of L2->L1 exits with only slight increase in number of H_GUEST_GET_STATE hcalls to read the value of 'DEC expiry TB'. This results in an overall ~4% improvement of arithoh[2] throughput. [1] commit 180c6b072bf3 ("KVM: PPC: Book3S HV nestedv2: Do not cancel pending decrementer exception") [2] https://github.com/kdlucas/byte-unixbench/ Fixes: 180c6b072bf3 ("KVM: PPC: Book3S HV nestedv2: Do not cancel pending decrementer exception") Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240415035731.103097-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12powerpc/bpf/32: Fix failing test_bpf testsChristophe Leroy2-31/+110
[ Upstream commit 8ecf3c1dab1c675721d3d0255556abe2306fa340 ] Recent additions in BPF like cpu v4 instructions, test_bpf module exhibits the following failures: test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #313 BSWAP 16: 0x0123456789abcdef -> 0xefcd eBPF filter opcode 00d7 (@2) unsupported jited:0 301 PASS test_bpf: #314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 555 PASS test_bpf: #315 BSWAP 64: 0x0123456789abcdef -> 0x67452301 eBPF filter opcode 00d7 (@2) unsupported jited:0 268 PASS test_bpf: #316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 269 PASS test_bpf: #317 BSWAP 16: 0xfedcba9876543210 -> 0x1032 eBPF filter opcode 00d7 (@2) unsupported jited:0 460 PASS test_bpf: #318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 320 PASS test_bpf: #319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe eBPF filter opcode 00d7 (@2) unsupported jited:0 222 PASS test_bpf: #320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 273 PASS test_bpf: #344 BPF_LDX_MEMSX | BPF_B eBPF filter opcode 0091 (@5) unsupported jited:0 432 PASS test_bpf: #345 BPF_LDX_MEMSX | BPF_H eBPF filter opcode 0089 (@5) unsupported jited:0 381 PASS test_bpf: #346 BPF_LDX_MEMSX | BPF_W eBPF filter opcode 0081 (@5) unsupported jited:0 505 PASS test_bpf: #490 JMP32_JA: Unconditional jump: if (true) return 1 eBPF filter opcode 0006 (@1) unsupported jited:0 261 PASS test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed] Fix them by adding missing processing. Fixes: daabb2b098e0 ("bpf/tests: add tests for cpuv4 instructions") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12printk: Fix LOG_CPU_MAX_BUF_SHIFT when BASE_SMALL is enabledYoann Congal1-2/+2
[ Upstream commit 320bf43190514be5c00e11f47ec2160dd3993844 ] LOG_CPU_MAX_BUF_SHIFT default value depends on BASE_SMALL: config LOG_CPU_MAX_BUF_SHIFT default 12 if !BASE_SMALL default 0 if BASE_SMALL But, BASE_SMALL is a config of type int and "!BASE_SMALL" is always evaluated to true whatever is the value of BASE_SMALL. This patch fixes this by using the correct conditional operator for int type : BASE_SMALL != 0. Note: This changes CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 to CONFIG_LOG_CPU_MAX_BUF_SHIFT=0 for BASE_SMALL defconfigs, but that will not be a big impact due to this code in kernel/printk/printk.c: /* by default this will only continue through for large > 64 CPUs */ if (cpu_extra <= __LOG_BUF_LEN / 2) return; Systems using CONFIG_BASE_SMALL and having 64+ CPUs should be quite rare. John Ogness <john.ogness@linutronix.de> (printk reviewer) wrote: > For printk this will mean that BASE_SMALL systems were probably > previously allocating/using the dynamic ringbuffer and now they will > just continue to use the static ringbuffer. Which is fine and saves > memory (as it should). Petr Mladek <pmladek@suse.com> (printk maintainer) wrote: > More precisely, it allocated the buffer dynamically when the sum > of per-CPU-extra space exceeded half of the default static ring > buffer. This happened for systems with more than 64 CPUs with > the default config values. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ Reported-by: Vegard Nossum <vegard.nossum@oracle.com> Closes: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Link: https://lore.kernel.org/r/20240505080343.1471198-2-yoann.congal@smile.fr Signed-off-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION()Zhu Yanjun1-0/+1
[ Upstream commit 9e6727f824edcdb8fdd3e6e8a0862eb49546e1cd ] No functional changes intended. Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver") Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20240506075538.6064-1-yanjun.zhu@linux.dev Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ASoC: tas2781: Fix a warning reported by robot kernel testShenghao Ding1-3/+3
[ Upstream commit 1ae14f3520b1a0ad144610a3f592c81a3e81cd1b ] Fix a warning reported by robot kernel test that 'fw_entry' in function 'tas2781_load_calibration' is used uninitialized with compiler sh4-linux-gcc (GCC) 13.2.0, an update of copyright and a correction of the comments. Fixes: ef3bcde75d06 ("ASoc: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://lore.kernel.org/r/20240505122346.1326-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting failsKonrad Dybcio1-1/+2
[ Upstream commit 46d4efcccc688cbacdd70a238bedca510acaa8e4 ] Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/588919/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12drm/msm/adreno: fix CP cycles stat retrieval on a7xxZan Dobersek1-2/+2
[ Upstream commit 328660262df89ab64031059909d763f7a8af9570 ] a7xx_submit() should use the a7xx variant of the RBBM_PERFCTR_CP register for retrieving the CP cycles value before and after the submitted command stream execution. Signed-off-by: Zan Dobersek <zdobersek@igalia.com> Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/588445/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12selftests/powerpc/dexcr: Add -no-pie to hashchk testsBenjamin Gray1-1/+1
[ Upstream commit d7228a58d9438d6f219dc7f33eab0d1980b3bd2f ] The hashchk tests want to verify that the hash key is changed over exec. It does so by calculating hashes at the same address across an exec. This is made simpler by disabling PIE functionality, so we can re-execute ourselves and be using the same addresses in the child. While -fno-pie is already added, -no-pie is also required. Fixes: bdb07f35a52f ("selftests/powerpc/dexcr: Add hashst/hashchk test") Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20240417112325.728010-2-bgray@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12ASoC: amd: acp: fix for acp platform device creation failureVijendar Mukunda4-21/+95
[ Upstream commit 09068d624c490c0e89f33f963c402f1859964467 ] ACP pin configuration varies based on acp version. ACP PCI driver should read the ACP PIN config value and based on config value, it has to create a platform device in below two conditions. 1) If ACP PDM configuration is selected from BIOS and ACP PDM controller exists. 2) If ACP I2S configuration is selected from BIOS. Other than above scenarios, ACP PCI driver should skip the platform device creation logic, i.e. ACP PCI driver probe sequence should never fail if other acp pin configuration is selected. It should skip platform device creation logic. check_acp_pdm() function was implemented for ACP6.x platforms to check ACP PDM configuration. Previously, this code was safe guarded by FLAG_AMD_LEGACY_ONLY_DMIC flag check. This implementation breaks audio use cases for Huawei Matebooks which are based on ACP3.x varaint uses I2S configuration. In current scenario, check_acp_pdm() function returns -ENODEV value which results in ACP PCI driver probe failure without creating a platform device even in case of valid ACP pin configuration. Implement check_acp_config() as a common function which invokes platform specific acp pin configuration check functions for ACP3.x, ACP6.0 & ACP6.3 & ACP7.0 variants and checks for ACP PDM controller. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218780 Fixes: 4af565de9f8c ("ASoC: amd: acp: fix for acp pdm configuration check") Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20240502140340.4049021-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12drm: zynqmp_dpsub: Always register bridgeSean Anderson1-4/+3
[ Upstream commit be3f3042391d061cfca2bd22630e0d101acea5fc ] We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240308204741.3631919-1-sean.anderson@linux.dev (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"Luca Ceresoli1-1/+0
[ Upstream commit ad81feb5b6f1f5461641706376dcf7a9914ed2e7 ] This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path") Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com (cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12media: cec: core: avoid confusing "transmit timed out" messageHans Verkuil1-1/+14
[ Upstream commit cbe499977bc36fedae89f0a0d7deb4ccde9798fe ] If, when waiting for a transmit to finish, the wait is interrupted, then you might get a "transmit timed out" message, even though the transmit was interrupted and did not actually time out. Set transmit_in_progress_aborted to true if the wait_for_completion_killable() call was interrupted and ensure that the transmit is properly marked as ABORTED. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Yang, Chenyuan <cy54@illinois.edu> Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: 590a8e564c6e ("media: cec: abort if the current transmit was canceled") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12media: cec: core: avoid recursive cec_claim_log_addrsHans Verkuil3-2/+7
[ Upstream commit 47c82aac10a6954d68f29f10d9758d016e8e5af1 ] Keep track if cec_claim_log_addrs() is running, and return -EBUSY if it is when calling CEC_ADAP_S_LOG_ADDRS. This prevents a case where cec_claim_log_addrs() could be called while it was still in progress. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Yang, Chenyuan <cy54@illinois.edu> Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12media: cec: cec-api: add locking in cec_release()Hans Verkuil1-0/+3
[ Upstream commit 42bcaacae924bf18ae387c3f78c202df0b739292 ] When cec_release() uses fh->msgs it has to take fh->lock, otherwise the list can get corrupted. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Yang, Chenyuan <cy54@illinois.edu> Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12media: cec: cec-adap: always cancel work in cec_transmit_msg_fhHans Verkuil1-2/+1
[ Upstream commit 9fe2816816a3c765dff3b88af5b5c3d9bbb911ce ] Do not check for !data->completed, just always call cancel_delayed_work_sync(). This fixes a small race condition. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Yang, Chenyuan <cy54@illinois.edu> Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: 490d84f6d73c ("media: cec: forgot to cancel delayed work") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12media: sunxi: a83-mips-csi2: also select GENERIC_PHYRandy Dunlap1-0/+1
[ Upstream commit 8237026159cb6760ad22e28d57b9a1c53b612d3a ] When selecting GENERIC_PHY_MIPI_DPHY, also select GENERIC_PHY to prevent kconfig warnings: WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY Depends on [n]: GENERIC_PHY [=n] Selected by [y]: - VIDEO_SUN8I_A83T_MIPI_CSI2 [=y] && MEDIA_SUPPORT [=y] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && V4L_PLATFORM_DRIVERS [=y] && VIDEO_DEV [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) && PM [=y] && COMMON_CLK [=y] && RESET_CONTROLLER [=y] Fixes: 94d7fd9692b5 ("media: sunxi: Depend on GENERIC_PHY_MIPI_DPHY") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/ZQ/WS8HC1A3F0Qn8@rli9-mobl Link: https://lore.kernel.org/linux-media/20230927040438.5589-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12cxl/region: Fix cxlr_pmem leaksLi Zhijian1-0/+1
[ Upstream commit 1c987cf22d6b65ade46145c03eef13f0e3e81d83 ] Before this error path, cxlr_pmem pointed to a kzalloc() memory, free it to avoid this memory leaking. Fixes: f17b558d6663 ("cxl/pmem: Refactor nvdimm device registration, delete the workqueue") Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240428030748.318985-1-lizhijian@fujitsu.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12cxl/trace: Correct DPA field masks for general_media & dram eventsAlison Schofield1-2/+2
[ Upstream commit 2042d11cb57b7e0cbda7910e5ff80e9e8bf0ae17 ] The length of Physical Address in General Media and DRAM event records is 64-bit, so the field mask for extracting the DPA should be 64-bit also, otherwise the trace event reports DPA's with the upper 32 bits of a DPA address masked off. If users do DPA-to-HPA translations this could lead to incorrect page retirement decisions. Use GENMASK_ULL() for CXL_DPA_MASK to get all the DPA address bits. Tidy up CXL_DPA_FLAGS_MASK by using GENMASK() to only mask the exact flag bits. These bits are defined as part of the event record physical address descriptions of General Media and DRAM events in CXL Spec 3.1 Section 8.2.9.2 Events. Fixes: d54a531a430b ("cxl/mem: Trace General Media Event Record") Co-developed-by: Shiyang Ruan <ruansy.fnst@fujitsu.com> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/2867fc43c57720a4a15a3179431829b8dbd2dc16.1714496730.git.alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12um: Fix the declaration of kasan_map_memoryTiwei Bie3-1/+3
[ Upstream commit 6a85e34c4d07d2ec0c153067baff338ac0db55ca ] Make it match its definition (size_t vs unsigned long). And declare it in a shared header to fix the -Wmissing-prototypes warning, as it is defined in the user code and called in the kernel code. Fixes: 5b301409e8bc ("UML: add support for KASAN under x86_64") Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-30 09:36:00 +0300