linux.git/drivers/firewire, branch master

Merge tag 'x86_cpu_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-19T02:09:42+00:00

Pull x86 cpuid updates from Borislav Petkov: - Get rid of static_cpu_has() - one less API to care about testing CPU features - Unify the handling of CPU core types (performance, efficient, etc) by mapping the vendor-specific types to Linux ones - Continuation of the work of Ahmed Darwish to centralize CPUID leaf representation * tag 'x86_cpu_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU: Rename struct cpuid_read_output to struct cpuid_output x86/cpu/scattered: Sort it properly x86/cpu: Use parsed CPUID(0x1) x86/lib: Add CPUID(0x1) family and model calculation x86/cpu: Use parsed CPUID(0x0) x86/cpu/transmeta: Rescan CPUID(0x1) after modifying capabilities x86/topology: Add TOPO_CPU_TYPE_LOW_POWER x86/topology: Name the AMD core-type values x86/topo: Map vendor CPU types to generic Linux such types x86/bugs: Don't use cpu-type matching in cpu_vuln_blacklist x86/cpu: Hide and rename static_cpu_has()

firewire: ohci: fix NULL pointer dereference in ar_context_release

2026-08-13T12:02:23+00:00

During the error handling path of the driver's probe function, a NULL pointer dereference can occur in ar_context_release(). When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping fails), the devres cleanup mechanism invokes release_ohci(). This function unconditionally calls ar_context_release() to clean up the asynchronous receive contexts. However, if ar_context_init() was not yet called, ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by devres_alloc()). ar_context_release() immediately dereferences ctx->ohci to get the dev pointer before checking if the context was actually initialized, leading to a crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543 Call Trace: release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567 release_nodes drivers/base/devres.c:546 [inline] devres_release_all+0x1a8/0x260 drivers/base/devres.c:576 device_unbind_cleanup drivers/base/dd.c:597 [inline] really_probe+0x451/0xae0 drivers/base/dd.c:772 To fix this, move the assignment of the dev pointer after the !ctx->buffer check. If ctx->buffer is NULL, it indicates that the context was never successfully initialized and there is nothing to release, safely avoiding the dereference of the uninitialized ctx->ohci pointer. Fixes: 5716e58aecdd ("firewire: ohci: release buffer for AR req/resp contexts when managed resource is released") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+d30aad27833a559defab@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d30aad27833a559defab Link: https://syzkaller.appspot.com/ai_job?id=10a18617-7893-42dd-bf1c-cd49e19e95d9 Signed-off-by: Aleksandr Nogikh Link: https://lore.kernel.org/r/90c5db71-dd1f-4d46-b9d3-2f1046cbd5ea@mail.kernel.org Signed-off-by: Takashi Sakamoto

firewire: net: Fix fragmented datagram reassembly

2026-07-13T11:19:06+00:00

fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: c76acec6d551 ("firewire: add IPv4 support") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260707150454.2265951-1-ruoyuw560@gmail.com Signed-off-by: Takashi Sakamoto

x86/cpu: Hide and rename static_cpu_has()

2026-07-07T04:34:26+00:00

cpu_feature_enabled() is the one to use to test feature flags so hide the static thing which doesn't pay attention to disabled mask bits anyway. Use the following command to do the replacement: $ git grep --files-with-matches -w static_cpu_has -- ':(exclude)*cpufeature.h' \ | xargs sed -i 's/static_cpu_has(/cpu_feature_enabled\(/g' There should be no functional changes resulting from this. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nikolay Borisov Link: https://patch.msgid.link/20260620015041.336288-1-bp@kernel.org

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

firewire: core: Open-code topology list walk

2026-06-13T02:10:23+00:00

A later change will make list_for_each_entry() cache the next element before entering the loop body. for_each_fw_node() intentionally appends newly discovered child nodes to the temporary walk list while the list is being traversed. Keep the loop open-coded so the next node is looked up only after children have been appended. This preserves the current breadth-first traversal semantics and prepares the code for the list iterator update. Signed-off-by: Kaitao Cheng Link: https://lore.kernel.org/r/20260609061347.93688-3-kaitao.cheng@linux.dev Signed-off-by: Takashi Sakamoto

firewire: core: cancel using delayed work for iso_resource_once management

2026-05-21T09:43:25+00:00

There is no need to use deferrable type of work for iso_resource_once management because the work is queued to run immediately. Link: https://lore.kernel.org/r/20260520130840.629934-4-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto

firewire: core: rename member name for channel mask of isoc resource

2026-05-21T09:43:25+00:00

The iso_resource_params structure has a member for channel mask, while the name of field is easy to misinterpret. Append _mask to the member name. Link: https://lore.kernel.org/r/20260520130840.629934-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto

firewire: core: minor code refactoring for case-dependent parameters of iso resources management

2026-05-21T09:43:25+00:00

The generation parameter is specific to the auto case of iso resources management, while it is in the common parameter structure. Move the generation member to the structure specific to auto case. Link: https://lore.kernel.org/r/20260520130840.629934-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto

firewire: core: move allocation/reallocation paths into specific branch after isoc resource management in cdev

2026-05-03T11:44:21+00:00

After managing the actual isochronous resources, there is post-processing logic to determine what type of event should be notified. However, there is room for improvement. This commit refactors the logic. Link: https://lore.kernel.org/r/20260501135823.241940-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto