On Mon, 11 Mar 2024 13:51:46 +0200
Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
> On Mon, 11 Mar 2024, Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote:
> > On Mon, 11 Mar 2024 13:16:19 +0200
> > Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
> >
> >> This reverts commit 674dc7f61aefea81901c21402946074927e63f1a.
> >>
> >> The commit causes a recursive dependency in kconfig:
> >>
> >> drivers/iommu/Kconfig:14:error: recursive dependency detected!
> >> drivers/iommu/Kconfig:14: symbol IOMMU_SUPPORT is selected by DRM_PANTHOR
> >> drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on PM
> >> kernel/power/Kconfig:183: symbol PM is selected by PM_SLEEP
> >> kernel/power/Kconfig:117: symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
> >> kernel/power/Kconfig:35: symbol HIBERNATE_CALLBACKS is selected by XEN_SAVE_RESTORE
> >> arch/x86/xen/Kconfig:67: symbol XEN_SAVE_RESTORE depends on XEN
> >> arch/x86/xen/Kconfig:6: symbol XEN depends on PARAVIRT
> >> arch/x86/Kconfig:781: symbol PARAVIRT is selected by HYPERV
> >> drivers/hv/Kconfig:5: symbol HYPERV depends on X86_LOCAL_APIC
> >> arch/x86/Kconfig:1106: symbol X86_LOCAL_APIC depends on X86_UP_APIC
> >> arch/x86/Kconfig:1081: symbol X86_UP_APIC prompt is visible depending on PCI_MSI
> >> drivers/pci/Kconfig:39: symbol PCI_MSI is selected by AMD_IOMMU
> >> drivers/iommu/amd/Kconfig:3: symbol AMD_IOMMU depends on IOMMU_SUPPORT
> >> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> >> subsection "Kconfig recursive dependency limitations"
> >>
> >> Fixes: 674dc7f61aef ("drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue")
> >> Cc: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>
> >> Cc: Liviu Dudau <liviu.dudau@xxxxxxx>
> >> Cc: Steven Price <steven.price@xxxxxxx>
> >> Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> >
> > Acked-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>
>
> Your suggestion select -> depends on IOMMU_SUPPORT seems to also work,
> at least for me. Want to send a patch for that instead of me merging the
> revert?
I replied on the other thread :-). I think we're better off reverting
the faulty commit, so we can discuss how to fix the original issue
properly without blocking the build.
Thanks;
Boris
