On Mon, 11 Mar 2024 13:51:46 +0200
Jani Nikula <jani.nik...@intel.com> wrote:

> On Mon, 11 Mar 2024, Boris Brezillon <boris.brezil...@collabora.com> wrote:
> > On Mon, 11 Mar 2024 13:16:19 +0200
> > Jani Nikula <jani.nik...@intel.com> 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.brezil...@collabora.com>
> >> Cc: Liviu Dudau <liviu.du...@arm.com>
> >> Cc: Steven Price <steven.pr...@arm.com>
> >> Signed-off-by: Jani Nikula <jani.nik...@intel.com>  
> >
> > Acked-by: Boris Brezillon <boris.brezil...@collabora.com>  
> 
> 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

Reply via email to