Le 21/07/2025 à 04:59,
huaqian.li-kv7WeFo6aLtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx a écrit :
From: Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@xxxxxxxxxxxxxxxx>
The AM654 lacks an IOMMU, thus does not support isolating DMA requests
from untrusted PCI devices to selected memory regions this way. Use
static PVU-based protection instead. The PVU, when enabled, will only
accept DMA requests that address previously configured regions.
Use the availability of a restricted-dma-pool memory region as trigger
and register it as valid DMA target with the PVU. In addition, enable
the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
VirtID so far, catching all devices.
Hi,
...
case DW_PCIE_EP_TYPE:
if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_EP)) {
@@ -1346,6 +1450,8 @@ static int ks_pcie_probe(struct platform_device *pdev)
err_ep_init:
dw_pcie_ep_deinit(&pci->ep);
+err_dma_cleanup:
+ ks_release_restricted_dma(pdev);
err_get_sync:
pm_runtime_put(dev);
pm_runtime_disable(dev);
@@ -1362,9 +1468,15 @@ static void ks_pcie_remove(struct platform_device *pdev)
{
struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
struct device_link **link = ks_pcie->link;
+ const struct ks_pcie_of_data *data;
int num_lanes = ks_pcie->num_lanes;
struct device *dev = &pdev->dev;
+ data = of_device_get_match_data(dev);
+ if (data && data->mode == DW_PCIE_RC_TYPE) {
If this test against DW_PCIE_RC_TYPE is needed in the remove function,
should the same be done in the error handling path of the probe?
If we go through "case DW_PCIE_EP_TYPE", we can end to "goto
err_ep_init" and call ks_release_restricted_dma() unconditionally.
If it is not an issue in the error handling path of the probe, then I
suppose that it can be removed from the remove function as well.
(and BTW, the extra {} could be removed)
CJ
+ ks_release_restricted_dma(pdev);
+ }
+
pm_runtime_put(dev);
pm_runtime_disable(dev);
ks_pcie_disable_phy(ks_pcie);
