[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNASUArREw1AWUzcOoQCe5=4jyifbs+x2CdCK+qXJ+woAdw@mail.gmail.com>
Date: Thu, 1 Nov 2018 01:05:26 +0900
From: Masahiro Yamada <yamada.masahiro@...ionext.com>
To: Christoph Hellwig <hch@....de>
Cc: linux-arch <linux-arch@...r.kernel.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
linux-pci@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Alex Bounine <alex.bou9@...il.com>,
mporter@...nel.crashing.org,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH 6/9] PCI: consolidate PCI config entry in drivers/pci
Hi Christoph,
On Fri, Oct 19, 2018 at 9:58 PM Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
>
> On Fri, Oct 19, 2018 at 9:23 PM Russell King - ARM Linux
> <linux@...linux.org.uk> wrote:
>
> > > index a68b34183107..b185794549be 100644
> > > --- a/arch/arm/mach-pxa/Kconfig
> > > +++ b/arch/arm/mach-pxa/Kconfig
> > > @@ -125,7 +125,7 @@ config MACH_ARMCORE
> > > bool "CompuLab CM-X255/CM-X270 modules"
> > > select ARCH_HAS_DMA_SET_COHERENT_MASK if PCI
> > > select IWMMXT
> > > - select MIGHT_HAVE_PCI
> > > + select HAVE_PCI
> > > select NEED_MACH_IO_H if PCI
> > > select PXA25x
> > > select PXA27x
> >
> > This is wrong. "MIGHT_HAVE_PCI" is _not_ the same as "HAVE_PCI" - we
> > have a bunch of platforms that mandatorily have PCI and these select
> > PCI directly. "MIGHT_HAVE_PCI" controls the _visibility_ of the PCI
> > menu option, but does not prevent it being selected. Your patch will
> > cause Kconfig to complain for those which mandatorily have PCI but
> > do not set HAVE_PCI.
>
>
> Good catch!
> But, adding a bunch of 'select HAVE_PCI' along with 'select PCI' is ugly.
>
> Do you have any suggestion?
>
> How about letting CONFIG_ARM to select HAVE_PCI ?
>
I applied 1/9, 3/9, 4/9, 5/9.
(I think 2/9 should be squashed to 9/9)
As Russell pointed out, we need to avoid
the unmet dependency.
Are you planning to send
the updated version for 6/9 through - 9/9 ?
If so, could you please rebase 6/9
so that it is cleanly applicable ?
Thanks.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists