All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Christoph Hellwig <hch@lst.de>, linux-pci@vger.kernel.org
Cc: mporter@kernel.crashing.org, Alex Bounine <alex.bou9@gmail.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/8] PCI: consolidate PCI config entry in drivers/pci
Date: Fri, 19 Oct 2018 14:07:04 +0900	[thread overview]
Message-ID: <CAK7LNASJaRrut2neRa92CudohW4A-2=GHMzgEpOzT97VdGuhng@mail.gmail.com> (raw)
In-Reply-To: <20181017080201.10866-5-hch@lst.de>

On Wed, Oct 17, 2018 at 5:04 PM Christoph Hellwig <hch@lst.de> wrote:
>
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAS_PCI symbol that indicates availability

HAS_PCI -> HAVE_PCI


> of PCI support and the handle the rest in drivers/pci.
>
> Note that for powerpc we now select HAVE_PCI globally instead of the
> convoluted mess of conditional or or non-conditional support per board,
> similar to what we do e.g. on x86.  For alpha PCI is selected for the
> non-jensen configs as it was the default before, and a lot of code does
> not compile without PCI enabled.  On other architectures with limited
> PCI support that wasn't as complicated I've left the selection as-is.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>



Just in case, could you double-check these?
PCI_ENDPOINT
PCI_ENDPOINT_CONFIGFS
PCI_EPF_TEST


Previously, architecture without "source drivers/pci/Kconfig"
could not enable PCI_ENDPOINT.

Now, any architecture can enable it
regardless of its actual PCI availability
because PCI_ENDPOINT is only guarded by HAS_DMA.


We could add 'depends on HAVE_PCI' or something
to guard it to avoid changing the logic.


config PCI_ENDPOINT
        bool "PCI Endpoint Support"
        depends on HAVE_PCI     # Is this correct ??
        depends on HAS_DMA


or better to have 'depends on PCI' ?


PCI ML is also CC'ed, so comments are appreciated.



-- 
Best Regards
Masahiro Yamada

WARNING: multiple messages have this Message-ID (diff)
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Christoph Hellwig <hch@lst.de>, linux-pci@vger.kernel.org
Cc: linux-arch <linux-arch@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Alex Bounine <alex.bou9@gmail.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/8] PCI: consolidate PCI config entry in drivers/pci
Date: Fri, 19 Oct 2018 14:07:04 +0900	[thread overview]
Message-ID: <CAK7LNASJaRrut2neRa92CudohW4A-2=GHMzgEpOzT97VdGuhng@mail.gmail.com> (raw)
In-Reply-To: <20181017080201.10866-5-hch@lst.de>

On Wed, Oct 17, 2018 at 5:04 PM Christoph Hellwig <hch@lst.de> wrote:
>
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAS_PCI symbol that indicates availability

HAS_PCI -> HAVE_PCI


> of PCI support and the handle the rest in drivers/pci.
>
> Note that for powerpc we now select HAVE_PCI globally instead of the
> convoluted mess of conditional or or non-conditional support per board,
> similar to what we do e.g. on x86.  For alpha PCI is selected for the
> non-jensen configs as it was the default before, and a lot of code does
> not compile without PCI enabled.  On other architectures with limited
> PCI support that wasn't as complicated I've left the selection as-is.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>



Just in case, could you double-check these?
PCI_ENDPOINT
PCI_ENDPOINT_CONFIGFS
PCI_EPF_TEST


Previously, architecture without "source drivers/pci/Kconfig"
could not enable PCI_ENDPOINT.

Now, any architecture can enable it
regardless of its actual PCI availability
because PCI_ENDPOINT is only guarded by HAS_DMA.


We could add 'depends on HAVE_PCI' or something
to guard it to avoid changing the logic.


config PCI_ENDPOINT
        bool "PCI Endpoint Support"
        depends on HAVE_PCI     # Is this correct ??
        depends on HAS_DMA


or better to have 'depends on PCI' ?


PCI ML is also CC'ed, so comments are appreciated.



-- 
Best Regards
Masahiro Yamada

  reply	other threads:[~2018-10-19  5:08 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17  8:01 move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2 Christoph Hellwig
2018-10-17  8:01 ` Christoph Hellwig
2018-10-17  8:01 ` [PATCH 1/8] aha152x: rename the PCMCIA define Christoph Hellwig
2018-10-17  8:01   ` Christoph Hellwig
2018-10-17  8:01 ` [PATCH 2/8] powerpc: remove CONFIG_PCI_QSPAN Christoph Hellwig
2018-10-17  8:01   ` Christoph Hellwig
2018-10-17  9:10   ` Benjamin Herrenschmidt
2018-10-17  8:01 ` [PATCH 3/8] powerpc: PCI_MSI needs PCI Christoph Hellwig
2018-10-17  8:01   ` Christoph Hellwig
2018-10-17  8:01 ` [PATCH 4/8] PCI: consolidate PCI config entry in drivers/pci Christoph Hellwig
2018-10-17  8:01   ` Christoph Hellwig
2018-10-19  5:07   ` Masahiro Yamada [this message]
2018-10-19  5:07     ` Masahiro Yamada
2018-10-19  7:02     ` Christoph Hellwig
2018-10-19  7:02       ` Christoph Hellwig
2018-10-19  5:19   ` Max Filippov
2018-10-19  5:19     ` Max Filippov
2018-10-17  8:01 ` [PATCH 5/8] pcmcia: allow PCMCIA support independent of the architecture Christoph Hellwig
2018-10-17  8:01   ` Christoph Hellwig
2018-10-17  8:01 ` [PATCH 6/8] rapidio: consolidate RAPIDIO config entry in drivers/rapidio Christoph Hellwig
2018-10-17  8:01   ` Christoph Hellwig
2018-10-19  4:53   ` Masahiro Yamada
2018-10-19  4:53     ` Masahiro Yamada
2018-10-17  8:02 ` [PATCH 7/8] eisa: consolidate EISA Kconfig entry in drivers/eisa Christoph Hellwig
2018-10-17  8:02   ` Christoph Hellwig
2018-10-19  4:46   ` Masahiro Yamada
2018-10-19  4:46     ` Masahiro Yamada
2018-10-19  7:06     ` Christoph Hellwig
2018-10-19  7:06       ` Christoph Hellwig
2018-10-19  4:48   ` Masahiro Yamada
2018-10-19  4:48     ` Masahiro Yamada
2018-10-17  8:02 ` [PATCH 8/8] kconfig: remove CONFIG_MCA leftovers Christoph Hellwig
2018-10-17  8:02   ` Christoph Hellwig
2018-10-17  8:30 ` move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ v2 Geert Uytterhoeven
2018-10-17  8:30   ` Geert Uytterhoeven
2018-10-19  7:00   ` Christoph Hellwig
2018-10-19  7:00     ` Christoph Hellwig
2018-10-19  7:07     ` Geert Uytterhoeven
2018-10-19  7:07       ` Geert Uytterhoeven
2018-10-19  7:10       ` Christoph Hellwig
2018-10-19  7:10         ` Christoph Hellwig
2018-10-19  7:22         ` Geert Uytterhoeven
2018-10-19  7:22           ` Geert Uytterhoeven
2018-10-19 12:01           ` Christoph Hellwig
2018-10-19 12:01             ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2018-10-13 15:10 move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/ Christoph Hellwig
2018-10-13 15:10 ` [PATCH 4/8] pci: consolidate PCI config entry in drivers/pci Christoph Hellwig
2018-10-13 15:10   ` Christoph Hellwig
2018-10-15  6:37   ` Masahiro Yamada
2018-10-15  6:37     ` Masahiro Yamada
2018-10-15  8:57     ` Christoph Hellwig
2018-10-15  8:57       ` Christoph Hellwig
2018-10-15  9:17       ` Masahiro Yamada
2018-10-15  9:17         ` Masahiro Yamada
2018-10-15 20:58   ` Bjorn Helgaas
2018-10-15 20:58     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK7LNASJaRrut2neRa92CudohW4A-2=GHMzgEpOzT97VdGuhng@mail.gmail.com' \
    --to=yamada.masahiro@socionext.com \
    --cc=alex.bou9@gmail.com \
    --cc=hch@lst.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mporter@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.