summaryrefslogtreecommitdiff
path: root/drivers/iommu/mtk_iommu.c
AgeCommit message (Collapse)AuthorFilesLines
2023-06-01iommu/mediatek: Flush IOTLB completely only if domain has been attachedChen-Yu Tsai1-1/+2
If an IOMMU domain was never attached, it lacks any linkage to the actual IOMMU hardware. Attempting to do flush_iotlb_all() on it will result in a NULL pointer dereference. This seems to happen after the recent IOMMU core rework in v6.4-rc1. Unable to handle kernel read from unreadable memory at virtual address 0000000000000018 Call trace: mtk_iommu_flush_iotlb_all+0x20/0x80 iommu_create_device_direct_mappings.part.0+0x13c/0x230 iommu_setup_default_domain+0x29c/0x4d0 iommu_probe_device+0x12c/0x190 of_iommu_configure+0x140/0x208 of_dma_configure_id+0x19c/0x3c0 platform_dma_configure+0x38/0x88 really_probe+0x78/0x2c0 Check if the "bank" field has been filled in before actually attempting the IOTLB flush to avoid it. The IOTLB is also flushed when the device comes out of runtime suspend, so it should have a clean initial state. Fixes: 08500c43d4f7 ("iommu/mediatek: Adjust the structure") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230526085402.394239-1-wenst@chromium.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-14Merge branches 'iommu/fixes', 'arm/allwinner', 'arm/exynos', 'arm/mediatek', ↵Joerg Roedel1-33/+125
'arm/omap', 'arm/renesas', 'arm/rockchip', 'arm/smmu', 'ppc/pamu', 'unisoc', 'x86/vt-d', 'x86/amd', 'core' and 'platform-remove_new' into next
2023-04-13iommu/mediatek: Set dma_mask for the master devicesYong Wu1-0/+8
MediaTek iommu arranges dma ranges for all the masters, this patch is to help them set dma mask. This is to avoid each master setting their own mask, but also to avoid a real issue, such as JPEG uses "mediatek,mtk-jpgenc" for 2701/8183/8186/8188, then JPEG could ignore its different dma_mask in different SoC to achieve common code. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-10-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-13iommu/mediatek: Add a gap for the iova regionsYong Wu1-5/+7
As the removed property in the vcodec dt-binding, the property is: dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; The length is 0xfff0_0000 rather than 0x1_0000_0000, this means it requires 1M as a gap. This is because the end address for some vcodec HW is (address + size). If the size is 4G, the end address may be 0x2_0000_0000, and the width for vcodec register only is 32, then the HW may get the ZERO address. Currently the consumer's dma-ranges property doesn't work, IOMMU has to consider this case. Add a bigger gap(8M) for all the regions to avoid it. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-9-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-13iommu/mediatek: mt8186: Add iova_region_larb_mskYong Wu1-0/+13
Add iova_region_larb_msk for mt8186. We separate the 16GB iova regions by each device's larbid/portid. Note: larb5/6/10/12/14/15/18 connect nothing in this SoC. Refer to include/dt-bindings/memory/mt8186-memory-port.h Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-8-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-13iommu/mediatek: mt8195: Add iova_region_larb_mskYong Wu1-0/+17
Add iova_region_larb_msk for mt8195. We separate the 16GB iova regions by each device's larbid/portid. Refer to include/dt-bindings/memory/mt8195-memory-port.h Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-7-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-13iommu/mediatek: mt8192: Add iova_region_larb_mskYong Wu1-1/+18
Add iova_region_larb_msk for mt8192. We separate the 16GB iova regions by each device's larbid/portid. Note: larb3/6/8/10/12/15 connect nothing in this SoC. Refer to the comment in include/dt-bindings/memory/mt8192-larb-port.h Define a new macro MT8192_MULTI_REGION_NR_MAX to indicate the index of mt8xxx_larb_region_msk and "struct mtk_iommu_iova_region mt8192_multi_dom" are the same. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-6-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-13iommu/mediatek: Get regionid from larb/port idYong Wu1-19/+26
After commit f1ad5338a4d5 ("of: Fix "dma-ranges" handling for bus controllers"), the dma-ranges is not allowed for dts leaf node. but we still would like to separate to different masters into different iova regions. Thus we have to separate it by the HW larbid and portid. For example, larb1/2 are in region2 and larb3 is in region3. The problem is that some ports inside a larb are in region4 while some ports inside this larb are in region5. Therefore I define a "iova_region_larb_msk" to help record the information for each a port. Take a example for a larb: [1] = ~0: means all ports in this larb are in region1; [2] = BIT(3) | BIT(4): means port3/4 in this larb are region2; [3] = ~(BIT(3) | BIT(4)): means all the other ports except port3/4 in this larb are region3. This method also avoids the users forget/abuse the iova regions. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-5-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-04-13iommu/mediatek: Improve comment for the current region/bankYong Wu1-5/+26
No functional change. Just add more comment about the current region/bank in the code. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230411093144.2690-4-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-03-31iommu/mtk: Convert to platform remove callback returning voidUwe Kleine-König1-3/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230321084125.337021-8-u.kleine-koenig@pengutronix.de Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-03-28iommu/mediatek: Set dma_mask for PGTABLE_PA_35_ENYong Wu1-0/+8
When we enable PGTABLE_PA_35_EN, the PA for pgtable may be 35bits. Thus add dma_mask for it. Fixes: 301c3ca12576 ("iommu/mediatek: Allow page table PA up to 35bit") Signed-off-by: Chengci.Xu <chengci.xu@mediatek.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230316101445.12443-1-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-01-13iommu: Remove detach_dev callbacksLu Baolu1-9/+0
The iommu core calls the driver's detach_dev domain op callback only when a device is finished assigning to user space and iommu_group_release_dma_owner() is called to return the device to the kernel, where iommu core wants to set the default domain to the device but the driver didn't provide one. In other words, if any iommu driver provides default domain support, the .detach_dev callback will never be called. This removes the detach_dev callbacks in those IOMMU drivers that support default domain. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Sven Peter <sven@svenpeter.dev> # apple-dart Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> # sprd Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> # amd Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20230110025408.667767-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-12Merge branches 'arm/allwinner', 'arm/exynos', 'arm/mediatek', ↵Joerg Roedel1-41/+112
'arm/rockchip', 'arm/smmu', 'ppc/pamu', 's390', 'x86/vt-d', 'x86/amd' and 'core' into next
2022-12-12iommu/mediatek: Fix forever loop in error handlingDan Carpenter1-2/+1
There is a typo so this loop does i++ where i-- was intended. It will result in looping until the kernel crashes. Fixes: 26593928564c ("iommu/mediatek: Add error path for loop of mm_dts_parse") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/Y5C3mTam2nkbaz6o@kili Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Fix crash on isr after kexec()Ricardo Ribalda1-1/+1
If the system is rebooted via isr(), the IRQ handler might be triggered before the domain is initialized. Resulting on an invalid memory access error. Fix: [ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070 [ 0.501166] Call trace: [ 0.501174] report_iommu_fault+0x28/0xfc [ 0.501180] mtk_iommu_isr+0x10c/0x1c0 Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20221125-mtk-iommu-v2-0-e168dff7d43e@chromium.org [ joro: Fixed spelling in commit message ] Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Remove unused "mapping" member from mtk_iommu_dataYong Wu1-3/+0
Just remove a unused variable that only is for mtk_iommu_v1. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221018024258.19073-7-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Improve safety for mediatek,smi property in larb nodesYong Wu1-16/+37
No functional change. Just improve safety from dts. All the larbs that connect to one IOMMU must connect with the same smi-common. This patch checks all the mediatek,smi property for each larb, If their mediatek,smi are different, it will return fails. Also avoid there is no available smi-larb nodes. Suggested-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221018024258.19073-6-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Validate number of phandles associated with "mediatek,larbs"Guenter Roeck1-0/+12
Fix the smatch warnings: drivers/iommu/mtk_iommu.c:878 mtk_iommu_mm_dts_parse() error: uninitialized symbol 'larbnode'. If someone abuse the dtsi node(Don't follow the definition of dt-binding), for example "mediatek,larbs" is provided as boolean property, "larb_nr" will be zero and cause abnormal. To fix this problem and improve the code safety, add some checking for the invalid input from dtsi, e.g. checking the larb_nr/larbid valid range, and avoid "mediatek,larb-id" property conflicts in the smi-larb nodes. Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221018024258.19073-5-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Add error path for loop of mm_dts_parseYong Wu1-7/+20
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if the i+1 larb is parsed fail, we should put_device for the i..0 larbs. There are two places need to comment: 1) The larbid may be not linear mapping, we should loop whole the array in the error path. 2) I move this line position: "data->larb_imu[id].dev = &plarbdev->dev;" before "if (!plarbdev->dev.driver)", That means set data->larb_imu[id].dev before the error path. then we don't need "platform_device_put(plarbdev)" again in probe_defer case. All depend on "put_device" of the error path in error cases. Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221018024258.19073-4-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Use component_match_addYong Wu1-6/+4
In order to simplify the error patch(avoid call of_node_put), Use component_match_add instead component_match_add_release since we are only interested in the "device" here. Then we could always call of_node_put in normal path. Strictly this is not a fixes patch, but it is a prepare for adding the error path, thus I add a Fixes tag too. Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE") Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221018024258.19073-3-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-12-05iommu/mediatek: Add platform_device_put for recovering the device refcntYong Wu1-3/+8
Add platform_device_put to match with of_find_device_by_node. Meanwhile, I add a new variable "pcommdev" which is for smi common device. Otherwise, "platform_device_put(plarbdev)" for smi-common dev may be not readable. And add a checking for whether pcommdev is NULL. Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221018024258.19073-2-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-11-19iommu/mediatek: Update to {map,unmap}_pagesRobin Murphy1-7/+8
Update map/unmap to the new multi-page interfaces, which is dead easy since we just pass them through to io-pgtable anyway. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/25b65b71e7e5d1006469aee48bab07ca87227bfa.1668100209.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-11-19iommu/mediatek: add support for MT8365 SoCFabien Parent1-0/+13
Add IOMMU support for MT8365 SoC. Signed-off-by: Fabien Parent <fparent@baylibre.com> Reviewed-by: Amjad Ouled-Ameur <aouledameur@baylibre.com> Tested-by: Amjad Ouled-Ameur <aouledameur@baylibre.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221001-iommu-support-v6-3-be4fe8da254b@baylibre.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-11-19iommu/mediatek: add support for 6-bit encoded port IDsFabien Parent1-1/+11
Until now the port ID was always encoded as a 5-bit data. On MT8365, the port ID is encoded as a 6-bit data. This requires to add extra macro F_MMU_INT_ID_LARB_ID_EXT, and F_MMU_INT_ID_PORT_ID_EXT in order to support 6-bit encoded port IDs. Signed-off-by: Fabien Parent <fparent@baylibre.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221001-iommu-support-v6-2-be4fe8da254b@baylibre.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-11-19iommu/mediatek: Check return value after calling platform_get_resource()Yang Yingliang1-0/+2
platform_get_resource() may return NULL pointer, we need check its return value to avoid null-ptr-deref in resource_size(). Fixes: 42d57fc58aeb ("iommu/mediatek: Initialise/Remove for multi bank dev") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20221029103550.3774365-1-yangyingliang@huawei.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-11-01iommu: Propagate return value in ->attach_dev callback functionsNicolin Chen1-1/+1
The mtk_iommu and virtio drivers have places in the ->attach_dev callback functions that return hardcode errnos instead of the returned values, but callers of these ->attach_dv callback functions may care. Propagate them directly without the extra conversions. Link: https://lore.kernel.org/r/ca8c5a447b87002334f83325f28823008b4ce420.1666042873.git.nicolinc@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-11-01iommu: Regulate EINVAL in ->attach_dev callback functionsNicolin Chen1-1/+1
Following the new rules in include/linux/iommu.h kdocs, EINVAL now can be used to indicate that domain and device are incompatible by a caller that treats it as a soft failure and tries attaching to another domain. On the other hand, there are ->attach_dev callback functions returning it for obvious device-specific errors. They will result in some inefficiency in the caller handling routine. Update these places to corresponding errnos following the new rules. Link: https://lore.kernel.org/r/5924c03bea637f05feb2a20d624bae086b555ec5.1666042872.git.nicolinc@nvidia.com Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-10-21iommu: Add gfp parameter to iommu_alloc_resv_regionLu Baolu1-1/+2
Add gfp parameter to iommu_alloc_resv_region() for the callers to specify the memory allocation behavior. Thus iommu_alloc_resv_region() could also be available in critical contexts. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20220927053109.4053662-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-26Merge branches 'apple/dart', 'arm/mediatek', 'arm/omap', 'arm/smmu', ↵Joerg Roedel1-25/+20
'virtio', 'x86/vt-d', 'x86/amd' and 'core' into next
2022-09-26iommu/mediatek: Add support for MT6795 Helio X10 M4UsAngeloGioacchino Del Regno1-0/+15
Add support for the M4Us found in the MT6795 Helio X10 SoC. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220913151148.412312-4-angelogioacchino.delregno@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-26iommu/mediatek: Introduce new flag TF_PORT_TO_ADDR_MT8173AngeloGioacchino Del Regno1-2/+4
In preparation for adding support for MT6795, add a new flag named TF_PORT_TO_ADDR_MT8173 and use that instead of checking for m4u_plat type in mtk_iommu_hw_init() to avoid seeing a long list of m4u_plat checks there in the future. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220913151148.412312-3-angelogioacchino.delregno@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-09-07iommu/mtk: Clean up bus_set_iommu()Robin Murphy1-23/+1
Stop calling bus_set_iommu() since it's now unnecessary, and simplify the probe failure paths accordingly. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/9134322ecd24030eebeac73f37ca579094cc7df0.1660572783.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-07-29Merge branches 'arm/exynos', 'arm/mediatek', 'arm/msm', 'arm/smmu', ↵Joerg Roedel1-34/+37
'virtio', 'x86/vt-d', 'x86/amd' and 'core' into next
2022-07-15iommu/mediatek: Log with dev_err_probe when failing to parse dtsNícolas F. R. A. Prado1-1/+1
mtk_iommu_mm_dts_parse() can fail with EPROBE_DEFER if not all larbs have probed yet, so use dev_err_probe() to avoid logging as an error in that case. Also drop the return value from the message since it's already printed by dev_err_probe(), and add the missing newline at the end. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220712214427.544860-1-nfraprado@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-07-15iommu: remove the put_resv_regions methodChristoph Hellwig1-1/+0
All drivers that implement get_resv_regions just use generic_put_resv_regions to implement the put side. Remove the indirections and document the allocations constraints. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20220708080616.238833-4-hch@lst.de Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-07-07iommu/mediatek: Allow page table PA up to 35bitYunfei Wang1-6/+7
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So add the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level 2 pgtable support at most 35bit PA. Signed-off-by: Ning Li <ning.li@mediatek.com> Signed-off-by: Yunfei Wang <yf.wang@mediatek.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20220630092927.24925-3-yf.wang@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-07-06iommu: Clean up release_device checksRobin Murphy1-5/+0
Since .release_device is now called through per-device ops, any call which gets as far as a driver definitely *is* for that driver, for a device which has successfully passed .probe_device, so all the checks to that effect are now redundant and can be removed. In the same vein we can also skip freeing fwspecs which are now managed by core code. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/02671dbfad7a3343fc25a44222350efcb455fe3c.1655822151.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-06-23iommu/mediatek: Cleanup pericfg lookup flowAngeloGioacchino Del Regno1-7/+5
Since only the INFRA type IOMMU needs to modify register(s) in the pericfg iospace, it's safe to drop the pericfg_comp_str NULL check; also, directly assign the regmap handle to data->pericfg instead of to the infracfg variable to improve code readability. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220616110830.26037-6-angelogioacchino.delregno@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-06-22iommu/mediatek: Lookup phandle to retrieve syscon to infracfgAngeloGioacchino Del Regno1-14/+24
This driver will get support for more SoCs and the list of infracfg compatibles is expected to grow: in order to prevent getting this situation out of control and see a long list of compatible strings, add support to retrieve a handle to infracfg's regmap through a new "mediatek,infracfg" phandle. In order to keep retrocompatibility with older devicetrees, the old way is kept in place. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Miles Chen <miles.chen@mediatek.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220616110830.26037-3-angelogioacchino.delregno@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-13iommu/mediatek: Fix NULL pointer dereference when printing dev_nameMiles Chen1-0/+6
When larbdev is NULL (in the case I hit, the node is incorrectly set iommus = <&iommu NUM>), it will cause device_link_add() fail and kernel crashes when we try to print dev_name(larbdev). Let's fail the probe if a larbdev is NULL to avoid invalid inputs from dts. It should work for normal correct setting and avoid the crash caused by my incorrect setting. Error log: [ 18.189042][ T301] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 ... [ 18.344519][ T301] pstate: a0400005 (NzCv daif +PAN -UAO) [ 18.345213][ T301] pc : mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] [ 18.346050][ T301] lr : mtk_iommu_probe_device+0xd0/0x118 [mtk_iommu] [ 18.346884][ T301] sp : ffffffc00a5635e0 [ 18.347392][ T301] x29: ffffffc00a5635e0 x28: ffffffd44a46c1d8 [ 18.348156][ T301] x27: ffffff80c39a8000 x26: ffffffd44a80cc38 [ 18.348917][ T301] x25: 0000000000000000 x24: ffffffd44a80cc38 [ 18.349677][ T301] x23: ffffffd44e4da4c6 x22: ffffffd44a80cc38 [ 18.350438][ T301] x21: ffffff80cecd1880 x20: 0000000000000000 [ 18.351198][ T301] x19: ffffff80c439f010 x18: ffffffc00a50d0c0 [ 18.351959][ T301] x17: ffffffffffffffff x16: 0000000000000004 [ 18.352719][ T301] x15: 0000000000000004 x14: ffffffd44eb5d420 [ 18.353480][ T301] x13: 0000000000000ad2 x12: 0000000000000003 [ 18.354241][ T301] x11: 00000000fffffad2 x10: c0000000fffffad2 [ 18.355003][ T301] x9 : a0d288d8d7142d00 x8 : a0d288d8d7142d00 [ 18.355763][ T301] x7 : ffffffd44c2bc640 x6 : 0000000000000000 [ 18.356524][ T301] x5 : 0000000000000080 x4 : 0000000000000001 [ 18.357284][ T301] x3 : 0000000000000000 x2 : 0000000000000005 [ 18.358045][ T301] x1 : 0000000000000000 x0 : 0000000000000000 [ 18.360208][ T301] Hardware name: MT6873 (DT) [ 18.360771][ T301] Call trace: [ 18.361168][ T301] dump_backtrace+0xf8/0x1f0 [ 18.361737][ T301] dump_stack_lvl+0xa8/0x11c [ 18.362305][ T301] dump_stack+0x1c/0x2c [ 18.362816][ T301] mrdump_common_die+0x184/0x40c [mrdump] [ 18.363575][ T301] ipanic_die+0x24/0x38 [mrdump] [ 18.364230][ T301] atomic_notifier_call_chain+0x128/0x2b8 [ 18.364937][ T301] die+0x16c/0x568 [ 18.365394][ T301] __do_kernel_fault+0x1e8/0x214 [ 18.365402][ T301] do_page_fault+0xb8/0x678 [ 18.366934][ T301] do_translation_fault+0x48/0x64 [ 18.368645][ T301] do_mem_abort+0x68/0x148 [ 18.368652][ T301] el1_abort+0x40/0x64 [ 18.368660][ T301] el1h_64_sync_handler+0x54/0x88 [ 18.368668][ T301] el1h_64_sync+0x68/0x6c [ 18.368673][ T301] mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] ... Cc: Robin Murphy <robin.murphy@arm.com> Cc: Yong Wu <yong.wu@mediatek.com> Reported-by: kernel test robot <lkp@intel.com> Fixes: 635319a4a744 ("media: iommu/mediatek: Add device_link between the consumer and the larb devices") Signed-off-by: Miles Chen <miles.chen@mediatek.com> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220505132731.21628-1-miles.chen@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Add mt8186 iommu supportYong Wu1-0/+16
Add mt8186 iommu supports. Signed-off-by: Anan Sun <anan.sun@mediatek.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220503071427.2285-37-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: mt8195: Enable multi banks for infra iommuYong Wu1-2/+5
Enable the multi-bank functions for infra-iommu. We put PCIE in bank0 and USB in the last bank(bank4). and we don't use the other banks currently, disable them. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-36-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Backup/restore regsiters for multi banksYong Wu1-15/+31
Each bank has some independent registers. thus backup/restore them for each a bank when suspend and resume. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-35-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Initialise/Remove for multi bank devYong Wu1-14/+30
The registers for each bank of the IOMMU base are in order, delta is 0x1000. Initialise the base for each bank. For all the previous SoC, we only have bank0. thus use "do {} while()" to allow bank0 always go. When removing the device, Not always all the banks are initialised, it depend on if there is masters for that bank. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-34-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Get the proper bankid for multi banksYong Wu1-7/+48
We preassign some ports in a special bank via the new defined banks_portmsk. Put it in the plat_data means it is not expected to be adjusted dynamically. If the iommu id in the iommu consumer's dtsi node is inside this banks_portmsk, then we switch it to this special iommu bank, and initialise the IOMMU bank HW. Each bank has the independent pgtable(4GB iova range). Each bank is a independent iommu domain/group. Currently we don't separate different iova ranges inside a bank. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-33-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Change the domid to iova_region_idYong Wu1-23/+23
Prepare for adding bankid, also no functional change. In the previous SoC, each a iova_region is a domain; In the multi-banks case, each a bank is a domain, then the original function name "mtk_iommu_get_domain_id" is not proper. Use "iova_region_id" instead of "domain_id". Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-32-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Initialise bank HW for each a bankYong Wu1-12/+20
The mt8195 IOMMU HW max support 5 banks, and regarding the banks' registers, it looks like: ---------------------------------------- |bank0 | bank1 | bank2 | bank3 | bank4| ---------------------------------------- |global | |control| null |regs | ----------------------------------------- |bank |bank |bank |bank |bank | |regs |regs |regs |regs |regs | | | | | | | ----------------------------------------- Each bank has some special bank registers and it share bank0's global control registers. this patch initialise the bank hw with the bankid. In the hw_init, we always initialise bank0's control register since we don't know if the bank0 is initialised. Additionally, About each bank's register base, always delta 0x1000. like bank[x + 1] = bank[x] + 0x1000. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-31-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Add mtk_iommu_bank_data structureYong Wu1-62/+117
Prepare for supporting multi-banks for the IOMMU HW, No functional change. Add a new structure(mtk_iommu_bank_data) for each a bank. Each a bank have the independent HW base/IRQ/tlb-range ops, and each a bank has its special iommu-domain(independent pgtable), thus, also move the domain information into it. In previous SoC, we have only one bank which could be treated as bank0( bankid always is 0 for the previous SoC). After adding this structure, the tlb operations and irq could use bank_data as parameter. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-30-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Remove mtk_iommu.hYong Wu1-1/+13
Currently there is a suspend structure in the header file. It's no need to keep a header file only for this. Move these into the c file and rm this header file. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-28-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-05-04iommu/mediatek: Separate mtk_iommu_data for v1 and v2Yong Wu1-5/+77
Prepare for adding the structure "mtk_iommu_bank_data". No functional change. The mtk_iommu_domain in v1 and v2 are different, we could not add current data as bank[0] in v1 simplistically. Currently we have no plan to add new SoC for v1, in order to avoid affect v1 when we add many new features for v2, I totally separate v1 and v2 in this patch, there are many structures only for v2. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20220503071427.2285-27-yong.wu@mediatek.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-06 11:20:36 +0300