summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-09PCI: tegra194: Enable hardware hot reset mode in Endpoint modeVidya Sagar1-0/+2
When PCIe link goes down, hardware can retrain the link and try to link up. To enable this feature, program the APPL_CTRL register with hardware hot reset with immediate LTSSM enable mode when the controller is operating in endpoint mode. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324191000.1095768-6-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Enable DMA interruptVidya Sagar1-0/+18
Enable DMA interrupt to support Tegra PCIe DMA in both Root Port and Endpoint modes. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324191000.1095768-5-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Remove IRQF_ONESHOT flag during Endpoint interrupt registrationVidya Sagar1-1/+1
The Tegra PCIe Endpoint controller has a single interrupt line that is shared between multiple interrupt sources: 1. PCIe link state events (link up, hot reset done) 2. Configuration space events (Bus Master Enable changes) 3. DMA completion events The interrupt is currently registered with IRQF_ONESHOT, which keeps the interrupt line masked until the threaded handler completes. That blocks processing of DMA completion events (and other sources) while the threaded handler runs. Removing IRQF_ONESHOT is safe for the following reasons: 1. The hard IRQ handler (tegra_pcie_ep_hard_irq) properly acknowledges and clears all interrupt status bits in hardware before returning. This prevents interrupt storms and ensures the interrupt controller can re-enable the interrupt line immediately. 2. The follow-up commit adds handling in the hard IRQ for DMA completion events. Dropping IRQF_ONESHOT is required so the line is unmasked after the hard IRQ returns and those events can be serviced without being blocked by the threaded handler. 3. The threaded handler (tegra_pcie_ep_irq_thread) only processes link-up notifications and LTR message sending. These operations don't conflict with DMA interrupt processing and don't require the interrupt line to remain masked. This change enables both DMA driver and Endpoint controller driver to share the interrupt line without blocking each other. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324191000.1095768-4-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Calibrate pipe to UPHY for Endpoint modeVidya Sagar1-0/+3
Calibrate 'Pipe to Universal PHY(UPHY)' (P2U) for the Endpoint controller to request UPHY PLL rate change to 2.5GT/s (Gen 1) during initialization. This helps to reset stale PLL state from the previous bad link state. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324191000.1095768-3-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Assert CLKREQ# explicitly by defaultVidya Sagar1-0/+2
The Root Port's CLKREQ# signal is shared with a downstream PCIe switch and the endpoints behind it. By default, APPL_PINMUX_CLKREQ_OVERRIDE only overrides the CLKREQ# input to the controller (so REFCLK is enabled internally); it does not drive the CLKREQ# output pin low. Some PCIe switches (e.g. Broadcom PCIe Gen4) forward the Root Port's CLKREQ# to their downstream side and expect it to be driven low for REFCLK, even when the switch does not support CLK-PM or ASPM-L1SS. Without driving the output pin low, link-up can fail between the switch and endpoints. Clear APPL_PINMUX_CLKREQ_DEFAULT_VALUE so the CLKREQ# output pad is explicitly driven low. That makes the shared CLKREQ# line low on the wire and avoids link-up issues with such switches. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324191000.1095768-2-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Fix CBB timeout caused by DBI access before core power-onManikanta Maddireddy1-4/+4
When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur. Fixes: 40e2125381dc ("PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-15-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Disable L1.2 capability of Tegra234 EPVidya Sagar1-0/+19
When Tegra234 is operating in the Endpoint mode with L1.2 enabled, PCIe link goes down during L1.2 exit. This is because Tegra234 powers up UPHY PLL immediately without making sure that the REFCLK is stable. This causes UPHY PLL to fail to lock to the correct frequency and leads to link going down. There is no hardware fix for this, hence do not advertise the L1.2 capability in the Endpoint mode. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-14-mmaddireddy@nvidia.com
2026-04-09PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as wellManikanta Maddireddy1-8/+8
The ECRC (TLP digest) workaround was originally added for DesignWare version 4.90a. Tegra234 SoC has 5.00a DWC HW version, which has the same ATU TD override behaviour, so apply the workaround for 5.00a too. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-13-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Use DWC IP core versionManikanta Maddireddy2-2/+4
Tegra194 PCIe driver used custom version numbers to detect Tegra194 and Tegra234 IPs. With version detect logic added, version check results in mismatch warnings: tegra194-pcie 14100000.pcie: Versions don't match (0000562a != 3536322a) Use HW version numbers which match to PORT_LOGIC.PCIE_VERSION_OFF in Tegra194 driver to avoid these kernel warnings. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-12-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Free up Endpoint resources during remove()Vidya Sagar1-0/+2
Free up the resources during remove() that were acquired by the DesignWare driver for the Endpoint mode during probe(). Fixes: bb617cbd8151 ("PCI: tegra194: Clean up the exit path for Endpoint mode") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-11-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Allow system suspend when the Endpoint link is not upVidya Sagar1-6/+25
Host software initiates the L2 sequence. PCIe link is kept in L2 state during suspend. If Endpoint mode is enabled and the link is up, the software cannot proceed with suspend. However, when the PCIe Endpoint driver is probed, but the PCIe link is not up, Tegra can go into suspend state. So, allow system to suspend in this case. Fixes: de2bbf2b71bb ("PCI: tegra194: Don't allow suspend when Tegra PCIe is in EP mode") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-10-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Set LTR message request before PCIe link up in Endpoint modeVidya Sagar1-9/+9
LTR message should be sent as soon as the Root Port enables LTR in the Endpoint mode. So set snoop and no-snoop LTR timing and LTR message request before the PCIe link comes up, so that the LTR message is sent upstream as soon as LTR is enabled. Without programming these values, the Endpoint would send latencies of 0 to the host, which will be inaccurate. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-9-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Disable direct speed change for Endpoint modeVidya Sagar1-0/+4
Pre-silicon simulation showed the controller operating in Endpoint mode initiating link speed change after completing Secondary Bus Reset. Ideally, the Root Port or the Switch Downstream Port should initiate the link speed change post SBR, not the Endpoint. So, as per the hardware team recommendation, disable direct speed change for the Endpoint mode to prevent it from initiating speed change after the physical layer link is up at Gen1, leaving speed change ownership with the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-8-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select"Vidya Sagar1-3/+3
The GPIO DT property "nvidia,refclk-select", to select the PCIe reference clock is optional. Use devm_gpiod_get_optional() to get it. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-7-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Disable PERST# IRQ only in Endpoint modeManikanta Maddireddy1-1/+2
The PERST# GPIO interrupt is only registered when the controller is operating in Endpoint mode. In Root Port mode, the PERST# GPIO is configured as an output to control downstream devices, and no interrupt is registered for it. Currently, tegra_pcie_dw_stop_link() unconditionally calls disable_irq() on pex_rst_irq, which causes issues in Root Port mode where this IRQ is not registered. Fix this by only disabling the PERST# IRQ when operating in Endpoint mode, where the interrupt is actually registered and used to detect PERST# assertion/deassertion from the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-6-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Don't force the device into the D0 state before L2Vidya Sagar1-41/+0
As per PCIe CEM r6.0, sec 2.3, the PCIe Endpoint device should be in D3cold to assert WAKE# pin. The previous workaround that forced downstream devices to D0 before taking the link to L2 cited PCIe r4.0, sec 5.2, "Link State Power Management"; however, that spec does not explicitly require putting the device into D0 and only indicates that power removal may be initiated without transitioning to D3hot. Remove the D0 workaround so that Endpoint devices can use wake functionality (WAKE# from D3). With some Endpoints the link may not enter L2 when they remain in D3, but the Root Port continues with the usual flow after PME timeout, so there is no functional issue. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-5-mmaddireddy@nvidia.com
2026-04-09PCI: tegra194: Disable LTSSM after transition to Detect on surprise link downManikanta Maddireddy1-13/+16
After the link reaches a Detect-related LTSSM state, disable LTSSM so it does not keep toggling between Polling and Detect. Do this by polling for the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert(). Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-4-mmaddireddy@nvidia.com
2026-04-09Merge tag 'drm-rust-next-2026-04-06' of ↵Dave Airlie5-58/+91
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.1-rc1 (2nd) Nova (Core): - Don't create intermediate (mutable) references to the whole command queue buffer, which is potential undefined behavior. - Add missing padding to the falcon firmware DMA buffer to prevent DMA transfers going out of range of the DMA buffer. - Actually set the default values in the bitfield Default implementation. - Use u32::from_le_bytes() instead of manual bit shifts to parse the PCI ROM header. - Fix a missing colon in the SEC2 boot debug message. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DHN5GMSIBKO2.2AYOLXDU4X19S@kernel.org
2026-04-09Merge tag 'ath-next-20260408' of ↵Johannes Berg4-3/+25
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v7.1 (PR #4) Add support for an ath10k device-tree quirk to skip host cap QMI requests. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-09hfsplus: fix generic/642 failureViacheslav Dubeyko1-12/+20
The xfstests' test-case generic/642 finishes with corrupted HFS+ volume: sudo ./check generic/642 [sudo] password for slavad: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #26 SMP PREEMPT_DYNAMIC Mon Mar 23 17:24:32 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/642 6s ... _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent (see xfstests-dev/results//generic/642.full for details) Ran: generic/642 Failures: generic/642 Failed 1 of 1 tests sudo fsck.hfs -d /dev/loop51 ** /dev/loop51 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. invalid free nodes - calculated 1637 header 1260 Invalid B-tree header Invalid map node (8, 0) ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0xc000 EBTStat = 0x0000 CBTStat = 0x0000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled was repaired successfully. The fsck tool detected that Extended Attributes b-tree is corrupted. Namely, the free nodes number is incorrect and map node bitmap has inconsistent state. Analysis has shown that during b-tree closing there are still some lost b-tree's nodes in the hash out of b-tree structure. But this orphaned b-tree nodes are still accounted as used in map node bitmap: tree_cnid 8, nidx 0, node_count 1408, free_nodes 1403 tree_cnid 8, nidx 1, node_count 1408, free_nodes 1403 tree_cnid 8, nidx 3, node_count 1408, free_nodes 1403 tree_cnid 8, nidx 54, node_count 1408, free_nodes 1403 tree_cnid 8, nidx 67, node_count 1408, free_nodes 1403 tree_cnid 8, nidx 0, prev 0, next 0, parent 0, num_recs 3, type 0x1, height 0 tree_cnid 8, nidx 1, prev 0, next 0, parent 3, num_recs 1, type 0xff, height 1 tree_cnid 8, nidx 3, prev 0, next 0, parent 0, num_recs 1, type 0x0, height 2 tree_cnid 8, nidx 54, prev 29, next 46, parent 3, num_recs 0, type 0xff, height 1 tree_cnid 8, nidx 67, prev 8, next 14, parent 3, num_recs 0, type 0xff, height 1 This issue happens in hfs_bnode_split() logic during detection the possibility of moving half ot the records out of the node. The hfs_bnode_split() contains a loop that implements a roughly 50/50 split of the B-tree node's records by scanning the offset table to find where the data crosses the node's midpoint. If this logic detects the incapability of spliting the node, then it simply calls hfs_bnode_put() for newly created node. However, node is not set as HFS_BNODE_DELETED and real deletion of node doesn't happen. As a result, the empty node becomes orphaned but it is still accounted as used. Finally, fsck tool detects this inconsistency of HFS+ volume. This patch adds call of hfs_bnode_unlink() before hfs_bnode_put() for the case if new node cannot be used for spliting the existing node. sudo ./check generic/642 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.0.0-rc1+ #26 SMP PREEMPT_DYNAMIC Fri Apr 3 12:39:13 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/642 40s ... 39s Ran: generic/642 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/242 cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-6-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-04-09hfsplus: rework logic of map nodes creation in xattr b-treeViacheslav Dubeyko2-23/+106
In hfsplus_init_header_node() when node_count > 63488 (header bitmap capacity), the code calculates map_nodes, subtracts them from free_nodes, and marks their positions used in the bitmap. However, it doesn't write the actual map node structure (type, record offsets, bitmap) for those physical positions, only node 0 is written. This patch reworks hfsplus_create_attributes_file() logic by introducing a specialized method of hfsplus_init_map_node() and writing the allocated map b-tree's nodes by means of hfsplus_write_attributes_file_node() method. cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-5-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-04-09hfsplus: fix logic of alloc/free b-tree nodeViacheslav Dubeyko1-0/+3
The hfs_bmap_alloc() and hfs_bmap_free() modify the b-tree's counters and nodes' bitmap of b-tree. However, hfs_btree_write() synchronizes the state of in-core b-tree's counters and node's bitmap with b-tree's descriptor in header node. Postponing this synchronization could result in inconsistent state of file system volume. This patch adds calling of hfs_btree_write() in hfs_bmap_alloc() and hfs_bmap_free() methods. cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-4-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-04-09hfsplus: fix error processing issue in hfs_bmap_free()Viacheslav Dubeyko1-5/+9
Currently, we check only -EINVAL error code in hfs_bmap_free() after calling the hfs_bmap_clear_bit(). It means that other error codes will be silently ignored. This patch adds the checking of all other error codes. cc: Shardul Bankar <shardul.b@mpiricsoftware.com> cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-3-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-04-09hfsplus: fix potential race conditions in b-tree functionalityViacheslav Dubeyko4-8/+18
The HFS_BNODE_DELETED flag is checked in hfs_bnode_put() under locked tree->hash_lock. This patch adds locking for the case of setting the HFS_BNODE_DELETED flag in hfs_bnode_unlink() with the goal to avoid potential race conditions. The hfs_btree_write() method should be called under tree->tree_lock. This patch reworks logic by adding locking the tree->tree_lock for the calls of hfs_btree_write() in hfsplus_cat_write_inode() and hfsplus_system_write_inode(). This patch adds also the lockdep_assert_held() in hfs_bmap_reserve(), hfs_bmap_alloc(), and hfs_bmap_free(). cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260403230556.614171-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-04-08Merge tag 'hid-for-linus-2026040801' of ↵Linus Torvalds12-1/+46
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - handling of new keycodes for contextual AI usages (Akshai Murari) - fix for UAF in hid-roccat (Benoît Sevens) - deduplication of error logging in amd_sfh (Maximilian Pezzullo) - various device-specific quirks and device ID additions (Even Xu, Lode Willems, Leo Vriska) * tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: Input: add keycodes for contextual AI usages (HUTRR119) HID: Kysona: Add support for VXE Dragonfly R1 Pro HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3 HID: roccat: fix use-after-free in roccat_report_event HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs HID: Intel-thc-hid: Intel-quicki2c: Add NVL Device IDs
2026-04-08PCI: tegra194: Increase LTSSM poll time on surprise link downManikanta Maddireddy1-15/+21
On surprise link down, LTSSM state transits from L0 -> Recovery.RcvrLock -> Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so the total time from L0 to Detect is ~96 ms. Increase the poll timeout to 120 ms to account for this. While at it, add LTSSM state defines for Detect-related states and use them in the poll condition. Use readl_poll_timeout() instead of readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path runs in non-atomic context. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Fix polling delay for L2 stateVidya Sagar1-5/+4
As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is polling for 10 msec with 1 usec delay which is aggressive. Use existing macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay. Since this function is used in non-atomic context only, use non-atomic poll function. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com
2026-04-08tracing: Report ipi_raise target CPUs as cpumaskCaoRuichuang1-3/+3
Bugzilla 217447 points out that ftrace bitmask fields still use the legacy dynamic-array format, which makes trace consumers treat them as unsigned long arrays instead of bitmaps. This is visible in the ipi events today: ipi_send_cpumask already reports its CPU mask as '__data_loc cpumask_t', but ipi_raise still exposes target_cpus as '__data_loc unsigned long[]'. Switch ipi_raise to __cpumask() and the matching helpers so its tracefs format matches the existing cpumask representation used by the other ipi event. The underlying storage size stays the same, but trace data consumers can now recognize the field as a cpumask directly. Link: https://patch.msgid.link/20260406162434.40767-1-create0818@163.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=217447 Signed-off-by: CaoRuichuang <create0818@163.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-04-08x86: shadow stacks: proper error handling for mmap lockLinus Torvalds2-4/+5
김영민 reports that shstk_pop_sigframe() doesn't check for errors from mmap_read_lock_killable(), which is a silly oversight, and also shows that we haven't marked those functions with "__must_check", which would have immediately caught it. So let's fix both issues. Reported-by: 김영민 <osori@hspace.io> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Dave Hansen <dave.hansen@intel.com> Acked-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-04-08tracefs: Fix default permissions not being applied on initial mountDavid Carlier1-0/+1
Commit e4d32142d1de ("tracing: Fix tracefs mount options") moved the option application from tracefs_fill_super() to tracefs_reconfigure() called from tracefs_get_tree(). This fixed mount options being ignored on user-space mounts when the superblock already exists, but introduced a regression for the initial kernel-internal mount. On the first mount (via simple_pin_fs during init), sget_fc() transfers fc->s_fs_info to sb->s_fs_info and sets fc->s_fs_info to NULL. When tracefs_get_tree() then calls tracefs_reconfigure(), it sees a NULL fc->s_fs_info and returns early without applying any options. The root inode keeps mode 0755 from simple_fill_super() instead of the intended TRACEFS_DEFAULT_MODE (0700). Furthermore, even on subsequent user-space mounts without an explicit mode= option, tracefs_apply_options(sb, true) gates the mode behind fsi->opts & BIT(Opt_mode), which is unset for the defaults. So the mode is never corrected unless the user explicitly passes mode=0700. Restore the tracefs_apply_options(sb, false) call in tracefs_fill_super() to apply default permissions on initial superblock creation, matching what debugfs does in debugfs_fill_super(). Cc: stable@vger.kernel.org Fixes: e4d32142d1de ("tracing: Fix tracefs mount options") Link: https://patch.msgid.link/20260404134747.98867-1-devnexen@gmail.com Signed-off-by: David Carlier <devnexen@gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-04-08bpf: Add fix for Trust Philips SPK6327 (145f:024b) modifier keysmuhammed Rishal1-0/+49
The Trust Philips SPK6327 keyboard (USB ID 145f:024b) has a broken HID descriptor on interface 1. Byte 101 is 0x00 (Input Array) but should be 0x02 (Input Variable), causing LCtrl, LAlt, Super, RAlt, RCtrl and RShift to all report as LShift on Linux. This BPF fix patches byte 101 at runtime fixing all affected modifier keys. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/234 Signed-off-by: muhammed Rishal <muhammedrishal7777777@gmail.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: Add support for the Huion KeyDial K20 over bluetoothBenjamin Tissoires1-0/+492
When connected over bluetooth this device is just different enough that forcing it into the same source file as the USB connection doesn't gain us much benefit. So let's duplicate this. Code and tests originally produced by Claude code. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/work_items/69 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/201 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: add a BPF to get the touchpad typeBenjamin Tissoires1-0/+90
Currently the kernel is scheduled to do this call by itself, but it requires a kernel v6.18 at least to have the INPUT_PROP set. For older kernels, we can try to query the property from a HID-BPF probe, and set a udev property based on that. This way we can provide the information to old kernels without modifying them. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/220 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08hid: bpf: hid_bpf_helpers: add helper for having read/write udev propertiesBenjamin Tissoires1-0/+38
We want udev-hid-bpf to be able to set udev properties by printing them out after the BPF object has been loaded. This allows to make a query to the device, and set a udev prop based on the answer. Because the way udev works, the properties are cleared on bind/unbind, and we need a way to store them. After several attempts to keep the property alive without re-running the udev-hid-bpf tool to communicate with the device, it came out that HID-BPF maps are pinned in the bpffs and we can then query them. So the following would export a UDEV property in the bpffs: EXPORT_UDEV_PROP(HID_FOO, 32); SEC("syscall") int probe(struct hid_bpf_probe_args *ctx) { const char *foo = "foo"; UDEV_PROP_SPRINTF(HID_FOO, "%s", foo); return 0; } Then, we can debug it with a simple cat: sudo cat /sys/fs/bpf/hid/.../UDEV_PROP_HID_FOO 0: {['f','o','o',],} This way, the property is always accessible without talking to the device Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/220 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: handle injected report descriptor in HID-BPFBenjamin Tissoires3-0/+3026
udev-hid-bpf is now capable of injecting the parsed report descriptor in the program. Provide the macros required for it. Sync up from udev-hid-bpf commits: bpf: inject the parsed report descriptor in HID_REPORT_DESCRIPTOR hid_bpf_helpers: provide iterator macros for walking the HID report descriptor hid_bpf_helpers: Add extract_bits function bpf: add hid_usages.h bpf: move the report descriptor structs into their own header Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/228 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: add helper macros for LE/BE conversionPeter Hutterer1-0/+67
BPF has bpf_htons and friends but those only work with data in Big Endian format. HID is little endian so we need our own macros. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: hid_bpf_helpers: provide a cleanup functionsBenjamin Tissoires2-18/+98
Combination of 2 udev-hid-bpf commits: bpf: hid_bpf_helpers: provide a cleanup function for hid_bpf_release_context bpf: helpers: add guard(bpf_spin) macro Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: fix some signed vs unsigned compiler warningsPeter Hutterer4-4/+5
On udev-hid-bpf, we are now getting warnings here, shut them off. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/227 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08selftests: pci_endpoint: Skip BAR subrange test on -ENOSPCChristian Bruel3-1/+7
In pci-epf-test.c, set the STATUS_NO_RESOURCE status bit if pci_epc_set_bar() returns -ENOSPC. This status bit is used to indicate that there are not enough inbound window resources to allocate the subrange. In pci_endpoint_test.c, return -ENOSPC instead of -EIO when STATUS_NO_RESOURCE is set. In pci_endpoint_test.c, skip the BAR subrange test if -ENOSPC, i.e., there are not enough inbound window resources to run the test. Signed-off-by: Christian Bruel <christian.bruel@foss.st.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: squash related commits] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260407-skip-bar_subrange-tests-if-enospc-v4-1-6f2e65f2298c@foss.st.com Link: https://patch.msgid.link/20260407-skip-bar_subrange-tests-if-enospc-v4-2-6f2e65f2298c@foss.st.com Link: https://patch.msgid.link/20260407-skip-bar_subrange-tests-if-enospc-v4-3-6f2e65f2298c@foss.st.com
2026-04-08io_uring: unify getting ctx from passed in file descriptorJens Axboe6-58/+40
io_uring_enter() and io_uring_register() end up having duplicated code for getting a ctx from a passed in file descriptor, for either a registered ring descriptor or a normal file descriptor. Move the io_uring_register_get_file() into io_uring.c and name it a bit more generically, and use it from both callsites rather than have that logic and handling duplicated. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-08io_uring/register: don't get a reference to the registered ring fdJens Axboe2-5/+6
This isn't necessary and was only done because the register path isn't a hot path and hence the extra ref/put doesn't matter, and to have the exit path be able to unconditionally put whatever file was gotten regardless of the type. In preparation for sharing this code with the main io_uring_enter(2) syscall, drop the reference and have the caller conditionally put the file if it was a normal file descriptor. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-08io_uring/tctx: clean up __io_uring_add_tctx_node() error handlingJens Axboe1-20/+40
Refactor __io_uring_add_tctx_node() so that on error it never leaves current->io_uring pointing at a half-setup tctx. This moves the assignment of current->io_uring to the end of the function post any failure points. Separate out the node installation into io_tctx_install_node() to further clean this up. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-08io_uring/tctx: have io_uring_alloc_task_context() return tctxJens Axboe3-14/+19
Instead of having io_uring_alloc_task_context() return an int and assign tsk->io_uring, just have it return the task context directly. This enables cleaner error handling in callers, which may have failure points post calling io_uring_alloc_task_context(). Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-08nvmet-tcp: remove redundant calls to nvmet_tcp_fatal_error()Maurizio Lombardi1-30/+7
Executing nvmet_tcp_fatal_error() is generally the responsibility of the caller (nvmet_tcp_try_recv); all other functions should just return the error code. Remove the nvmet_tcp_fatal_error() function, it's not needed anymore. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callersMaurizio Lombardi1-22/+29
Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. Fixes: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec") Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Yunje Shin <ioerts@kookmin.ac.kr> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08ASoC: dt-bindings: hisilicon: Convert hi6210 I2S to dt-schemaChaitanya Sabnis2-42/+80
Convert the Hisilicon hi6210 I2S controller hardware binding from legacy plain text to modern YAML dt-schema format. During the conversion, the order of the dma-names properties in the example was corrected to "tx", "rx" to match the official property description, resolving a contradiction in the original text binding. Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260327092106.4233-1-chaitanya.msabnis@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-08ASoC: tas2781: Explicit association of Device, Device Name, and Device IDShenghao Ding1-53/+51
By correlating devices with their names and IDs, the driver becomes more discoverable. Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20260406103131.1883-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-08perf maps: Fix copy_from that can break sorted by name orderIan Rogers1-10/+3
When an parent is copied into a child the name array is populated in address not name order. Make sure the name array isn't flagged as sorted. Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-04-08perf maps: Fix fixup_overlap_and_insert that can break sorted by name orderIan Rogers1-0/+2
When an entry in the address array is replaced, the corresponding name entry is replaced. The entries names may sort differently and so it is important that the sorted by name property be cleared on the maps. Fixes: 0d11fab32714 ("perf maps: Fixup maps_by_name when modifying maps_by_address") Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-04-08perf maps: Move getting debug_file to verbose pathIan Rogers1-5/+4
Getting debug_file can trigger warnings if not set. Avoid getting these warnings by pushing the use under the controlling if. Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-28 21:12:01 +0300