Re: [PATCH] dmaengine: hisilicon: fix PCI_MSI dependency

[Vinod Koul <vkoul@kernel.org>]

On 09-04-20, 09:57, Zhou Wang wrote:
> On 2020/4/9 4:05, Arnd Bergmann wrote:
> > The dependency is phrased incorrectly, so on arm64, it is possible
> > to build with CONFIG_PCI disabled, resulting a build failure:
> > 
> > drivers/dma/hisi_dma.c: In function 'hisi_dma_free_irq_vectors':
> > drivers/dma/hisi_dma.c:138:2: error: implicit declaration of function 'pci_free_irq_vectors'; did you mean 'pci_alloc_irq_vectors'? [-Werror=implicit-function-declaration]
> >   138 |  pci_free_irq_vectors(data);
> >       |  ^~~~~~~~~~~~~~~~~~~~
> >       |  pci_alloc_irq_vectors
> > drivers/dma/hisi_dma.c: At top level:
> > drivers/dma/hisi_dma.c:605:1: warning: data definition has no type or storage class
> >   605 | module_pci_driver(hisi_dma_pci_driver);
> >       | ^~~~~~~~~~~~~~~~~
> > drivers/dma/hisi_dma.c:605:1: error: type defaults to 'int' in declaration of 'module_pci_driver' [-Werror=implicit-int]
> > drivers/dma/hisi_dma.c:605:1: warning: parameter names (without types) in function declaration
> > drivers/dma/hisi_dma.c:599:26: error: 'hisi_dma_pci_driver' defined but not used [-Werror=unused-variable]
> >   599 | static struct pci_driver hisi_dma_pci_driver = {
> > 
> > Change it so we always depend on PCI_MSI, even on ARM64
> > 
> > Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  drivers/dma/Kconfig | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index 98ae15c82a30..c19e25b140c5 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -241,7 +241,8 @@ config FSL_RAID
> >  
> >  config HISI_DMA
> >  	tristate "HiSilicon DMA Engine support"
> > -	depends on ARM64 || (COMPILE_TEST && PCI_MSI)
> > +	depends on ARM64 || COMPILE_TEST
> > +	depends on PCI_MSI
> >  	select DMA_ENGINE
> >  	select DMA_VIRTUAL_CHANNELS
> >  	help
> > 
> 
> Hi Arnd,
> 
> There was a fix from Haibing: https://lkml.org/lkml/2020/3/28/158
> Maybe Vinod will review and take it later :)

It should be in -next tomorrow :)


-- 
~Vinod