summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-17dt-bindings: usb: Add Aspeed AST2700 DWC3 controllerRyan Chen
The Aspeed AST2700 SoC integrates the Synopsys DesignWare USB3 core with no vendor glue logic: it is functionally compatible with snps,dwc3, uses the standard DWC3 clocks, and the only SoC-specific part is a USB3 PHY that is handled by a separate driver. Add a dedicated binding document rather than adding the compatible and a conditional to snps,dwc3.yaml. This follows the established per-vendor DWC3 convention (apple,dwc3.yaml, socionext,uniphier-dwc3.yaml, ...) and keeps the AST2700-specific constraints - notably the mandatory USB3 PHY - out of the generic schema. Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260710-xhci-v2-1-f292c4f7339a@aspeedtech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17dt-bindings: usb: cdns3: allow iommus propertyFrank Li
Some SoC such as i.MX8QM have iommu support. Add optional property iommus. Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709205331.636449-1-Frank.Li@oss.nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17dt-binding: qcom,snps-dwc3: Add Maili compatible to supported device listKrishna Kurapati
Add Maili compatible to supported device list. Maili has one SuperSpeed USB controller. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260712-maili-usb-dwc3-binding-v1-1-fd6697fa1e21@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17usb: misc: cypress_cy7c63: check result of IOOliver Neukum
If the device returns a bogus short read, treat it as EIO. Actually check for IO errors. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://patch.msgid.link/20260710095523.1646308-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17usb: atm: ueagle-atm: reject descriptors that confuse probe and disconnectDiego Fernando Mancera Gomez
uea_probe() distinguishes a pre-firmware device from a post-firmware one using the USB id (UEA_IS_PREFIRM()), and stores a different object as the interface data in each case: a 'struct completion' for a pre-firmware device (to be waited on in .disconnect()), or a 'struct usbatm_data' for a post-firmware one. uea_disconnect() instead tells the two apart by the number of interfaces of the active configuration (a pre-firmware device exposes a single interface, ADI930 has 2 and eagle has 3), and casts the interface data accordingly. Because the two handlers use different criteria, a crafted device that advertises a pre-firmware id together with a multi-interface descriptor (or a post-firmware id with a single interface) makes them disagree: the small 'struct completion' stored by uea_probe() is then passed to usbatm_usb_disconnect(), which casts it to 'struct usbatm_data' and takes instance->serialize, reading past the end of the allocation: BUG: KASAN: slab-out-of-bounds in __mutex_lock+0x152a/0x1b80 Read of size 8 at addr ffff8880470e2c60 by task kworker/1:2/982 ... __mutex_lock+0x152a/0x1b80 usbatm_usb_disconnect+0x70/0x820 uea_disconnect+0x133/0x2c0 usb_unbind_interface+0x1dd/0x9e0 ... which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes to the right of allocated 96-byte region [ffff8880470e2c00, ffff8880470e2c60) Reject such inconsistent descriptors in uea_probe() so that both handlers always make the same pre/post-firmware decision. Reported-by: syzbot+e62a973f8322b3bbe3ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e62a973f8322b3bbe3ac Fixes: e2674dfbed8a ("usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()") Signed-off-by: Diego Fernando Mancera Gomez <diegomancera.dev@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260717080704.1264-1-diegomancera.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17sctp: fix auth_hmacs array size in struct sctp_cookieXin Long
The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Xin Liu <dstsmallbird@foxmail.com> Reported-by: Zihan Xi <xizh2024@lzu.edu.cn> Reported-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/634a0de0d5de29532915e6d47c92a0cbc206e03f.1783707155.git.lucien.xin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17net/sched: act_tunnel_key: Defer dst_release to RCU callbackJamal Hadi Salim
Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(&params->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x4fff00000000240(workingset|head|node=1|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 04fff00000000240 ffff88801c841b40 ffffea0001856290 ffffea0001856190 raw: ffff88806158d600 0000000800100009 00000000f5000000 0000000000000000 head: 04fff00000000240 ffff88801c841b40 ffffea0001856290 ffffea0001856190 head: ffff88806158d600 0000000800100009 00000000f5000000 0000000000000000 head: 04fff00000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 9391, tgid 9378 (poc), ts 123227323196, free_ts 0 set_page_owner include/linux/page_owner.h:32 post_alloc_hook+0xfe/0x140 mm/page_alloc.c:1853 prep_new_page mm/page_alloc.c:1861 get_page_from_freelist+0x110c/0x2fc0 mm/page_alloc.c:3941 __alloc_frozen_pages_noprof+0x263/0x2bc0 mm/page_alloc.c:5221 alloc_slab_page mm/slub.c:3278 allocate_slab mm/slub.c:3467 new_slab+0xa6/0x690 mm/slub.c:3525 refill_objects+0x271/0x420 mm/slub.c:7272 refill_sheaf mm/slub.c:2816 __pcs_replace_empty_main+0x373/0x630 mm/slub.c:4652 alloc_from_pcs mm/slub.c:4750 slab_alloc_node mm/slub.c:4884 __do_kmalloc_node mm/slub.c:5295 __kmalloc_noprof+0x66d/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 metadata_dst_alloc+0x26/0x90 net/core/dst.c:298 tun_rx_dst include/net/dst_metadata.h:144 __ip_tun_set_dst include/net/dst_metadata.h:208 tunnel_key_init+0xb01/0x1b90 net/sched/act_tunnel_key.c:451 tcf_action_init_1+0x46b/0x6c0 net/sched/act_api.c:1428 tcf_action_init+0x448/0xa20 net/sched/act_api.c:1503 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] ================================================================== Fix by moving dst_release() into a custom RCU callback that runs after the grace period, matching the lifetime of the containing params struct. Readers in the datapath therefore always find a live rcuref when calling dst_clone(). Fixes: 9174c3df1cd18 ("net/sched: act_tunnel_key: fix memory leak in case of action replace") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Davide Caratti <dcaratti@redhat.com> Link: https://patch.msgid.link/20260711150537.7946-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17Merge branch 'netconsole-stop-charging-netpoll-users-for-netconsole-only-data'Paolo Abeni
Breno Leitao says: ==================== netconsole: stop charging netpoll users for netconsole-only data This work continue to untangle netconsole and netpoll, improving memory usage for netpoll users that are not netconsole. struct netpoll is shared by every netpoll consumer in the tree: bonding, bridge, team, vlan, macvlan, dsa and netconsole. The non- netconsole users only need a per-port handle that lets them transmit SKBs. Yet struct netpoll has accumulated a pile of fields that exist only to serve netconsole's printk path: - skb_pool / refill_wq: the fallback skb pool find_skb() falls back on when alloc_skb() returns NULL, plus the workqueue that refills it. - local_port / remote_port / remote_mac: the source and destination UDP ports and the destination ethernet address used to build outgoing log packets. Every netpoll user that allocates a struct netpoll pays for all of these fields, even though it never queues a single skb on the pool, never sends a UDP frame and never looks at any of the addressing. Move this netconsole-only state out of the shared struct into struct netconsole_target, where its only consumer already lives. After the series every passive netpoll consumer drops sizeof(sk_buff_head) + sizeof(work_struct) + 2 * sizeof(u16) + ETH_ALEN bytes per port (plus padding), and struct netpoll keeps only what belongs to the generic poll/transmit abstraction or what netpoll core still reads itself. Follow-ups ---------- local_ip, remote_ip and ipv6 are still in struct netpoll. Moving the addressing additionally requires relocating netpoll_setup() -- whose only caller is netconsole -- and its IPv4/IPv6 helpers, so it is left for a follow-up to keep this series focused on a single responsibility transfer. This is pure code motion with no functional change. The pre-existing target/device teardown races reported against v1 have since been fixed independently (as suggested by Jakub) and are already in the tree, so, re-posting this one. ==================== Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-0-6f63f76b28bc@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: move skb_pool / refill_wq from struct netpoll to netconsole_targetBreno Leitao
These two fields back the fallback skb pool that find_skb() uses. Every helper that touches them lives in netconsole now (refill_skbs, refill_skbs_work_handler, netconsole_skb_pool_init, netconsole_skb_pool_flush, find_skb, netcons_skb_pop), so the data can move alongside its only consumer. Add skb_pool and refill_wq to struct netconsole_target, drop them from struct netpoll. This will save 48-bytes for every netpoll user instance (except netconsole that will have it in netconsole target struct). Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-7-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: move remote_mac from struct netpoll to netconsole_targetBreno Leitao
The destination ethernet address is netconsole configuration: no other netpoll user (bonding, team, vlan, bridge, macvlan, dsa) references np->remote_mac, only netconsole's ethernet framing and its configfs/cmdline interface do. Move it into struct netconsole_target and convert push_eth() to take the netconsole_target; netconsole_print_banner() and netconsole_parser_cmdline() already take it. The configfs show/store handlers and alloc_and_init() reach the field directly. No functional change; the remote_mac sysfs attribute is unchanged. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-9-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: move skb_pool_flush() from netpollBreno Leitao
skb_pool_flush() has no callers left in net/core/netpoll.c after netconsole took over the pool lifecycle. Inline its body into netconsole_skb_pool_flush() (the only caller) and drop the function and its export from netpoll. The prototype goes from <linux/netpoll.h>. Pure code motion: cancel_work_sync() + skb_queue_purge_reason() semantics are unchanged. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-6-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: move local_port / remote_port from struct netpoll to ↵Breno Leitao
netconsole_target The source and destination UDP ports live in struct netpoll but are netconsole configuration. No other netpoll user (bonding, team, vlan, bridge, macvlan, dsa) touches np->local_port or np->remote_port; they only use the netpoll TX/forwarding path. Only netconsole's UDP framing and its configfs/cmdline interface read these fields. Move both into struct netconsole_target and convert the three helpers that read them - push_udp(), netconsole_print_banner() and netconsole_parser_cmdline() - to take the netconsole_target. The configfs show/store handlers already have the target in hand. No functional change; the local_port / remote_port sysfs attributes are unchanged. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-8-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: move refill_skbs() and skb-pool sizing macros from netpollBreno Leitao
refill_skbs() is now only called from netconsole (directly via netconsole_skb_pool_init() and indirectly via the just-moved refill_skbs_work_handler()), and the MAX_UDP_CHUNK / MAX_SKBS / MAX_SKB_SIZE macros are private to it. Move them all into drivers/net/netconsole.c. MAX_UDP_CHUNK and MAX_SKB_SIZE were promoted to <linux/netpoll.h> by commit 6c537b845c99 ("netconsole: do not dequeue pooled skbs that cannot satisfy len") so find_skb() could detect oversized requests against the same value refill_skbs() used. With both functions now local to netconsole, the shared definition no longer needs to live in the header. Pure code motion: bodies and pool sizing semantics are unchanged. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-5-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: move refill_skbs_work_handler() from netpollBreno Leitao
The work handler is wired via INIT_WORK() in netconsole_skb_pool_init() and has no other callers since the previous patch took the skb pool lifecycle out of __netpoll_setup(). Move the function body into drivers/net/netconsole.c as a file-static helper, drop EXPORT_SYMBOL_GPL() and remove the prototype from <linux/netpoll.h>. Pure code motion: the body is unchanged and still calls the exported refill_skbs() in net/core/netpoll.c. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-4-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: take over skb pool lifecycle from netpollBreno Leitao
The fallback skb pool fronted by find_skb() is netconsole's only client: every other netpoll goes through __netpoll_setup() / netpoll_send_skb() without ever touching np->skb_pool. Today __netpoll_setup() and __netpoll_cleanup() create and destroy the pool for everyone, paying ~48 KB of pre-allocated skbs per netpoll instance that only netconsole uses, what a waste! Move the responsibility to netconsole. __netpoll_setup() did this under the RTNL, but netconsole enables targets from enabled_store() / alloc_param_target() without it, while the teardown path flushes the pool (cancel_work_sync() + skb_queue_purge()) under the RTNL from netconsole_process_cleanups_core(). Initialising the queue head and the refill work on every enable would therefore race that flush. They only need initialising once: after a flush the queue head is left valid and empty and cancel_work_sync() leaves the work re-armable. Set them up in alloc_and_init(), while the target is not yet reachable, and let the enable paths only refill the pool via refill_skbs(), which serialises with the flush through skb_pool.lock. See discussions in [1] Link: https://lore.kernel.org/all/alDMvD5S7TZnoD_V@gmail.com/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-3-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netpoll: export refill_skbs(), refill_skbs_work_handler(), skb_pool_flush()Breno Leitao
These three helpers manage the per-netpoll fallback skb pool. They are file-static today because all of their callers live in net/core/netpoll.c. Subsequent patches relocate the pool's owner from struct netpoll to the only consumer that actually uses it (netconsole), and that work needs netconsole to drive the helpers directly while the function bodies still live here. Drop static, add prototypes in <linux/netpoll.h>, and EXPORT_SYMBOL_GPL() each. No behaviour change. The exports are transitional. Each helper is moved into drivers/net/netconsole.c later in this series, and at that point its EXPORT_SYMBOL_GPL() and prototype are dropped. By the end of the series no symbol introduced here remains exported. The goal of this patch is to make the subsequente patches easy to review. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-2-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17netconsole: clean up released targets dropped before the cleanup workerBreno Leitao
drop_netconsole_target() might eventually tear down a target that netconsole_netdev_event() had moved to target_cleanup_list but that netconsole_process_cleanups_core() had not processed yet. Always cleanup devices that eventually have a device attached to the target, independent of the state. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260710-netconsole_move_more-v3-1-6f63f76b28bc@debian.org Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()Ivan Vecera
When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device. Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260710193625.1378822-1-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17tcp: fix TIME_WAIT socket reference leak on PSP policy failureEric Dumazet
Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures. Fixes: 659a2899a57d ("tcp: add datapath logic for PSP with inline key exchange") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20260710181317.4060230-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17net/mlx5: free mlx5_st_idx_data on final deallocZhiping Zhang
Workloads that repeatedly allocate and release mkeys carrying TPH steering-tag hints (e.g. churning RDMA MRs) leak one struct mlx5_st_idx_data per cycle; kmemleak flags it as unreferenced and the kmalloc slab grows over time. When the last reference to an ST table entry is dropped, mlx5_st_dealloc_index() removed the entry from idx_xa but the backing mlx5_st_idx_data allocation was never freed. Free idx_data after the xa_erase() so the lifetime of the bookkeeping struct matches the lifetime of the ST entry it tracks. Cc: stable@vger.kernel.org Fixes: 888a7776f4fb ("net/mlx5: Add support for device steering tag") Reviewed-by: Michael Gur <michaelgur@nvidia.com> Signed-off-by: Zhiping Zhang <zhipingz@meta.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260702222507.1234467-1-zhipingz@meta.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17Merge tag 'linux-can-fixes-for-7.2-20260716' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2026-07-16 this is a pull request of 19 patches for net/main. The first patch is by Alexander Hölzl and fixes the Kconfig description of the vxcan driver. Next patch by Fan Wu fixes the tear down order in the esd_usb driver. Followed by a patch by Oliver Hartkopp that adds missing locking for the raw flags in the CAN_RAW protocol. Shuhao Fu's patch for the j1939 protocol fix lockless local-destination check. Stéphane Grosjean updates their email address. The next 11 patches all target the CAM Broadcast Manager protocol. One contributed by Lee Jones the remaining ones by Oliver Hartkopp. They fix several concurrency and locking issues found by various bots. The last 3 patches are also by Oliver Hartkopp fixing concurrency and locking issues found by various bots in the CAN ISO Transport Protocol. linux-can-fixes-for-7.2-20260716 * tag 'linux-can-fixes-for-7.2-20260716' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: isotp: serialize TX state transitions under so->rx_lock can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER can: isotp: use unconditional synchronize_rcu() in isotp_release() can: bcm: track a single source interface for ANYDEV timeout/throttle ops can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() can: bcm: fix stale rx/tx ops after device removal can: bcm: add missing device refcount for CAN filter removal can: bcm: validate frame length in bcm_rx_setup() for RTR replies can: bcm: extend bcm_tx_lock usage for data and timer updates can: bcm: add missing rcu list annotations and operations can: bcm: fix CAN frame rx/tx statistics can: bcm: add locking when updating filter and timer values can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF can: peak: Modification of references to email accounts being deleted can: j1939: fix lockless local-destination check can: raw: add locking for raw flags bitfield can: esd_usb: kill anchored URBs before freeing netdevs can: vxcan: Kconfig: fix description stating no local echo provided ==================== Link: https://patch.msgid.link/20260716155528.809908-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17cpufreq: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr() and wrmsr() are planned to be removed. Use the related 64-bit variants instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-pm@vger.kernel.org Link: https://patch.msgid.link/20260703112445.1763078-1-jgross@suse.com
2026-07-17x86/featctl: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr() and rdmsr_safe() are planned to be removed. Use the related 64-bit variants instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: https://patch.msgid.link/20260703112426.1763049-1-jgross@suse.com
2026-07-17KVM/x86: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr(), wrmsr() and rdmsr_safe() are planned to be removed. Use the related 64-bit variants instead. No change in functionality intended. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Kiryl Shutsemau <kas@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Sean Christopherson <seanjc@google.com> Cc: kvm@vger.kernel.org Link: https://patch.msgid.link/20260629060526.3638272-10-jgross@suse.com
2026-07-17Merge tag 'for-net-2026-07-13' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_sync: hold hdev->lock for hci_conn_params lookups - hci_sync: extend conn_hash lookup critical sections - hci_qca: Clear memdump state on invalid dump size - MGMT: revalidate LOAD_CONN_PARAM queued update - MGMT: Translate HCI reason in Device Disconnected event - MGMT: fix locking in unpair_device/disconnect_sync - MGMT: hold reference for hci_conn in mgmt_pending_cmds - btrtl: validate firmware patch bounds - qca: fix NVM tag length underflow in TLV parser * tag 'for-net-2026-07-13' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: mgmt: Translate HCI reason in Device Disconnected event Bluetooth: hci_qca: Clear memdump state on invalid dump size Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Bluetooth: hci_sync: extend conn_hash lookup critical sections Bluetooth: btrtl: validate firmware patch bounds Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update Bluetooth: qca: fix NVM tag length underflow in TLV parser ==================== Link: https://patch.msgid.link/20260713141940.954317-1-luiz.dentz@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17x86/mtrr: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr(), wrmsr(), rdmsr_safe() and wrmsr_safe() are planned to be removed. Use the related 64-bit variants instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: https://patch.msgid.link/20260703112344.1762985-1-jgross@suse.com
2026-07-17printk: Handle pre-enabled consoles in the top-level register_console()Petr Mladek
The function try_enable_preferred_console() currently has the non-obvious side effect of returning success for consoles that are already pre-enabled. This obscures the logic flow during console registration. Move the check for pre-enabled consoles directly into the top-level register_console(). This change makes the handling of pre-enabled consoles explicit and easier to follow. Furthermore, this separation lays the groundwork for future cleanups where try_enable_preferred_console() can be restricted to cases where an entry actually exists in the console_cmdline[] array. Also it fixes a possible out-of-bound access when the console_cmdline[] array is full and no console matched. In fact, the check of c->user_specified did not make much sense. The new console either matched and was handled in the for-cycle. Or it did not match and then *c pointed to an unused entry. Possible behavior change: try_enable_preferred_console() will newly be called also with @user_specified parameter set to "false" when it failed with the "true" variant. But it looks like the right way to do. It will allow to call newcon->setup() when the console was preferred by some platform specific code. Reported-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com> # out-of-bound access Closes: https://lore.kernel.org/r/7sq4tr2nmlz32tvkf6vpsghv6exvqfghsrlvywjcqihzsqqbf7@bspclmti5xg4 Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20260604101459.393162-2-pmladek@suse.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2026-07-17Merge tag 'nf-26-07-10' of ↵Paolo Abeni
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf Florian Westphal says: ==================== netfilter: updates for net The following patchset contains Netfilter fixes for *net*. These are fixes for bugs except patches 6 and 9 which fix issues added in last PR and 7.1-rc1. 1) Reject unsupported target families in xt_nat_checkentry(). From Wyatt Feng. 2) Fix inverted time_after() check in ecache_work_evict_list(). Causes pointless work rescheds and thus way longer time to clear the pending event backlog. From Yizhou Zhao. 3) Fix a use-after-free in br_ip6_fragment() caused by a dangling prevhdr pointer. From Xiang Mei. 4) Fix incorrect conntrack zone comparison in nf_conncount tuple deduplication. Pass IP_CT_DIR_ORIGINAL, not zone direction. From Yizhou Zhao. 5) Add bridge tunnel flowtable regression test for a bug that got fixed in the previous PR. From Zhengyang Chen. 6) Use the correct direction when setting up tunnel routes in the flowtable xmit path. From Pablo Neira Ayuso. This fixes a bug added in the previous PR. 7) Reload IP header after potential skb head reallocation in IPVS. 8) Fix incorrect IPv6 transport offsets in TCP application code. Correct the ICMPv6 header offset to ensure proper checksumming with extension headers, from Julian Anastasov. this is a followup to the previous PR. 9) Remove null-termination requirement for xt_physdev masks, this broke device names with 15 characters. netfilter pull request nf-26-07-10 * tag 'nf-26-07-10' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: xt_physdev: masks are not c-strings ipvs: fix more places with wrong ipv6 transport offsets ipvs: reload ip header after head reallocation netfilter: flowtable: use correct direction to set up tunnel route selftests: netfilter: add bridge tunnel flowtable regression netfilter: nf_conncount: fix zone comparison in tuple dedup netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() netfilter: ecache: fix inverted time_after() check netfilter: xt_nat: reject unsupported target families ==================== Link: https://patch.msgid.link/20260710143733.29741-1-fw@strlen.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17intel_idle: Add ACPI _LPI supportRafael J. Wysocki
Allow intel_idle to use idle states information coming from ACPI _LPI objects by making it call acpi_processor_extract_lpi_info() and, if that is successful, using the list of idle states produced by that function instead of the one coming from acpi_processor_evaluate_cst(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2280567.Icojqenx9y@rafael.j.wysocki
2026-07-17intel_idle: Prepare for adding ACPI _LPI supportRafael J. Wysocki
In preparation for adding ACPI _LPI support to intel_idle, move some code used for processing ACPI idle states information coming from _CST objects to separate functions because that code will be also used for processing idle states information coming from _LPI. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1932965.atdPhlSkOF@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Add switch for strict _LPI processingRafael J. Wysocki
Add a "strict" argument to acpi_processor_extract_lpi_info() that, when set, will cause it to ignore _LPI states without minimum residency or wake latency instead of assuming 10 us values for these parameters. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/3896986.MHq7AAxBmi@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Relocate acpi_processor_extract_lpi_info()Rafael J. Wysocki
In preparation for adding ACPI _LPI support to the intel_idle driver, move acpi_processor_extract_lpi_info() along with some static functions used by it to the acpi_processor.c file containing the non-modular part of the ACPI processor driver, so it can be called by external non-modular code like intel_idle. However, export it to modules in the ACPI_PROCESSOR_IDLE import namespace so that the modular part of the ACPI processor driver can still invoke it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/2277662.Mh6RI2rZIc@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Introduce acpi_processor_extract_lpi_info()Rafael J. Wysocki
In preparation for adding ACPI _LPI support to the intel_idle driver, move the majority of the acpi_processor_get_lpi_info() function body to a new function called acpi_processor_extract_lpi_info() that will be exported to external code subsequently. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/2709187.Lt9SDvczpP@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Introduce too_many_states() for _LPIRafael J. Wysocki
To reduce code duplication, introduce a function called too_many_states() that will check if the total number of _LPI states for a given CPU is too large and print a message in that case. Use that function in flatten_lpi_states() and acpi_processor_get_lpi_info(). No functional impact beyond reducing dynamic debug flexibility. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/1964818.CQOukoFCf9@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Rework flatten_lpi_states()Rafael J. Wysocki
Rewrite flatten_lpi_states() to make it easier to follow: * Rename its flat_state_cnt, curr_level and prev_level parameters to state_count, curr, and prev, respectively, so their names match the names of analogous variables in acpi_processor_get_lpi_info(). * Eliminate a redundant local variable state_count. * Move definitions of local variables to the code blocks in which they are used. * Reduce the indentation level in the inner loop. * Use more meaningful names for local variables. * Move two statements that belong in acpi_processor_get_lpi_info() from flatten_lpi_states() to that function. * Use acpi_handle_info() for printing a message when the count of flattened states gets too large and drop the message requesting ACPI_PROCESSOR_MAX_POWER to be adjusted which is pointless. * Add a comment explaining what happens in that function. No intentional functional impact beyond the message printed when the count of flattened states is too large. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/2064627.usQuhbGJ8B@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Rearrange loop in acpi_processor_get_lpi_info()Rafael J. Wysocki
Eliminate local variable status (that is redundant) from acpi_processor_get_lpi_info() and make that function call acpi_get_parent() in one place. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/1862515.VLH7GnMWUR@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Drop redundant _LPI presence checksRafael J. Wysocki
The acpi_has_method() checks for _LPI in acpi_processor_get_lpi_info() are redundant because acpi_processor_evaluate_lpi() returns an error when _LPI is not present, so drop them. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/3349003.5fSG56mABF@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Rework first-level _LPI states processingRafael J. Wysocki
The first-level _LPI states need not be combined with the previous level and the entry method for them cannot be ACPI_CSTATE_INTEGER, so process them directly in acpi_processor_get_lpi_info() instead of doing a special case for them in flatten_lpi_states(). Also bail out if there are no _LPI states at the first level because that means that there are no _LPI states at all. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Link: https://patch.msgid.link/3703077.iIbC2pHGDl@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Rearrange acpi_processor_get_lpi_info()Rafael J. Wysocki
Reorder the definitions of local variables in acpi_processor_get_lpi_info() and drop local variable pr_ahandle that is not really necessary from it. Additionally, move two definitions of local variables to the loop in which they are used and rearrange the code slightly to prepare it for subsequent changes. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/7965163.EvYhyI6sBW@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Introduce lpi_state_debug()Rafael J. Wysocki
Add a helper macro called lpi_state_debug() for printing debug messages regarding _LPI states and use it in acpi_processor_evaluate_lpi(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2043393.PYKUYFuaPT@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Split acpi_processor_evaluate_lpi()Rafael J. Wysocki
Move individual _LPI state package processing from acpi_processor_evaluate_lpi() to a separate new function called process_lpi_state_package(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/10878273.nUPlyArG6x@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Rearrange acpi_processor_evaluate_lpi()Rafael J. Wysocki
Rearrange acpi_processor_evaluate_lpi() to make it somewhat easier to follow and diagnose (if need be). In particular: * Rename some local variables and reorder their definitions. * Change the type of local variables used for storing firmware-provided values to unsigned int (they cannot be negative). * Eliminate local variable "loop" that is redundant. * Avoid explicit pointer arithmetic. * Print the correct number of _LPI state packages in the final debug message. No intentional functional impact beyond debug output. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Link: https://patch.msgid.link/3426078.44csPzL39Z@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Unify debug in acpi_processor_evaluate_lpi()Rafael J. Wysocki
Use acpi_handle_debug() consistently for printing debug messages in acpi_processor_evaluate_lpi() because that makes it somewhat easier to identify the source of the problem in the ACPI tables. No intentional functional impact beyond debug output. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/3051550.e9J7NaK4W3@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Ignore _LPI states with SYSTEMIO entry methodRafael J. Wysocki
The only entry method for _LPI states supported by acpi_idle_lpi_enter() is FFH and it is better to ignore _LPI states with the SYSTEMIO entry method upfront than return an error from acpi_idle_lpi_enter() on attempts to use them. Update acpi_processor_evaluate_lpi() accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/2268989.irdbgypaU6@rafael.j.wysocki
2026-07-17ACPI: processor: idle: Expand _LPI package sanity checksRafael J. Wysocki
The _LPI package sanity checks in acpi_processor_evaluate_lpi() miss a couple of things, so expand them by adding a buffer size check before retrieving a struct acpi_power_register from it (and skip the given state if the buffer is not large enough to hold a register structure) and making the function avoid copying the state description from the ACPI table if there are too few elements in the package supposed to hold it. While at it, relocate and rephrase a comment about skipping _LPI state package elements [7-8]. Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org> Acked-by: Huisong Li <lihuisong@huawei.com> Link: https://patch.msgid.link/5084143.GXAFRqVoOG@rafael.j.wysocki
2026-07-17gpio: pcf857x: Use le16_to_cpu() and cpu_to_le16() in IO accessorsAndy Shevchenko
16-bit expander data is an __le16, use le16_to_cpu() to read it. In the similar way use cpu_to_le16() to write __le16 value. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: and Cc: stable? Link: https://patch.msgid.link/20260715163944.1300616-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-17dt-bindings: gpio: cdns: add Axiado AX3005 GPIO variantSwark Yang
Add binding for Axiado AX3005 GPIO controller. So far, no changes are known, so it can fall back to the cdns,gpio-r1p02 compatible. Signed-off-by: Swark Yang <syang@axiado.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-upstream-axiado-ax3005-upstream-v3-2-c429095143ec@axiado.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-17acpi: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr(), wrmsr(), rdmsr_safe() and wrmsr_safe() are planned to be removed. Use the related 64-bit variants instead. In processor_throttling.c drop needless initializers. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260629060526.3638272-5-jgross@suse.com
2026-07-17powercap: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr_safe() and wrmsr_safe() are planned to be removed. Use the related 64-bit variants instead. Drop a pointless initializer while at it. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260629060526.3638272-3-jgross@suse.com
2026-07-17thermal/intel: Stop using 32-bit MSR interfacesJuergen Gross
The 32-bit MSR interfaces rdmsr(), wrmsr(), rdmsr_safe() and wrmsr_safe() are planned to be removed. Use the related 64-bit variants instead. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260703112232.1762925-1-jgross@suse.com