Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1572229 > unrolled thread

Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n Michael Ellerman <mpe@ellerman.id.au> - 2017-02-02 11:00 +0100
    Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n Alex Williamson <alex.williamson@redhat.com> - 2017-02-02 18:10 +0100

#1572229 — Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n

Michael Ellerman <mpe@ellerman.id.au> writes:

> Currently the kconfig logic for VFIO_IOMMU_SPAPR_TCE and VFIO_SPAPR_EEH
> is broken when SPAPR_TCE_IOMMU=n. Leading to:
>
>     warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct dependencies (VFIO && SPAPR_TCE_IOMMU)
>     warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct dependencies (VFIO && SPAPR_TCE_IOMMU)
>     drivers/vfio/vfio_iommu_spapr_tce.c:113:8: error: implicit declaration of function 'mm_iommu_find'
>
> This stems from the fact that VFIO selects VFIO_IOMMU_SPAPR_TCE, and
> although it has an if clause, the condition is not correct.
>
> We could fix it by doing select VFIO_IOMMU_SPAPR_TCE if SPAPR_TCE_IOMMU,
> but the cleaner fix is to drop the selects and tie VFIO_IOMMU_SPAPR_TCE
> to the value of VFIO, and express the dependencies in only once place.
>
> Do the same for VFIO_SPAPR_EEH.
>
> The end result is that the values of VFIO_IOMMU_SPAPR_TCE and
> VFIO_SPAPR_EEH follow the value of VFIO, except when SPAPR_TCE_IOMMU=n
> and/or EEH=n. Which is exactly what we want to happen.

Ping?

There was a bit of discussion on this patch but I think we decided it
was correct in the end.

cheers

[toc] | [next] | [standalone]

#1572525

On Thu, 02 Feb 2017 20:50:48 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:

> Michael Ellerman <mpe@ellerman.id.au> writes:
> 
> > Currently the kconfig logic for VFIO_IOMMU_SPAPR_TCE and VFIO_SPAPR_EEH
> > is broken when SPAPR_TCE_IOMMU=n. Leading to:
> >
> >     warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct dependencies (VFIO && SPAPR_TCE_IOMMU)
> >     warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct dependencies (VFIO && SPAPR_TCE_IOMMU)
> >     drivers/vfio/vfio_iommu_spapr_tce.c:113:8: error: implicit declaration of function 'mm_iommu_find'
> >
> > This stems from the fact that VFIO selects VFIO_IOMMU_SPAPR_TCE, and
> > although it has an if clause, the condition is not correct.
> >
> > We could fix it by doing select VFIO_IOMMU_SPAPR_TCE if SPAPR_TCE_IOMMU,
> > but the cleaner fix is to drop the selects and tie VFIO_IOMMU_SPAPR_TCE
> > to the value of VFIO, and express the dependencies in only once place.
> >
> > Do the same for VFIO_SPAPR_EEH.
> >
> > The end result is that the values of VFIO_IOMMU_SPAPR_TCE and
> > VFIO_SPAPR_EEH follow the value of VFIO, except when SPAPR_TCE_IOMMU=n
> > and/or EEH=n. Which is exactly what we want to happen.  
> 
> Ping?
> 
> There was a bit of discussion on this patch but I think we decided it
> was correct in the end.

If there are no other comments or objections, I'll queue this for
v4.11.  Based on this last comment:

  eg, using def_tristate you get:

  # CONFIG_VFIO_IOMMU_SPAPR_TCE is not set
  # CONFIG_VFIO is not set

  Whereas using depends all you get is:

  # CONFIG_VFIO is not set

I prefer prefer the solution here that doesn't leave extra unselected
config entries when CONFIG_VFIO is also not selected.  Thanks,

Alex

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web