On Thu, 3 Nov 2022 at 14:03, Sam Protsenko <semen.protsenko@xxxxxxxxxx> wrote: > > Hi Marek, > > [snip] > > > MODULE_DEVICE_TABLE(of, sysmmu_of_match); is missing, so the driver > > won't be automatically loaded, what breaks its operation if compiled as > > module. > > > > Right, didn't think about hot-plug case. Will add > MODULE_DEVICE_TABLE() along with MODULE_ALIAS() in v2, thanks. > > > Also Exynos DRM and S5P-MFC drivers rely on the Exynos IOMMU being > > built-in, so they need to be adjusted for modularized builds too imho, > > at least in the Kconfig dependency. > > > Did some research on that question: - both DRM_EXYNOS and S5P_MFC drivers are designed to work fine even when EXYNOS_IOMMU is disabled: they just take another code path in that case - DRM_EXYNOS already uses IS_ENABLE() macro, which covers EXYNOS_IOMMU=m case - I'll provide a fix for S5P_MFC in v2 to do the same, as right now it does the check with #ifdef CONFIG_EXYNOS_IOMMU, which only covers =y case - both DRM_EXYNOS and S5P_MFC don't use EXYNOS_IOMMU driver symbols, as the latter doesn't export any - the correct probe order (EXYNOS_IOMMU first, then its users) is already ensured in device tree, by referencing sysmmu phandles in "iommus = <&...>" properties So I'm not sure if it makes sense to make those drivers depend on EXYNOS_IOMMU in Kconfig? AFAIR, there could've been some issues if those used some exported symbols from EXYNOS_IOMMU, but it's not the case. Please let me know if I'm missing something. > Sure, I'll check all Kconfigs and defconfigs before sending out v2. > > Btw, can you please also check my most recent reply [1] for the > "[PATCH 1/2] iommu/exynos: Abstract getting the fault info"? > > [1] https://lore.kernel.org/lkml/CAPLW+4n-Lf6je61rxdJ9nJnX9h9F8F-y+qikG7eFF0avQpMV9Q@xxxxxxxxxxxxxx/ > > Thanks! > > [snip]
