kernel/linux.git/drivers/pci/endpoint/functions, branch v6.18.21

PCI: endpoint: pci-epf-test: Fix sleeping function being called from atomic context

2025-12-18T13:02:38+00:00

[ Upstream commit 25423cda145f9ed6ee4a72d9f2603ac2a4685e74 ] When Root Complex (RC) triggers a Doorbell interrupt to Endpoint (EP), it triggers the below warning in the EP: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:271 Call trace: __might_resched+0x130/0x158 __might_sleep+0x70/0x88 mutex_lock+0x2c/0x80 pci_epc_get_msi+0x78/0xd8 pci_epf_test_raise_irq.isra.0+0x74/0x138 pci_epf_test_doorbell_handler+0x34/0x50 The BUG arises because the EP's pci_epf_test_doorbell_handler() which is running in the hard IRQ context is making an indirect call to pci_epc_get_msi(), which uses mutex inside. To fix the issue, convert the hard IRQ handler to a threaded IRQ handler to allow it to call functions that can sleep during bottom half execution. Also, register the threaded IRQ handler with IRQF_ONESHOT to keep the interrupt line disabled until the threaded IRQ handler completes execution. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Bhanu Seshu Kumar Valluri [mani: reworded description a bit] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Link: https://patch.msgid.link/20251014024109.42287-1-bhanuseshukumar@gmail.com Signed-off-by: Sasha Levin

PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release

2025-09-16T06:41:04+00:00

The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data") Signed-off-by: Shin'ichiro Kawasaki [mani: trimmed the stack trace] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Damien Le Moal Reviewed-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250916025756.34807-1-shinichiro.kawasaki@wdc.com

PCI: endpoint: pci-epf-test: Fix doorbell test support

2025-09-12T20:09:32+00:00

The doorbell feature temporarily overrides the inbound translation to point to the address stored in epf_test->db_bar.phys_addr, i.e., it calls set_bar() twice without ever calling clear_bar(), as calling clear_bar() would clear the BAR's PCI address assigned by the host. Thus, when disabling the doorbell, restore the inbound translation to point to the memory allocated for the BAR. Without this, running the PCI endpoint kselftest doorbell test case more than once would fail. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20250908161942.534799-2-cassel@kernel.org

PCI: endpoint: pci-epf-test: Limit PCIe BAR size for fixed BARs

2025-09-08T19:48:55+00:00

Currently, the test allocates BAR sizes according to fixed table bar_size. This does not work with controllers which have fixed size BARs that are smaller than the requested BAR size. One such controller is Renesas R-Car V4H PCIe controller, which has BAR4 size limited to 256 bytes, which is much less than one of the BAR size, 131072 currently requested by this test. A lot of controllers drivers in-tree have fixed size BARs, and they do work perfectly fine, but it is only because their fixed size is larger than the size requested by pci-epf-test.c Adjust the test such that in case a fixed size BAR is detected, the fixed BAR size is used, as that is the only possible option. This helps with test failures reported as follows: pci_epf_test pci_epf_test.0: requested BAR size is larger than fixed size pci_epf_test pci_epf_test.0: Failed to allocate space for BAR4 Signed-off-by: Marek Vasut [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20250905184240.144431-1-marek.vasut+renesas@mailbox.org

Merge branch 'pci/endpoint/epf-vntb'

2025-07-31T21:11:46+00:00

- Return -ENOENT (not -1) if pci_epc_get_next_free_bar() fails (Jerome Brunet) - Align MW (memory window) naming with config names (Jerome Brunet) - Allow BAR assignment via configfs so platforms have flexibility in determining BAR usage (Jerome Brunet) - Drop incorrect '__iomem' annotation on the return value of pci_epf_alloc_space(); this also fixes an sparse warning (Manivannan Sadhasivam) * pci/endpoint/epf-vntb: PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute PCI: endpoint: pci-epf-vntb: Allow BAR assignment via configfs PCI: endpoint: pci-epf-vntb: Align MW naming with config names PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails

PCI: endpoint: pci-epf-test: Add doorbell test support

2025-07-24T21:51:43+00:00

Add doorbell support by allocating a dedicated BAR using the pci_epf_alloc_doorbell() API and mapping the Endpoint MSI controller message data address to it. The data to be written in the message address is stored in the 'pci_epf_test_reg::doorbell_data' register. Finally, the RC can trigger doorbell in the Endpoint by writing the content of 'doorbell_data' register to the offset specified in 'doorbell_offset' of the 'doorbell_bar' BAR. Triggering of the doorbell is detected by pci_epf_test_doorbell_handler(), which is bound to the doorbell IRQ. On successful completion, STATUS_DOORBELL_SUCCESS status is set in the above mentioned handler. To avoid breaking compatibility between host and endpoint, add two new commands: COMMAND_ENABLE_DOORBELL and COMMAND_DISABLE_DOORBELL. The doorbell is allocated when COMMAND_ENABLE_DOORBELL command is called and destroyed when COMMAND_DISABLE_DOORBELL is called. This doorbell feature only works when both RC and EP drivers support it. If one of them doesn't support the feature, the testcase will fail. Signed-off-by: Frank Li [mani: code cleanups and reworded commit message] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Niklas Cassel Link: https://patch.msgid.link/20250710-ep-msi-v21-6-57683fc7fb25@nxp.com

PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute

2025-07-21T05:58:56+00:00

__iomem attribute is supposed to be used only with variables holding the MMIO pointer. But here, 'mw_addr' variable is just holding a 'void *' returned by pci_epf_alloc_space(). So annotating it with __iomem is clearly wrong. Hence, drop the attribute. This also fixes the below sparse warning: drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: warning: incorrect type in assignment (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: expected void [noderef] __iomem *mw_addr drivers/pci/endpoint/functions/pci-epf-vntb.c:524:17: got void * drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: warning: incorrect type in assignment (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: expected unsigned int [usertype] *epf_db drivers/pci/endpoint/functions/pci-epf-vntb.c:530:21: got void [noderef] __iomem *mw_addr drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: warning: incorrect type in argument 2 (different address spaces) drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: expected void *addr drivers/pci/endpoint/functions/pci-epf-vntb.c:542:38: got void [noderef] __iomem *mw_addr Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20250709125022.22524-1-mani@kernel.org

PCI: endpoint: pci-epf-vntb: Allow BAR assignment via configfs

2025-07-09T12:36:51+00:00

The current BAR configuration for the PCI vNTB endpoint function allocates BARs in order, which lacks flexibility and does not account for platform-specific quirks. This is problematic on Renesas platforms, where BAR_4 is a fixed 256B region that ends up being used for MW1, despite being better suited for doorbells. Add new configfs attributes to allow users to specify arbitrary BAR assignments. If no configuration is provided, the driver retains its original behavior of sequential BAR allocation, preserving compatibility with existing userspace setups. This enables use cases such as assigning BAR_2 for MW1 and using the limited BAR_4 for doorbells on Renesas platforms. Signed-off-by: Jerome Brunet [mani: adjusted the indent of EPF_NTB_BAR_W, fixed kdoc & squashed bar fix] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-3-fc685a22ad28@baylibre.com

PCI: endpoint: pci-epf-vntb: Align MW naming with config names

2025-06-23T12:04:08+00:00

The config file related to the memory windows start the numbering of the MW from 1. The other NTB function does the same, yet the enumeration defining the BARs of the vNTB function starts numbering the MW from 0. Both numbering should be fine, but mixing the two is a bit confusing. The configfs file being the interface with userspace, keep that stable and consistently start the numbering of the MW from 1. Signed-off-by: Jerome Brunet [mani: commit message rewording] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-2-fc685a22ad28@baylibre.com

PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails

2025-06-23T12:03:19+00:00

According the function documentation of epf_ntb_init_epc_bar(), the function should return an error code on error. However, it returns -1 when no BAR is available i.e., when pci_epc_get_next_free_bar() fails. Return -ENOENT instead. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Jerome Brunet [mani: changed err code to -ENOENT] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-1-fc685a22ad28@baylibre.com