summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-09selftests/bpf: Add test to ensure kprobe_multi is not sleepableVarun R Mallya2-1/+59
Add a selftest to ensure that kprobe_multi programs cannot be attached using the BPF_F_SLEEPABLE flag. This test succeeds when the kernel rejects attachment of kprobe_multi when the BPF_F_SLEEPABLE flag is set. Suggested-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Varun R Mallya <varunrmallya@gmail.com> Link: https://lore.kernel.org/r/20260408190137.101418-3-varunrmallya@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-09bpf: Make find_linfo widely availableKumar Kartikeya Dwivedi3-42/+39
Move find_linfo() as bpf_find_linfo() into core.c to allow for its use in the verifier in subsequent patches. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://lore.kernel.org/r/20260408021359.3786905-4-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-09bpf: Extract bpf_get_linfo_file_lineKumar Kartikeya Dwivedi2-8/+23
Extract bpf_get_linfo_file_line as its own function so that the logic to obtain the file, line, and line number for a given program can be shared in subsequent patches. Reviewed-by: Puranjay Mohan <puranjay@kernel.org> Acked-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20260408021359.3786905-3-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-09ecryptfs: keep the lower iattr contained in truncate_upperChristoph Hellwig1-46/+36
Currently the two callers of truncate_upper handle passing information very differently. ecryptfs_truncate passes a zeroed lower_ia and expects truncate_upper to fill it in from the upper ia created just for that, while ecryptfs_setattr passes a fully initialized lower_ia copied from the upper one. Both of them then call notify_change on the lower_ia. Switch to only passing the upper ia, and derive the lower ia from it inside truncate_upper, and call notify_change inside the function itself. Because the old name is misleading now, rename the resulting function to __ecryptfs_truncate as it deals with both the lower and upper inodes. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09ecryptfs: factor out a ecryptfs_iattr_to_lower helperChristoph Hellwig1-9/+15
Prepare for using the code to create a lower struct iattr in multiple places. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09ecryptfs: merge ecryptfs_inode_newsize_ok into truncate_upperChristoph Hellwig1-35/+17
Both callers of ecryptfs_inode_newsize_ok call truncate_upper right after. Merge ecryptfs_inode_newsize_ok into truncate_upper to simplify the logic. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09ecryptfs: combine the two ATTR_SIZE blocks in ecryptfs_setattrChristoph Hellwig1-5/+4
Simplify the logic in ecryptfs_setattr by combining the two ATTR_SIZE blocks. This initializes lower_ia before the size check, which is obviously correct as the size check doesn't look at it. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09ecryptfs: use ZERO_PAGE instead of allocating zeroed memory in truncate_upperChristoph Hellwig1-9/+2
Use the existing pre-zeroed memory instead of allocating a new chunk. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09ecryptfs: streamline truncate_upperChristoph Hellwig1-55/+60
Use a few strategic gotos to reduce indentation and keep the main flow outside of branches. Switch all touched comments to normal kernel style and avoid breaks in printed strings for all the code touched. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09ecryptfs: cleanup ecryptfs_setattrChristoph Hellwig1-12/+10
Initialize variables at declaration time where applicable and reformat conditionals to match the kernel coding style. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tyler Hicks <code@tyhicks.com>
2026-04-09KVM: SEV: Move SEV-specific VM initialization to sev.cSean Christopherson3-11/+18
Move SEV+ VM initialization to sev.c (as sev_vm_init()) so that kvm_sev_info (and all usage) can be gated on CONFIG_KVM_AMD_SEV=y without needing more #ifdefs. As a bonus, isolating the logic will make it easier to harden the flow, e.g. to WARN if the vm_type is unknown. No functional change intended (SEV, SEV_ES, and SNP VM types are only supported if CONFIG_KVM_AMD_SEV=y). Link: https://patch.msgid.link/20260310234829.2608037-12-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09KVM: SEV: Move standard VM-scoped helpers to detect SEV+ guests to sev.cSean Christopherson2-17/+14
Now that all external usage of the VM-scoped APIs to detect SEV+ guests is gone, drop the stubs provided for CONFIG_KVM_AMD_SEV=n builds and bury the "standard" APIs in sev.c. No functional change intended. Link: https://patch.msgid.link/20260310234829.2608037-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09KVM: SEV: Document the SEV-ES check when querying SMM support as "safe"Sean Christopherson1-2/+10
Use the "unsafe" API to check for an SEV-ES+ guest when determining whether or not SMBASE is a supported MSR, i.e. whether or not emulated SMM is supported. This will eventually allow adding lockdep assertings to the APIs for detecting SEV+ VMs without triggering "real" false positives. While svm_has_emulated_msr() doesn't hold kvm->lock, i.e. can get both false positives *and* false negatives, both are completely fine, as the only time the result isn't stable is when userspace is the sole consumer of the result. I.e. userspace can confuse itself, but that's it. No functional change intended. Link: https://patch.msgid.link/20260310234829.2608037-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09KVM: SEV: Add quad-underscore version of VM-scoped APIs to detect SEV+ guestsSean Christopherson1-7/+21
Add "unsafe" quad-underscore versions of the SEV+ guest detectors in anticipation of hardening the APIs via lockdep assertions. This will allow adding exceptions for usage that is known to be safe in advance of the lockdep assertions. Use a pile of underscores to try and communicate that use of the "unsafe" shouldn't be done lightly. No functional change intended. Link: https://patch.msgid.link/20260310234829.2608037-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09KVM: SEV: Provide vCPU-scoped accessors for detecting SEV+ guestsSean Christopherson3-64/+82
Provide vCPU-scoped accessors for detecting if the vCPU belongs to an SEV, SEV-ES, or SEV-SNP VM, partly to dedup a small amount of code, but mostly to better document which usages are "safe". Generally speaking, using the VM-scoped sev_guest() and friends outside of kvm->lock is unsafe, as they can get both false positives and false negatives. But for vCPUs, the accessors are guaranteed to provide a stable result as KVM disallows initialization SEV+ state after vCPUs are created. I.e. operating on a vCPU guarantees the VM can't "become" an SEV+ VM, and that it can't revert back to a "normal" VM. This will also allow dropping the stubs for the VM-scoped accessors, as it's relatively easy to eliminate usage of the accessors from common SVM once the vCPU-scoped checks are out of the way. No functional change intended. Link: https://patch.msgid.link/20260310234829.2608037-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09KVM: SEV: Lock all vCPUs for the duration of SEV-ES VMSA synchronizationSean Christopherson1-8/+7
Lock and unlock all vCPUs in a single batch when synchronizing SEV-ES VMSAs during launch finish, partly to dedup the code by a tiny amount, but mostly so that sev_launch_update_vmsa() uses the same logic/flow as all other SEV ioctls that lock all vCPUs. Link: https://patch.msgid.link/20260310234829.2608037-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finishSean Christopherson1-4/+12
Lock all vCPUs when synchronizing and encrypting VMSAs for SNP guests, as allowing userspace to manipulate and/or run a vCPU while its state is being synchronized would at best corrupt vCPU state, and at worst crash the host kernel. Opportunistically assert that vcpu->mutex is held when synchronizing its VMSA (the SEV-ES path already locks vCPUs). Fixes: ad27ce155566 ("KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260310234829.2608037-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-04-09HID: sony: add battery status support for Rock Band 4 PS5 guitarsRosalie Wanders1-1/+39
This commit adds battery status support for Rock Band 4 PS5 guitars. The data is reported in the same way as the dualsense in hid-playstation except it's located at byte 30. Signed-off-by: Rosalie Wanders <rosalie@mailbox.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-09HID: sony: fix style issuesRosalie Wanders1-43/+34
This commit fixes inconsistent quirk names and also fixes all the checkpatch.pl issues alongside inconsistent code, it also adds static asserts to assert struct sizes at compile time. Signed-off-by: Rosalie Wanders <rosalie@mailbox.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-09HID: quirks: update hid-sony supported devicesRosalie Wanders1-7/+39
hid-sony has been updated with new device support, update the hid_have_special_driver list accordingly. Signed-off-by: Rosalie Wanders <rosalie@mailbox.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-09HID: sony: add support for more instrumentsRosalie Wanders2-47/+253
This patch adds support for the following instruments: * Rock Band 1/2/3 Wii/PS3 instruments * Rock Band 3 PS3 Pro instruments * DJ Hero Turntable Wii and PS3 instruments are the same besides the vendor and product ID. This patch also fixes the mappings for the existing Guitar Hero instruments. Co-developed-by: Sanjay Govind <sanjay.govind9@gmail.com> Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com> Co-developed-by: Brenton Simpson <appsforartists@google.com> Signed-off-by: Brenton Simpson <appsforartists@google.com> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-09PCI: tegra194: Add core monitor clock supportVidya Sagar1-0/+16
Add support for Tegra PCIe core clock monitoring. Monitoring tracks rate changes that may occur due to link speed changes and is useful for detecting core clock changes not initiated by software. Parse the monitor clock from device tree and enable it when present. 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-8-mmaddireddy@nvidia.com
2026-04-09dt-bindings: PCI: tegra194: Add monitor clock supportVidya Sagar2-2/+10
Tegra supports PCIe core clock monitoring for any rate changes that may be happening because of the link speed changes. This is useful in tracking any changes in the core clock that are not initiated by the software. 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: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324191000.1095768-7-mmaddireddy@nvidia.com
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
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 09:34:41 +0300