summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2026-07-17Merge tag 'svc_fixes_for_v7.2' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into char-misc-linus Dinh writes: firmware: stratix10-svc: fixes for v7.2 - Fix a memory leak by explicitly using kfree() to match the list-managed lifetime - Fix FCS SMC call documentation - Add proper handling of a no response from the SDM - Fix teardown order of service driver * tag 'svc_fixes_for_v7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: firmware: stratix10-svc: fix teardown order in remove to prevent race firmware: stratix10-svc: handle NO_RESPONSE in async poll firmware: stratix10-svc: fix FCS SMC call kernel-doc firmware: stratix10-svc: fix memory leaks and list corruption bugs
2026-07-17dmaengine: dw-edma: Enable HDMA 64R/W ChannelsDevendra K Verma
As per 'Designware Cores PCI Express Controller Databook', Section 7.1 - Overview, HDMA supports 64 Read and 64 Write channels. Current controller driver supports up to 8 read and write channels only. In order to utilize all the channels the controller driver need to have the channel related structs and variables as per the number of channels supported by IP. Following changes are made to enable 64 Read / 64 Write channel support: o Defined HDMA specific macros to reflect the channel count. o The count of ll_regions and dt_regions in dw_edma_chip and dw_edma_pcie_data shall be in accordance to number of read and write channels. o In dw_edma_probe() configure the channels as per the channels of the IP used. o Changed mask types to u64 for higher channel counts. Signed-off-by: Devendra K Verma <devendra.verma@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260713064854.4065262-1-devverma@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-17net: mana: Add debug knob to skip TX timeout recovery resetAditya Garg
Add a per-port debugfs boolean "tx_timeout_skip_reset" that, when enabled, makes mana_tx_timeout() log the TX timeout and return without queueing the per-port detach/attach recovery work. This is a debug-only aid for bringup and qualification: skipping the recovery reset keeps the device and queue state intact so a TX timeout can be correlated with hardware telemetry. The knob defaults to false, so production recovery behaviour is unchanged. Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710132229.2851441-1-gargaditya@linux.microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DASiddaraju DH
Add comment to clarify the physical media 10000baseCR follows. 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD. It has no autonegotiation, no link training, and no mandatory FEC. The industry standard for this media type is SFF-8431 Appendix-E Direct Attach cable, also known as 10G_SFI_DA. Link: https://lore.kernel.org/r/SN7PR11MB69003D33489DB1D6B17EF72A9AF52@SN7PR11MB6900.namprd11.prod.outlook.com Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260703100537.1109838-1-siddaraju.dh@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-17ssb: gpio: Add and register software node for GPIO controllerDmitry Torokhov
We want to convert the legacy gpio-keys platform device on BCM47XX boards to use software nodes. To do this properly and allow referencing the GPIO controller by address rather than relying on name-based matching (which is being removed from the gpiolib core), we need to associate the GPIO controller with a software node. Introduce ssb_gpio_swnode, register it, and associate it with the gpio_chip. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17bcma: gpio: Add and register software node for GPIO controllerDmitry Torokhov
We want to convert the legacy gpio-keys platform device on BCM47XX boards to use software nodes. To do this properly and allow referencing the GPIO controller by address rather than relying on name-based matching (which is being removed from the gpiolib core), we need to associate the GPIO controller with a software node. Introduce bcma_gpio_swnode, register it if the device does not already have a firmware node, and associate it with the gpio_chip. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-07-17usb: typec: tcpm: Add support for Battery Cap response messageAmit Sunil Dhamne
Add support for responding to Get_Battery_Cap (extended) request with a a Battery_Capabilities (extended) msg. The requester will request Battery Cap for a specific battery using an index in Get_Battery_Cap. In case of failure to identify battery, TCPM shall reply with an appropriate message indicating so. As the Battery Cap Data Block size is 9 Bytes (lesser than MaxExtendedMsgChunkLen of 26B), only a single chunk is required to complete the AMS. Support for Battery_Capabilities message is required for sinks that contain battery as specified in USB PD Rev3.1 v1.8 ("Applicability of Data Messages" section). Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> Reviewed-by: Badhri Jagan Sridharan <badhri@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260714-batt-caps-upstream-v1-1-c86f0a7fbbda@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17usb: typec: tcpm: Add support for Battery Status response messageAmit Sunil Dhamne
Add support for responding to a Get_Battery_Status request with a Battery_Status message. The port partner shall request the status of a port's battery by providing an index in the Get_Battery_Status AMS. In case of failure to identify the battery, the port shall reply with an appropriate message indicating so. Support for Battery_Status message is required for sinks that contain battery as specified in USB PD Rev3.1 v1.8 ("Applicability of Data Messages" section). Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> Reviewed-by: Badhri Jagan Sridharan <badhri@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260714-batt-status-v5-2-9de4aa900b69@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-17power: supply: Add helpers to get and put arrays of power supply handlesAmit Sunil Dhamne
Add power_supply_get_system_batteries() to allow drivers to obtain a list of registered battery type power supply references in the system. Also add power_supply_put_system_batteries() to perform cleanup after the former function is called. Signed-off-by: Amit Sunil Dhamne <amitsd@google.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260714-batt-status-v5-1-9de4aa900b69@google.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-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-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-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-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-17media: cec/core: add error-inj-tx-timeouts debugfs entryHans Verkuil
Add a new debugfs entry that makes it possible to do error injection of failing the next N transmits by a timeout. This can be used to test what happens in that case during the claiming of a free logical address. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2026-07-17media: cec/core: add a new CEC_LOG_ADDRS_FL_CONFIG_FAILED flagHans Verkuil
If claiming a logical address fails, then set the CEC_LOG_ADDRS_FL_CONFIG_FAILED flag. This makes it possible for userspace to detect this corner case. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2026-07-17media: cec/core: handle core events like normal eventsHans Verkuil
Currently there is a distinction between core events (CEC_EVENT_STATE_CHANGE and CEC_EVENT_LOST_MSGS) and other events. The core events do not require memory allocations, so are a bit faster, but they are also limited to just a single event: if a new event comes in, then that replaces the old one. It's all overly complicated, and with only one state change event it is easy to miss state changes. So just drop that optimization, and allow for up to 3 state change events. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2026-07-17clk: fixed-factor: Export __clk_hw_register_fixed_factor()Benoît Monin
Make the base registration function for fixed-factor clocks public and re-implement the various registration functions that are a direct call to __clk_hw_register_fixed_factor() as macros. This is similar to how the registration functions of divider, mux and other clocks are implemented. Add a new macro clk_hw_register_fixed_factor_pdata() to register a fixed-factor clock with its parent clock passed as a struct clk_parent_data. Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
2026-07-17dt-bindings: soc: mobileye: Add EyeQ7H OLBBenoît Monin
The Other Logic Blocks (OLB) found in Mobileye SoCs contain hardware sub-functions grouped in a logical device. The EyeQ7H features 14 such OLB. The main differences with the previous generation of SoC are that some blocks have two clock sources instead of one and that the clock source can be the one of the clock output of another OLB instead of the main oscillator. For the blocks with a single parent clock, the name of that clock is "ref", similar to what is done for the OLB of the previous SoC. The blocks with two parent clocks use either "ref" for the main oscillator, "ref_100p0" for a 100MHz reference clock or "ref_106p6" for 106.6MHz reference clock. Some OLB also contain a reset controller with one or more reset domain, like the blocks found in the EyeQ6H. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
2026-07-17crypto: powerpc/aes - use bool for encryption/decryption flagThorsten Blum
Use bool for the CBC encryption/decryption flag passed through p8_aes_cbc_crypt() to aes_p8_cbc_encrypt(). Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Breno Leitao <leitao@debian.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-07-17dma/swiotlb: introduce Kconfig option for compile-time default pool sizeJagadeesh Pagadala
The SWIOTLB bounce buffer pool size is hardcoded at 64 MB via IO_TLB_DEFAULT_SIZE with no compile-time knob to adjust it. On memory-constrained embedded or mobile platforms equipped with a hardware IOMMU (e.g., ARM SMMU) covering most DMA-capable devices, reserving 64 MB at boot is unnecessarily wasteful — the SWIOTLB is only exercised for devices that bypass the IOMMU or have restricted DMA address ranges. Introduce CONFIG_SWIOTLB_DEFAULT_SIZE_MB, an integer Kconfig option (range 1–64 MB, default 64) that allows platforms to set a smaller compile-time default. IO_TLB_DEFAULT_SIZE is updated to derive from this value when CONFIG_SWIOTLB is enabled, preserving the existing 64 MB default when the option is not configured. The runtime "swiotlb=<nslabs>" kernel parameter override remains fully supported and takes precedence over the compile-time default. Signed-off-by: Jagadeesh Pagadala <jpagadal@qti.qualcomm.com> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/20260702-swiotlb-v2-1-9205f3ba5408@oss.qualcomm.com Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-16scsi: zorro: Simplify storing pointers in device id structUwe Kleine-König (The Capable Hub)
Technically it is fine (on all current Linux architectures) to store a pointer in an unsigned long variable. However this needs explicit casting which is an easy source for type mismatches. By replacing the plain unsigned long .driver_data in struct zorro_device_id by an anonymous union, most of the casting can be dropped. There is still some implicit casting involved (between a void * and a driver specific pointer type), but that's better than the approach to store a pointer in an unsigned long variable as this doesn't lose the information that the data being pointed to is const. All users of struct zorro_device_id are initialized in a way that is compatible with the new definition, so no adaptions are needed there. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Max Staudt <max@enpas.org> Acked-by: Helge Deller <deller@gmx.de> Link: https://patch.msgid.link/49576a7501128c93ef318566ed7faefce163f1fd.1779803053.git.u.kleine-koenig@baylibre.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-16Merge patch series "ufs: Add callback for vendor-specific RTT capability"Martin K. Petersen
ed.tsai@mediatek.com says: The first patch adds the get_hba_nortt() callback to the UFS core layer, allowing vendor drivers to provide dynamic, platform-specific RTT capability handling. The second patch implements this callback in the MediaTek UFS driver, distinguishing between legacy platforms (which require the RTT to be limited to 2) and newer MT6995 B0+ platforms (which can use the value from the capability register directly). The third patch removes the max_num_rtt field from ufs_hba_variant_ops as it is now replaced by the get_hba_nortt() callback. Link: https://patch.msgid.link/20260615055802.105479-1-ed.tsai@mediatek.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-07-17Merge tag 'drm-misc-next-2026-07-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 7.3: UAPI Changes: Cross-subsystem Changes: Core Changes: - blend: allow blend mode property without PREMULTI - bridges: - Rename drm_for_each_bridge_in_chain_scoped to drm_for_each_bridge_in_chain - Drop legacy bridges support - gpusvm: Code reorganization to give drivers more flexibility Driver Changes: - etnaviv: Check if a reset has been successful - nouveau: Create instmem iomapping at first use - panthor: Remove redundant cleanup - qxl: Convert to a simple encoder to a regular one - bridges: - Convert all remaining legacy bridges to atomic - tc358767: clamp the reported AUX read size to the request - panels: - novatek-nt37801: Use mipi_dsi_*_multi() functions - samsung-s6d16d0: Fix prepare error handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260716-famous-pastel-ostrich-a1aaef@houat
2026-07-16bpf: Fix tracing of kfuncs with implicit argsIhor Solodrai
A kfunc marked with KF_IMPLICIT_ARGS flag takes implicit arguments (such as bpf_prog_aux) that the verifier injects at load time. resolve_btfids strips those from the kfunc's BTF-visible prototype and keeps the real kernel ABI in a counterpart _impl prototype [1]. fentry/fexit/fmod_ret/fsession programs may attach to the BPF kernel functions, including those with implicit args. However bpf_check_attach_target() and bpf_check_attach_btf_id_multi() extract the struct btf_func_model from the wrong BTF prototype of the kfunc. The btf_func_model is later read to construct the trampoline, which then causes the injected implicit argument to be clobbered and the kfunc dereferencing garbage. Add btf_attach_func_proto() to resolve the real ABI prototype of the kfunc the way the call site does: by looking up the _impl prototype for a KF_IMPLICIT_ARGS kfunc. Use it at both attach-target model construction sites. To enable this, make two supporting changes: * pass bpf_verifier_log instead of bpf_verifier_env to find_kfunc_impl_proto(), so it can be reused from the attach path * add btf_kfunc_check_flag() to test a flag across all of a kfunc's hook sets, because a program attaching to a kfunc is not in the kfunc's call-set KF_IMPLICIT_ARGS must be consistent across the sets, so btf_kfunc_check_flag() returns -EINVAL on inconsistency. btf_kfunc_check_flag() reads the kfunc's flags from the target's kfunc_set_tab. For a module BTF that table is stable only after the module is live, so take a module reference around the read, mirroring how the kfunc call path gates the same lookup with btf_try_get_module(). The remaining call sites of btf_distill_func_proto() are safe as is. The BPF_TRACE_ITER case distills a registered iterator's prototype, and bpf_struct_ops_desc_init() distills the function-pointer members of a struct_ops type. Neither is a kfunc, and so can't have implicit arguments. [1] https://lore.kernel.org/all/20260120222638.3976562-1-ihor.solodrai@linux.dev/ Fixes: 64e1360524b9 ("bpf: Verifier support for KF_IMPLICIT_ARGS") Reported-by: Tejun Heo <tj@kernel.org> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://github.com/sched-ext/scx/issues/3687#issuecomment-4906694106 Link: https://patch.msgid.link/20260713235223.1639022-2-ihor.solodrai@linux.dev Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-16Merge tag 'pmdomain-v7.2-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: "imx: - Assign child domains for imx93 to prevent power off when in use - Fix i.MX8MP power up sequences mediatek: - Fix possible nullptr in HWV cleanup/on-check" * tag 'pmdomain-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check pmdomain: imx: Fix i.MX8MP VC8000E power up sequence pmdomain: imx: Fix i.MX8MP power notifier pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI dt-bindings: power: imx93: Add MIPI PHY power domain
2026-07-16net/mlx5: Add PSP related fields to the mlx5_ifcCosmin Ratiu
This adds: - misc_parameters_6, containing a few fields for matching PSP headers. As this is the last misc_parameters field defined, retire the old optimization added in commit [1] to not touch the reserved part. - PSP decap action. - PSP SPI header field pointer. [1] commit 667cb65ae5ad ("net/mlx5: Don't store reserved part in FTEs and FGs") Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260713084320.1015240-3-tariqt@nvidia.com Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-16net/mlx5: Drop redundant esw_cap, reuse e_switch_capShay Drory
esw_manager_vport_number{,_valid} and merged_eswitch were read through a separate mlx5_ifc_esw_cap_bits struct, but these bits live in the e-switch capability that mlx5_ifc_e_switch_cap_bits already describes (both overlay the same QUERY_HCA_CAP op_mod 0x9 output). Add esw_manager_vport_number{,_valid} to mlx5_ifc_e_switch_cap_bits at the same offsets, drop the redundant mlx5_ifc_esw_cap_bits and its hca_cap_union member, and switch the only user (hws/cmd.c) to capability.e_switch_cap. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260713084320.1015240-2-tariqt@nvidia.com Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-16smp: Use task-local IPI cpumask in smp_call_function_many_cond()Chuyi Zhou
smp_call_function_many_cond() uses the per-CPU cfd->cpumask as the list of remote CPUs to wait for. That is safe while the caller remains pinned to the current CPU for the whole operation, because another task cannot run on the same CPU and reuse the per-CPU mask. The synchronous wait is the long-latency part of the operation. To make that wait preemptible, the mask iterated by csd_lock_wait() must remain stable even if the task is preempted or migrates. If the wait used the per-CPU cfd->cpumask after dropping CPU pinning, another task scheduled on the original CPU could enter smp_call_function_many_cond() and overwrite the mask while the first task is still iterating it. Give each task private IPI cpumask storage and use it as the wait mask in smp_call_function_many_cond(). Other cpumask storage choices do not fit this use case: - Per-CPU storage is the state that becomes unsafe once the wait is made preemptible. After the caller drops CPU pinning, another task scheduled on the original CPU can enter smp_call_function_many_cond() and reuse the same per-CPU mask. - Stack storage is not suitable for large NR_CPUS or CONFIG_CPUMASK_OFFSTACK=y configurations. The wait mask needs to scale with cpumask_size(), and putting that storage on the stack is not acceptable on large systems. - Allocating the mask inside smp_call_function_many_cond() would put an allocation and a failure path in the generic IPI path. A sleeping allocation is not suitable because callers have historically only provided a preempt-disabled context, not a sleepable one. GFP_ATOMIC would avoid sleeping, but a failure fallback would make the latency improvement opportunistic instead of guaranteed. The users are not limited to a small, pre-identifiable class of tasks. On x86, ordinary tasks can reach this path through TLB flushes during exit, unmap and reclaim, so allocating the mask only for a known subset of tasks is not straightforward. The memory cost is explicit: one word is added to task_struct. When cpumask_size() fits in that word, the mask is stored inline and no separate allocation is needed. Larger systems allocate cpumask_size() per task; on x86-64 NR_CPUS=8192 this is 1 KiB per task. For context, x86 already carries several KiB of per-task architecture and FPU state, depending on the enabled features and configuration. That does not make the extra cpumask free, but it puts the large-NR_CPUS case in perspective. Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20260709122933.4021501-5-zhouchuyi@bytedance.com
2026-07-16smp: Refactor remote CPU selection in smp_call_function_any()Chuyi Zhou
smp_call_function_any() disables preemption across the entire operation: selecting a target CPU, enqueueing the IPI, and synchronously waiting for the remote CPU. smp_call_function_single() already re-enables preemption before the synchronous csd_lock_wait(), so callers of smp_call_function_any() should benefit from the same shorter preemption-disabled section. Simply removing get_cpu() and put_cpu() from smp_call_function_any() would leave the preemption disablement entirely to smp_call_function_single(). That opens a preemption window between selecting the remote CPU, for example via sched_numa_find_nth_cpu(), and dispatching the IPI in smp_call_function_single(). If the selected CPU is fully offlined in that window, smp_call_function_single() fails its cpu_online() check and returns -ENXIO to the caller, violating the guarantee that smp_call_function_any() executes on any online CPU in the mask. Move the remote CPU selection into a common __smp_call_function_single() helper. Keep the target CPU selection and IPI dispatch within the same preemption-disabled region, while still allowing the wait path to use the shorter preemption-disabled section provided by smp_call_function_single(). Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20260709122933.4021501-4-zhouchuyi@bytedance.com
2026-07-16can: peak: Modification of references to email accounts being deletedStéphane Grosjean
Following the sale of PEAK-System France by HMS-Networks, this update is intended to change all my @hms-networks.com email addresses to my new @peak-system.fr address. Signed-off-by: Stéphane Grosjean <s.grosjean@peak-system.fr> Link: https://patch.msgid.link/20260410124251.40506-1-stephane.grosjean@free.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2026-07-15srcu: expose srcu_readers_active()Onur Özkan
This is needed by rust/helpers/srcu.c which now adds rust_helper_srcu_readers_active() as a wrapper around the SRCU helper for Rust callers. To achive this: 1- Move the srcu_readers_active() implementation from "kernel/rcu/srcutree.c" to "include/linux/srcutree.h". 2- Implement a matching srcu_readers_active() in "include/linux/srcutiny.h" and use it on the existing open-coded WARN_ON() check in cleanup_srcu_struct(). Signed-off-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-15srcu: make init_srcu_struct() consistently wrap __init_srcu_struct()Onur Özkan
Restructure the SRCU initialization functions so it always follows one direction: init_srcu_struct() -> __init_srcu_struct() -> lockdep or generic This uses the same wrapper style as mutex. It avoids the old confusing style where init_srcu_struct() and __init_srcu_struct() called each other in different configs. It also helps Rust side to have simpler helper for SRCU initialization. Signed-off-by: Onur Özkan <work@onurozkan.dev> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-15Merge branch '20260624-glymur_camcc-v5-1-a321df74b1a1@oss.qualcomm.com' into ↵Bjorn Andersson
HEAD Merge Glymur clock controller binding from topic branch to get access to constants.
2026-07-15Merge branch ↵Bjorn Andersson
'20260608-shikra-gcc-rpmcc-clks-v5-2-94cefe092ee3@oss.qualcomm.com' into HEAD Merge Shikra RPM and global clock controller bindings from topic branch to get access to the various constants.
2026-07-15remoteproc: qcom: Check subdev start status in rproc_stop()Jingyi Wang
For rproc that doing attach, rproc_start_subdevices() is called only when attach successfully. If rproc_report_crash() is called in the attach function, rproc_boot_recovery()->rproc_stop()->rproc_stop_subdevices()-> glink_subdev_stop() could be called and cause NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000300 Mem abort info: ... pc : qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] lr : glink_subdev_stop+0x1c/0x30 [qcom_common] ... Call trace: qcom_glink_smem_unregister+0x14/0x48 [qcom_glink_smem] (P) glink_subdev_stop+0x1c/0x30 [qcom_common] rproc_stop+0x58/0x17c rproc_trigger_recovery+0xb0/0x150 rproc_crash_handler_work+0xa4/0xc4 process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x124/0x138 ret_from_fork+0x10/0x20 Code: a9be7bfd 910003fd a90153f3 aa0003f3 (b9430000) ---[ end trace 0000000000000000 ]--- Introduce "subdevs_started" flag to indicate rproc_start_subdevices() has been called successfully. Ensure subdevices are only stopped if they have been started. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-2-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-15remoteproc: core: Attach rproc asynchronously in rproc_add() path via ↵Jingyi Wang
schedule_work() Unlike the remoteproc firmware load path where rproc_add() call rproc_auto_boot_callback() asynchronously and ignores the return value of rproc_boot(), the attach path calls rproc_boot() synchronously and propagates its return value back to rproc_add(). This means a failure during rproc_attach() causes rproc_add() to fail and triggers resource release, removing the remoteproc from sysfs and making it unavailable for recovery or further boot attempts. Align the remoteproc attach path with the firmware load path by introducing attach_work and scheduling rproc_boot() asynchronously via schedule_work(). This keeps the remoteproc registered and available in sysfs even if the initial attach attempt fails, and avoids blocking rproc_add() on the attach result. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260623-rproc-attach-issue-v3-1-8e24310707ce@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-15PCI: vmd: Add feature to scan BIOS-enumerated devicesNirmal Patel
Newer VMD with device ID 0x28C1 has unique settings compared to its predecessor where BIOS enumerates the entire VMD device tree and assigns respective configurations. VMD configuration BAR0 carries over from GNR legacy VMD as the mechanism to access the configuration space of the devices owned by VMD. The size of this window is fixed at 256 MB, where each function consumes 4 KB and every bus consumes 1 MB. The shadow and scratchpad registers have been relocated from the VMD configuration space to the VMD MMIO space in VMD BAR4/BAR5, otherwise refers to as MEMBAR2 or MSI-X bar. VMD MSI-X remapping enable/disable is no longer supported. On this new device, simply obtain the bus hide range and shadow register values set by BIOS and perform a bus scan. Also refactor vmd_enable_domain(). Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260629165025.268836-1-nirmal.patel@linux.intel.com
2026-07-15kunit: provide a set of fwnode-oriented helpersBartosz Golaszewski
Provide three new kunit-managed helpers for test cases that need to register/create dynamic software nodes. Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260713-swnode-fw-devlink-v4-1-d4f2dee27ad9@oss.qualcomm.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-15cpufreq: intel_pstate: Adjust the .adjust_perf() driver callbackRafael J. Wysocki
In some cases, the processor may not actually stick to the "desired" performance level programmed through the driver's .adjust_perf() callback and may go above it, which may not be desirable (for instance, there may be a UCLAMP_MAX limit set for the task currently running on the given CPU which should be respected). Address that by adjusting the .adjust_perf() callback to take an additional argument, max_perf, representing the maximum allowed performance level of the CPU and update the intel_pstate driver to take that argument into account as appropriate. Accordingly, adjust cpufreq_driver_adjust_perf() and the other existing user of .adjust_perf(), which is the amd-pstate driver (but the behavior of that driver is not changed). While at it, also update the cpufreq_driver_adjust_perf() documentation to reflect this change and some previous code changes that have not been taken into account in it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/6277654.lOV4Wx5bFT@rafael.j.wysocki [ rjw: Adjusted Rust function formatting ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-15media: videobuf2: move vb2_querybuf() kernel-doc to headerTharit Tangkijwanichakul
Move the function documentation for vb2_querybuf() from videobuf2-v4l2.c to videobuf2-v4l2.h to match other functions. Leaving the comment in the source file prevents the kernel-doc parser from extracting it - thus become missing from the generated HTML. Additionally, format the comment block to be the same style as other functions in the header. Signed-off-by: Tharit Tangkijwanichakul <tharitt97@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-15media: pci: Use PCI_DEVICE macros and drop zeros from pci_device_id arraysUwe Kleine-König (The Capable Hub)
Some pci_device_id arrays already used the PCI_DEVICE macros, others used named initializers or list initializers. Unify all to use the PCI_DEVICE macros and (if applicable) a named initializer for .driver_data. Also drop all zeros that the compiler can care for and unify indention and spacing. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-07-15sched/psi: Create the psimon kthread outside of cgroup_mutexTejun Heo
a5b98009f16d ("sched/psi: fix race between file release and pressure write") made pressure_write() hold cgroup_mutex across psi_trigger_create(), which forks the psimon kthread for the first rtpoll trigger. As kthread creation depends on the whole fork path, the commit inadvertently created a lot of unwanted locking dependencies from cgroup_mutex. sched_ext got hit by one: its enable path blocks forks and then grabs cgroup_mutex, so a pressure write racing a scheduler enable deadlocks, with every other fork piling up behind. Fix it by splitting trigger creation so that the worker is forked with cgroup_mutex dropped and the kernfs active reference left broken. The latter matters because rmdir and cgroup.pressure writes drain active references under cgroup_mutex. Publishing the trigger last keeps error reporting synchronous and preserves the of->priv lifetime rules. The trigger registered in the first stage pins the group's rtpoll machinery across the unlocked window, leaving only creation races to resolve. The catch-up poll on installation covers scheduling attempts dropped while there was no worker. v2: Retagged sched/psi (was cgroup). Fixes: a5b98009f16d ("sched/psi: fix race between file release and pressure write") Cc: stable@vger.kernel.org Cc: Edward Adam Davis <eadavis@qq.com> Cc: Chen Ridong <chenridong@huaweicloud.com> Reported-by: Matt Fleming <mfleming@cloudflare.com> Closes: https://lore.kernel.org/all/20260710100441.2653477-1-matt@readmodwrite.com/ Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Tested-by: Matt Fleming <mfleming@cloudflare.com> Acked-by: Suren Baghdasaryan <surenb@google.com>
2026-07-15drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05Alessandro Rinaldi
The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that advertises AUX/DPCD backlight control, so amdgpu's automatic detection (amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight path has no effect: brightness writes are accepted but the panel level never changes, the display is stuck at a fixed brightness and max_brightness is reported as a bogus 511000. As a result neither the desktop brightness slider nor the brightness hotkeys do anything. Forcing PWM backlight (amdgpu.backlight=0) restores working control: max_brightness becomes 65535 and the level tracks writes. This has long been applied by users as a manual kernel-parameter workaround. Extend the generic panel backlight quirk with a force_pwm flag, add an entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu disable AUX backlight (use PWM) when the quirk matches and the user lets the driver auto-select the backlight type. Signed-off-by: Alessandro Rinaldi <ale@alerinaldi.it> Tested-by: Alessandro Rinaldi <ale@alerinaldi.it> Reviewed-by: George Zhang <george.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>