All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Tom Rini <trini@konsulko.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Arnd Bergmann <arnd@arndb.de>, Nishanth Menon <nm@ti.com>,
	Olof Johansson <olof@lixom.net>, SoC <soc@kernel.org>,
	arm-soc <arm@kernel.org>, Tero Kristo <kristo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17
Date: Tue, 21 Dec 2021 16:55:48 +0100	[thread overview]
Message-ID: <CAK8P3a2wNNSQkN_m3DzEF5RLmq1aED1JpOkXW9Yq13+ypiAaGQ@mail.gmail.com> (raw)
In-Reply-To: <20211221153250.GA2081238@bill-the-cat>

On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote:
> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote:
> >
> > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as
> > modules (symbols are bool only).
> > PCIe is not necessary for basic boot either. So, I can drop these
> > configs until these drivers are build able as modules, if you prefer.
>
> Is PCIe required for basic boot for the other platforms in the defconfig
> which do enable it in the defconfig today?  It is required for non-basic
> boot (whatever storage one puts in a PCIe slot).  If someone is going to
> be fixing the PCIe driver to be able to be modular, that's fine too but
> I ran in to this trying to see what works out of the box in the
> defconfig, on this platform and hit both of these rather large
> omissions.

If PCI is often used for storage, then that's ok. There are a number of
other platforms where PCIe is only used for wireless networking or
other secondary devices, but they are still built-in because they got
added before it became possible for PCIe host drivers to be loadable
modules. I would like to eventually go through and turn those into
loadable modules, but for the moment it would be good to only add
built-in drivers where this is actually useful.

       Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Tom Rini <trini@konsulko.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Arnd Bergmann <arnd@arndb.de>, Nishanth Menon <nm@ti.com>,
	 Olof Johansson <olof@lixom.net>, SoC <soc@kernel.org>,
	arm-soc <arm@kernel.org>, Tero Kristo <kristo@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17
Date: Tue, 21 Dec 2021 16:55:48 +0100	[thread overview]
Message-ID: <CAK8P3a2wNNSQkN_m3DzEF5RLmq1aED1JpOkXW9Yq13+ypiAaGQ@mail.gmail.com> (raw)
In-Reply-To: <20211221153250.GA2081238@bill-the-cat>

On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote:
> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote:
> >
> > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as
> > modules (symbols are bool only).
> > PCIe is not necessary for basic boot either. So, I can drop these
> > configs until these drivers are build able as modules, if you prefer.
>
> Is PCIe required for basic boot for the other platforms in the defconfig
> which do enable it in the defconfig today?  It is required for non-basic
> boot (whatever storage one puts in a PCIe slot).  If someone is going to
> be fixing the PCIe driver to be able to be modular, that's fine too but
> I ran in to this trying to see what works out of the box in the
> defconfig, on this platform and hit both of these rather large
> omissions.

If PCI is often used for storage, then that's ok. There are a number of
other platforms where PCIe is only used for wireless networking or
other secondary devices, but they are still built-in because they got
added before it became possible for PCIe host drivers to be loadable
modules. I would like to eventually go through and turn those into
loadable modules, but for the moment it would be good to only add
built-in drivers where this is actually useful.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-12-21 15:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 17:28 [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 Vignesh Raghavendra
2021-12-17 17:28 ` Vignesh Raghavendra
2021-12-17 17:28 ` [GIT PULL 2/2] arm64: dts: TI K3 updates " Vignesh Raghavendra
2021-12-17 17:28   ` Vignesh Raghavendra
2021-12-20 15:27 ` [GIT PULL 1/2] arm64: TI K3 SoC configs changes " Arnd Bergmann
2021-12-20 15:27   ` Arnd Bergmann
2021-12-20 17:40   ` Vignesh Raghavendra
2021-12-20 17:40     ` Vignesh Raghavendra
2021-12-21 15:32     ` Tom Rini
2021-12-21 15:32       ` Tom Rini
2021-12-21 15:55       ` Arnd Bergmann [this message]
2021-12-21 15:55         ` Arnd Bergmann
2021-12-21 16:09         ` Tom Rini
2021-12-21 16:09           ` Tom Rini
2021-12-22  7:26           ` Vignesh Raghavendra
2021-12-22  7:26             ` Vignesh Raghavendra
2021-12-22 16:40             ` Tom Rini
2021-12-22 16:40               ` Tom Rini

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=CAK8P3a2wNNSQkN_m3DzEF5RLmq1aED1JpOkXW9Yq13+ypiAaGQ@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=arm@kernel.org \
    --cc=kristo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=olof@lixom.net \
    --cc=soc@kernel.org \
    --cc=trini@konsulko.com \
    --cc=vigneshr@ti.com \
    /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.