summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-15drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync offThomas Zimmermann
Blank the display by disabling sync pulses with VGACR17<7>. Unblank by reenabling them. This VGA setting should be supported by all Aspeed hardware. Ast currently blanks via sync-off bits in VGACRB6. Not all BMCs handle VGACRB6 correctly. After disabling sync during a reboot, some BMCs do not reenable it after the soft reset. The display output remains dark. When the display is off during boot, some BMCs set the sync-off bits in VGACRB6, so the display remains dark. Observed with Blackbird AST2500 BMCs. Clearing the sync-off bits unconditionally fixes these issues. Also do not modify VGASR1's SD bit for blanking, as it only disables GPU access to video memory. v2: - init vgacrb6 correctly (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: ce3d99c83495 ("drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers") Tested-by: Nick Bowler <nbowler@draconx.ca> Reported-by: Nick Bowler <nbowler@draconx.ca> Closes: https://lore.kernel.org/dri-devel/wpwd7rit6t4mnu6kdqbtsnk5bhftgslio6e2jgkz6kgw6cuvvr@xbfswsczfqsi/ Cc: Douglas Anderson <dianders@chromium.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.7+ Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20251014084743.18242-1-tzimmermann@suse.de
2025-10-15accel/ivpu: Fix race condition when mapping dmabufWludzik, Jozef
Fix a race that can occur when multiple jobs submit the same dmabuf. This could cause the sg_table to be mapped twice, leading to undefined behavior. Fixes: e0c0891cd63b ("accel/ivpu: Rework bind/unbind of imported buffers") Signed-off-by: Wludzik, Jozef <jozef.wludzik@intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Link: https://lore.kernel.org/r/20251014071725.3047287-1-karol.wachowski@linux.intel.com
2025-10-14net: airoha: Add get_link ethtool callbackLorenzo Bianconi
Set get_link ethtool callback to ethtool_op_get_link routine. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251013-airoha-ethtool-improvements-v1-2-fdd1c6fc9be1@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-14net: airoha: Add missing stats to ethtool_eth_mac_statsLorenzo Bianconi
Add the following stats to ethtool ethtool_eth_mac_stats stats: - FramesTransmittedOK - OctetsTransmittedOK - FramesReceivedOK - OctetsReceivedOK Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251013-airoha-ethtool-improvements-v1-1-fdd1c6fc9be1@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-14eth: fealnx: fix typo in commentsDenis Benato
There are a few typos in comments: - replace "avilable" with "available" - replace "mutlicast" with "multicast" Signed-off-by: Denis Benato <benato.denis96@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251013183632.1226627-1-benato.denis96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-14cxl/trace: Subtract to find an hpa_alias0 in cxl_poison eventsAlison Schofield
Traces of cxl_poison events include an hpa_alias0 field if the poison address is in a region configured with an ELC, Extended Linear Cache. Since the ELC always comes first in the region, the calculation needs to subtract the ELC size from the calculated HPA address. Fixes: 8c520c5f1e76 ("cxl: Add extended linear cache address alias emission for cxl events") Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-10-14interval_tree: Fix ITSTATIC usage for *_subtree_search()Josh Poimboeuf
For consistency with the other function templates, change _subtree_search_*() to use the user-supplied ITSTATIC rather than the hard-coded 'static'. Acked-by: Petr Mladek <pmladek@suse.com> Tested-by: Joe Lawrence <joe.lawrence@redhat.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2025-10-14ipmi: Skip channel scan if channels are already marked readyJinhui Guo
Channels remain static unless the BMC firmware changes. Therefore, rescanning is unnecessary while they are marked ready and no BMC update has occurred. Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Message-ID: <20250930074239.2353-4-guojinhui.liam@bytedance.com> Signed-off-by: Corey Minyard <corey@minyard.net>
2025-10-14ipmi: Fix __scan_channels() failing to rescan channelsJinhui Guo
channel_handler() sets intf->channels_ready to true but never clears it, so __scan_channels() skips any rescan. When the BMC firmware changes a rescan is required. Allow it by clearing the flag before starting a new scan. Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Message-ID: <20250930074239.2353-3-guojinhui.liam@bytedance.com> Signed-off-by: Corey Minyard <corey@minyard.net>
2025-10-14ipmi: Fix the race between __scan_channels() and deliver_response()Jinhui Guo
The race window between __scan_channels() and deliver_response() causes the parameters of some channels to be set to 0. 1.[CPUA] __scan_channels() issues an IPMI request and waits with wait_event() until all channels have been scanned. wait_event() internally calls might_sleep(), which might yield the CPU. (Moreover, an interrupt can preempt wait_event() and force the task to yield the CPU.) 2.[CPUB] deliver_response() is invoked when the CPU receives the IPMI response. After processing a IPMI response, deliver_response() directly assigns intf->wchannels to intf->channel_list and sets intf->channels_ready to true. However, not all channels are actually ready for use. 3.[CPUA] Since intf->channels_ready is already true, wait_event() never enters __wait_event(). __scan_channels() immediately clears intf->null_user_handler and exits. 4.[CPUB] Once intf->null_user_handler is set to NULL, deliver_response() ignores further IPMI responses, leaving the remaining channels zero-initialized and unusable. CPUA CPUB ------------------------------- ----------------------------- __scan_channels() intf->null_user_handler = channel_handler; send_channel_info_cmd(intf, 0); wait_event(intf->waitq, intf->channels_ready); do { might_sleep(); deliver_response() channel_handler() intf->channel_list = intf->wchannels + set; intf->channels_ready = true; send_channel_info_cmd(intf, intf->curr_channel); if (condition) break; __wait_event(wq_head, condition); } while(0) intf->null_user_handler = NULL; deliver_response() if (!msg->user) if (intf->null_user_handler) rv = -EINVAL; return rv; ------------------------------- ----------------------------- Fix the race between __scan_channels() and deliver_response() by deferring both the assignment intf->channel_list = intf->wchannels and the flag intf->channels_ready = true until all channels have been successfully scanned or until the IPMI request has failed. Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Message-ID: <20250930074239.2353-2-guojinhui.liam@bytedance.com> Signed-off-by: Corey Minyard <corey@minyard.net>
2025-10-14PCI: Revert early bridge resource set upIlpo Järvinen
The commit a43ac325c7cb ("PCI: Set up bridge resources earlier") moved bridge window resources set up earlier than before. The change was necessary to support another change that got pulled on the last minute due to breaking s390 and other systems. The presence of valid bridge window resources earlier than before allows pci_assign_unassigned_root_bus_resources() call from pci_host_probe() assign the bridge windows. Some host bridges, however, have to wait first for the link up event before they can enumerate successfully (see e.g. qcom_pcie_global_irq_thread()) and thus the bus has not been enumerated yet while calling pci_host_probe(). Calling pci_assign_unassigned_root_bus_resources() without results from enumeration can result in sizing bridge windows with too small sizes which cannot be later corrected after the enumeration has completed because bridge windows have become pinned in place by the other resources. Interestingly, it seems pci_read_bridge_bases() is not called at all in the problematic case and the bridge window resource type setup is done by pci_bridge_check_ranges() and sizing by the usual resource fitting logic. The root problem behind all this looks pretty generic. If resource fitting is called too early, the hotplug reservation and old size lower bounding cause the bridge windows to be assigned without children but with non-zero size, which leads to these pinning problems. As such, this can likely be solved on the general level but the solution does not look trivial. As the commit a43ac325c7cb ("PCI: Set up bridge resources earlier") was prequisite for other change that did not end up into kernel yet, revert it to resolve the resource assignment failures and give time to code and test a generic solution. Fixes: a43ac325c7cb ("PCI: Set up bridge resources earlier") Reported-by: Val Packett <val@packett.cool> Link: https://lore.kernel.org/r/017ff8df-511c-4da8-b3cf-edf2cb7f1a67@packett.cool Reported-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/df266709-a9b3-4fd8-af3a-c22eb3c9523a@roeck-us.net Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251014163602.17138-1-ilpo.jarvinen@linux.intel.com
2025-10-14net: dsa: b53: implement port isolation supportJonas Gorski
Implement port isolation support via the Protected Ports register. Protected ports can only communicate with unprotected ports, but not with each other, matching the expected behaviour of isolated ports. Tested on BCM963268BU. Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20251013152834.100169-1-jonas.gorski@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-14cxl/region: Use %pa printk format to emit resource_size_tAlison Schofield
KASAN reports a stack-out-of-bounds access in validate_region_offset() while running the cxl-poison.sh unit test because the printk format specifier, %pr format, is not a match for the resource_size_t type of the variables. %pr expects struct resource pointers and attempts to dereference the structure fields, reading beyond the bounds of the stack variables. Since these messages emit an 'A exceeds B' type of message, keep the resource_size_t's and use the %pa specifier to be architecture safe. BUG: KASAN: stack-out-of-bounds in resource_string.isra.0+0xe9a/0x1690 [] Read of size 8 at addr ffff88800a7afb40 by task bash/1397 ... [] The buggy address belongs to stack of task bash/1397 [] and is located at offset 56 in frame: [] validate_region_offset+0x0/0x1c0 [cxl_core] Fixes: c3dd67681c70 ("cxl/region: Add inject and clear poison by region offset") Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-10-14cxl: Fix match_region_by_range() to use region_res_match_cxl_range()Dave Jiang
match_region_by_range() is not using the helper function that also takes extended linear cache size into account when comparing regions. This causes a x2 region to show up as 2 partial incomplete regions rather than a single CXL region with extended linear cache support. Replace the open coded compare logic with the proper helper function for comparison. User visible impact is that when 'cxl list' is issued, no activa CXL region(s) are shown. There may be multiple idle regions present. No actual active CXL region is present in the kernel. [dj: Fix stable address] Fixes: 0ec9849b6333 ("acpi/hmat / cxl: Add extended linear cache support for CXL") Cc: stable@vger.kernel.org Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-10-14cxl: Set range param for region_res_match_cxl_range() as constDave Jiang
The function takes two parameters and compares them. The second parameter should be const since no modification should be done to it. Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-10-14cxl/acpi: Fix setup of memory resource in cxl_acpi_set_cache_size()Dave Jiang
In order to compare the resource against the HMAT memory target, the resource needs to be memory type. Change the DEFINE_RES() macro to DEFINE_RES_MEM() in order to set the correct resource type. hmat_get_extended_linear_cache_size() uses resource_contains() internally. This causes a regression for platforms with the extended linear cache enabled as the comparison always fails and the cache size is not set. User visible impact is that when 'cxl list' is issued, a CXL region with extended linear cache support will only report half the size of the actual size. And this also breaks MCE reporting of the memory region due to incorrect offset calculation for the memory. [dj: Fixup commit log suggested by djbw] [dj: Fixup stable address for cc] Fixes: 12b3d697c812 ("cxl: Remove core/acpi.c and cxl core dependency on ACPI") Cc: stable@vger.kernel.org Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-10-14eth: fbnic: fix various typos in comments and stringsAlok Tiwari
Fix several minor typos and grammatical errors in comments and log (in fbnic firmware, PCI, and time modules) Changes include: - "cordeump" -> "coredump" - "of" -> "off" in RPC config comment - "healty" -> "healthy" in firmware heartbeat comment - "Firmware crashed detected!" -> "Firmware crash detected!" - "The could be caused" -> "This could be caused" - "lockng" -> "locking" in fbnic_time.c Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251013160507.768820-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-10-14accel/qaic: Support the new READ_DATA implementationJeff Hugo
AIC200 uses the newer "XBL" firmware implementation which changes the expectations of how READ_DATA is performed. Larger data requests are supported via streaming the data over the transport instead of requiring a single transport transfer for everything. Co-developed-by: Carl Vanderlip <quic_carlv@quicinc.com> Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007224045.605374-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14accel/qaic: Ensure entry belongs to DBC in qaic_perf_stats_bo_ioctl()Youssef Samir
struct qaic_perf_stats is defined to have a DBC specified in the header, followed by struct qaic_perf_stats_entry instances, each pointing to a BO that is associated with the DBC. Currently, qaic_perf_stats_bo_ioctl() does not check if the entries belong to the DBC specified in the header. Therefore, add checks to ensure that each entry in the request is sliced and belongs to hdr.dbc_id. Co-developed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Youssef Samir <quic_yabdulra@quicinc.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007221212.559474-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14Merge tag 'for-linus-6.18-2' of https://github.com/cminyard/linux-ipmiLinus Torvalds
Pull IPMI fixes from Corey Minyard: "A few bug fixes for patches that went in this release: a refcount error and some missing or incorrect error checks" * tag 'for-linus-6.18-2' of https://github.com/cminyard/linux-ipmi: ipmi: Fix handling of messages with provided receive message pointer mfd: ls2kbmc: check for devm_mfd_add_devices() failure mfd: ls2kbmc: Fix an IS_ERR() vs NULL check in probe()
2025-10-14accel/qaic: Use overflow check function instead of divisionCarl Vanderlip
Division is an expensive operation. Overflow check functions exist already. Use existing overflow check functions rather than dividing to check for overflow. Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007174218.469867-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14nvme-auth: update sc_c in host responseMartin George
The sc_c field is currently not updated in the host response to the controller challenge leading to failures while attempting secure channel concatenation. Fix this by adding a new sc_c variable to the dhchap queue context structure which is appropriately set during negotiate and then used in the host response. Fixes: e88a7595b57f ("nvme-tcp: request secure channel concatenation") Signed-off-by: Martin George <marting@netapp.com> Signed-off-by: Prashanth Adurthi <prashana@netapp.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-10-14accel/qaic: Fix incorrect error return pathAswin Venkatesan
Found via code inspection that when encode_message() fails in the middle of processing, instead of returning the actual error code, it always returns -EINVAL. This is because the entire message length has not been processed, and the error code is set to -EINVAL. Instead, take the 'out' path on failure to return the actual error code. Signed-off-by: Aswin Venkatesan <aswivenk@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007170130.445878-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14remoteproc: imx_rproc: Use devm_rproc_add() helperPeng Fan
Replace manual rproc_add() and cleanup logic with devm_rproc_add(), which ties the remoteproc lifecycle to the device's lifecycle. This simplifies error handling and ensures proper cleanup. With no need to invoke rproc_del(), the remove() ops could be removed. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-6-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-14remoteproc: imx_rproc: Use devm_add_action_or_reset() for scu cleanupPeng Fan
Replace the explicit call to imx_rproc_put_scu() in the remove path with devm_add_action_or_reset(). Ensure proper cleanup of scu resources and simplify the code by leveraging the device-managed resource framework. Additionally: - Remove the IMX_RPROC_SCU_API check from imx_rproc_put_scu(), as devm_add_action_or_reset() now exclusively handles SCU cleanup. - Improve error reporting by using dev_err_probe() for consistency and clarity. - Drop the err_put_scu label, as it is now redundant due to the updated error handling approach. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-5-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-14remoteproc: imx_rproc: Use devm_clk_get_enabled() and simplify cleanupPeng Fan
Replace separate calls to devm_clk_get() and clk_prepare_enable() with devm_clk_get_enabled(), which combines clock acquisition and enabling into a single managed step. Simplify the probe logic and remove the need for manual clock disable in error and remove paths. Also, update error handling to eliminate redundant cleanup steps and use return-based error propagation where appropriate. Improve code clarity and reduce the chance of resource leaks or incorrect ordering in cleanup paths. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-4-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-14remoteproc: imx_rproc: Use devm_add_action_or_reset() for mailbox cleanupPeng Fan
Convert imx_rproc_free_mbox() to a devm-managed cleanup action using devm_add_action_or_reset(). Ensure the mailbox resources are freed automatically with the device lifecycle, simplify error handling and removing the need for manual cleanup in probe and remove paths. Also improve error reporting by using dev_err_probe() for consistency and clarity. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-3-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-14accel/qaic: Remove redundant retry_count = 0 statementYoussef Samir
If msg_xfer() is called and the channel ring does not have enough room to accommodate the whole message, the function sleeps and tries again. It uses retry_count to keep track of the number of retrials done. This variable is not used after the space check succeeds. So, remove the retry_count = 0 statement used later in the function. Signed-off-by: Youssef Samir <quic_yabdulra@quicinc.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007161148.422744-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14remoteproc: imx_rproc: Use devm_add_action_or_reset() for workqueue cleanupPeng Fan
Replace manual destroy_workqueue() calls in error and remove paths with a devm_add_action_or_reset() helper. Ensure the workqueue is properly cleaned up with the device lifecycle, and simplify error handling in probe by removing now-unnecessary labels and cleanup steps. No functional changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-2-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-14remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove pathPeng Fan
Proper cleanup should be done when rproc_add() fails by invoking both pm_runtime_disable() and pm_runtime_put_noidle() to avoid leaving the device in an inconsistent power state. Fix it by adding pm_runtime_put_noidle() and pm_runtime_disable() in the error path. Also Update the remove() callback to use pm_runtime_put_noidle() instead of pm_runtime_put(), to clearly indicate that only need to restore the usage count. Fixes: a876a3aacc43 ("remoteproc: imx_rproc: detect and attach to pre-booted remote cores") Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Hiago De Franco <hiago.franco@toradex.com> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250926-imx_rproc_v3-v3-1-4c0ec279cc5f@nxp.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2025-10-14accel/qaic: Synchronize access to DBC request queue head & tail pointerPranjal Ramajor Asha Kanojiya
Two threads of the same process can potential read and write parallelly to head and tail pointers of the same DBC request queue. This could lead to a race condition and corrupt the DBC request queue. Fixes: ff13be830333 ("accel/qaic: Add datapath") Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> [jhugo: Add fixes tag] Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007061837.206132-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14accel/qaic: Include signal.h in qaic_control.cZack McKevitt
Include linux/sched/signal.h in qaic_control.c to avoid implicit inclusion of signal_pending(). Signed-off-by: Zack McKevitt <zmckevit@qti.qualcomm.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007154525.415039-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-14drm/xe/sriov: Disable SR-IOV if primary GT is disabled via configfsMatt Roper
SR-IOV operation relies on the primary GT's GuC to operate (in both PF and VF mode). Don't enable the .has_sriov flag if the primary-GT was disabled by configfs. v2: - Move handling to xe_info_init(). (Michal) v3: - Just update the .has_sriov flag in xe_info_init_early(). (Michal) v4: - Drop unnecessary comment. (Michal) - Flip condition order for consistency with other checks. (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-48-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/configfs: Add attribute to disable GT typesMatt Roper
Preventing the driver from initializing GTs of specific type(s) can be useful for debugging and early hardware bringup. Add a configfs attribute to allow this kind of control for debugging. With today's platforms and software design, this configuration setting is only effective for disabling the media GT since the driver currently requires that there always be a primary GT to probe the device. However this might change in the future --- in theory it should be possible (with some additional driver work) to allow an igpu device to come up with only the media GT and no primary GT. Or to allow an igpu device to come up with no GTs at all (for display-only usage). A primary GT will likely always be required on dgpu platforms because we rely on the BCS engines inside the primary GT for various vram operations. v2: - Expand/clarify kerneldoc for configfs attribute. (Gustavo) - Tighten type usage in gt_types[] structure. (Gustavo) - Adjust string parsing/name matching to match exact GT names and not accept partial names. (Gustavo) v3: - Switch to scope-based cleanup in gt_types_allowed_store() to fix a leak if the device is already bound. (Gustavo) - Switch configfs lookup interface to two boolean functions that specify whether primary/media are supported rather than one function that returns a mask. This is simpler to use and understand. v4: - Rename xe_configfs_*_gt_supported to xe_configfs_*_gt_allowed for consistency with configfs interface and other functions. (Gustavo) - Simplify boolean check in xe_configfs_*_gt_allowed. (Michal) - Use xe_info() for message printing. (Michal) - Use guard() instead of scoped_guard(). (Michal) - Make new functions take 'struct pci_dev' for consistency with other configfs lookup functions. (Michal) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-47-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Break GT setup out of xe_info_init()Matt Roper
xe_info_init() is getting a bit long and hard to follow. Break the allocation and basic initialization of the xe_gt structures out to their own functions. v2: - Rename new functions from init_* to alloc_*. (Gustavo) - Move early NULL return of media GT before allocation. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-46-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Don't check BIOS-disabled FlatCCS if primary GT is disabledMatt Roper
If the primary is GT is disabled via configfs, we can't read the GT registers that would tell us whether the BIOS has disabled FlatCCS on a platform that would otherwise have it; we'll just proceed as if the FlatCCS is still enabled. This is similar to the situation seen by SRIOV VFs and doesn't cause any functional problems since the hardware will simply drop writes to the CCS region and reads will always come back as 0 (indicating uncompressed data). We'll simply miss out on the chance to avoid some unnecessary overhead during BO creation and migration. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-45-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Check that GT is not NULL before testing Wa_16023588340Matt Roper
If the primary GT is disabled, skip the check for this workaround (which only applies to dgpu platforms where the primary GT cannot be NULL). Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-44-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Correct lineage for Wa_22014953428 and only check with valid GTMatt Roper
Wa_22014953428 was incorrectly labelled with a release-specific ID number rather than the cross-platform lineage number; fix that. Also check that the GT is not NULL before trying to lookup the workaround in it. Since this workaround only applies to DG2 discrete GPUs (where the primary GT cannot be disabled), no coverage is lost. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-43-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Bypass Wa_14018094691 when primary GT is disabledMatt Roper
Don't try to lookup Wa_14018094691 on a NULL GT when the primary GT is disabled. Since this whole workaround centers around mid-thread preemption behavior, the workaround isn't relevant if the primary GT (where the engines that can do MTP live) is disabled. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-42-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/rtp: Pass xe_device parameter to FUNC matchesMatt Roper
FUNC matches in RTP only pass the GT and hwe, preventing them from being used effectively in device workarounds. Add an additional xe_device parameter so that we can use them in device workarounds where a GT may not be available. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-41-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Handle Wa_22010954014 and Wa_14022085890 as device workaroundsMatt Roper
When Wa_22010954014 and Wa_14022085890 were first implemented, we didn't have a device workaround infrastructure so we hacked them into the GT workaround list. Now that we have proper device workaround support, move them to the proper place. Note that Wa_14022085890 specifically applies to BMG-G21 platforms, so this requires defining a BMG subplatform to capture the correct subset of device IDs. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-40-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/irq: Don't try to lookup engine masks for non-existent primary GTMatt Roper
If the primary GT is disabled via configfs, we shouldn't try to access it to lookup BCS/CCS engine masks. For the purposes of IRQ reset (which masks & disables interrupts in an sgunit register), assume all possible instances are present. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-39-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Make display part of Wa_22019338487 a device workaroundMatt Roper
The display part of Wa_22019338487 (i.e., avoiding use of stolen memory) is using a platform test rather than an graphics/media IP test. Since this workaround is focused on non-GT uses of stolen memory, it makes sense that we'd want to still apply the workaround on affected platforms even if the GTs themselves are disabled via configfs. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-38-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Check for primary GT before looking up Wa_22019338487Matt Roper
If the primary GT is disabled via configfs, we need to make sure that we don't search for this workaround on a NULL xe_gt pointer. Since we can disable the primary GT only on igpu platforms, the media GT is the one we'd want to check anyway for this workaround. The ternary operators in ggtt_update_access_counter() were getting a bit long/complicated, so rewrite them with regular if/else statements. While we're at it, throw in a couple extra assertions to make sure that we're truly picking the expected GT according to igpu/dgpu type. v2: - Adjust indentation/wrapping; it's easier to read this with longer, unwrapped lines. (Lucas) - Tweak wording of commit message to remove ambiguity. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-37-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/pmu: Initialize PMU event types based on first available GTMatt Roper
GT ID#0 (primary GT on tile 0) may not always be available if the primary GT has been disabled via configfs. Instead use the first available GT when determining which PMU events are supported. If there are no GTs, then don't advertise any GT-related events. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-36-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe/query: Report hwconfig size as 0 if primary GT is disabledMatt Roper
The hwconfig table is part of the primary GT's GuC firmware. If the primary GT is disabled, the hwconfig is unavailable and should be reported to userspace as having size 0. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-35-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Skip L2 / TDF cache flushes if primary GT is disabledMatt Roper
If the primary GT is disabled via configfs, GT-side L2 and TD cache flushes are unnecessary since nothing is using/filling these caches. Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-34-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move primary GT allocation from xe_tile_init_early to xe_tile_initMatt Roper
During the early days of the Xe driver, there were cases where we accessed some fields in the primary GT's xe_gt structure before the GT itself was formally initialized; this required that the structure itself be allocated during xe_tile_init_early(). A lot of refactoring of the device probe has happened since that time and there's no longer a need to allocate the primary GT early. Move the allocation into xe_info_init() where GT initialization happens and where we're doing the allocation of the media GT. v2: - Only make this change after a separate patch to perform VF GMD_ID lookup with a dummy GT instead of xe_root_mmio_gt(). Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-33-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Read VF GMD_ID with a specifically-allocated dummy GTMatt Roper
SRIOV VF initialization has a bit of a chicken and egg design problem. Determining the IP version of the graphics and media IPs can't be done via direct register reads as it is on PF or native and instead requires querying the GuC. However initialization of the GT, including its GuC, needs to wait until after we know the IP versions so that the proper initialization steps for the platform/IP are followed. Currently the (somewhat hacky) solution is to manually fill out just enough fields in tile 0's primary GT structure to make it look as if the GT has been initialized so that the GuC can be partially initialized and queried to obtain the GMD_ID values. When the GT gets properly initialized during the regular flows, the hacked-up values will get overwritten as part of the general initialization flows. Rather than using tile 0's primary GT structure to hold the hacked up values for querying every GT on every tile, instead allocate a dedicated dummy structure. This will allow us to move the tile->primary_gt's allocation to a more consistent place later in the initialization flow in future patches (i.e., we shouldn't even allocate this GT structure if the GT is disabled/unavailable). It also helps ensure there can't be any accidental leakage of initialization or state between the dummy initialization for GMD_ID and the real driver initialization of the GT. v2: - Initialize gt->tile for temporary GT. (CI, Michal) - Use scope-based cleanup handler to free temp GT. (Michal) - Propagate actual error code from xe_gt_sriov_vf_bootstrap() rather than just setting IP version to 0.0 now that read_gmdid() can return an error. (Michal) v3: - Explicitly initialize gt to NULL, just in case something else gets inserted before the kzalloc() in the future. (Lucas) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-32-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-10-14drm/xe: Move 'has_flatccs' flag back to platform descriptorMatt Roper
FlatCCS presence/absence is a flag that should be tracked at the platform level rather than the IP level. FlatCCS affects the device-wide memory initialization and reservations so its effects are not confined to a single IP block or GT. This is also a trait that should be tied to the platform even if the graphics IP itself is not present (e.g., if we disable the primary GT via configfs). Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-31-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>