From: Bjorn Helgaas <helgaas@kernel.org>
To: Achal Verma <a-verma1@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
Tom Joseph <tjoseph@cadence.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczy_ski <kw@linux.com>,
Rob Herring <robh@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-omap@vger.kernel.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] PCI: j721e: Add support to build pci-j721e as a kernel module
Date: Thu, 17 Aug 2023 12:04:17 -0500 [thread overview]
Message-ID: <20230817170417.GA320486@bhelgaas> (raw)
In-Reply-To: <20230817120823.1158766-3-a-verma1@ti.com>
On Thu, Aug 17, 2023 at 05:38:23PM +0530, Achal Verma wrote:
> pci-j721e driver can be build as a in-built kernel driver only, which is
> not required as it is not used during boot time in most cases.
> This change add support to build pci-j721e as a kernel loadable module.
>
> J721e PCIe controller can work in both host mode and end-point mode.
> In order to enable host mode driver and endpoint driver to be built
> independently either as built-in or kernel module, the pcie-j721e.c driver
> is refactored into following components:
>
> 1) pci-j721e-host.c: Driver used when PCIe controller has to be
> initialized in host mode.
>
> 2) pci-j721e-ep.c: Driver used when PCIe controller has to be
> initialized in endpoint mode.
>
> 3) pci-j721e.c: contains common code required in both modes.
Sounds like at least two commits (I'm not sure what the best order
would be):
1) Split into separate host mode and endpoint mode drivers
2) Make both drivers tristate
It looks like you implement both module loading and removal. Do we
now think removal of these modules is safe? IIRC there used to be a
question related to irq_desc lifetimes, e.g., there's some discussion
here: https://lore.kernel.org/linux-pci/87k085xekg.wl-maz@kernel.org/
The ability to *load* drivers as modules is definitely useful. The
ability to *remove* them is useful for developers but not really
useful for users.
But I guess j721e_pcie_remove() already exists, so maybe you're not
changing anything as far as irq_desc lifetimes\x06
Since you're splitting into new files, maybe this is an opportunity to
fix my naming mistake of suggesting a "pci-" prefix instead of
"pcie-"?
Bjorn
> config PCI_J721E_HOST
> - bool "TI J721E PCIe controller (host mode)"
> + tristate "TI J721E PCIe controller (host mode)"
> depends on OF
> select PCIE_CADENCE_HOST
> select PCI_J721E
> @@ -56,7 +56,7 @@ config PCI_J721E_HOST
> core.
>
> config PCI_J721E_EP
> - bool "TI J721E PCIe controller (endpoint mode)"
> + tristate "TI J721E PCIe controller (endpoint mode)"
> depends on OF
> depends on PCI_ENDPOINT
> select PCIE_CADENCE_EP
> +static struct platform_driver j721e_pcie_ep_driver = {
> + .probe = j721e_pcie_probe,
> + .remove_new = j721e_pcie_remove,
> + .driver = {
> + .name = "j721e-pcie-ep",
> + .of_match_table = of_j721e_pcie_ep_match,
> + .suppress_bind_attrs = true,
> + },
> +};
> +static struct platform_driver j721e_pcie_host_driver = {
> + .probe = j721e_pcie_probe,
> + .remove_new = j721e_pcie_remove,
> + .driver = {
> + .name = "j721e-pcie-host",
> + .of_match_table = of_j721e_pcie_host_match,
> + .suppress_bind_attrs = true,
> + },
> +};
next prev parent reply other threads:[~2023-08-17 17:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 12:08 [RFC PATCH 0/2] Add support to build pci-j721e as a kernel module Achal Verma
2023-08-17 12:08 ` [RFC PATCH 1/2] PCI: cadence: Add support to build pcie-cadence library " Achal Verma
2023-08-17 12:08 ` [RFC PATCH 2/2] PCI: j721e: Add support to build pci-j721e " Achal Verma
2023-08-17 17:04 ` Bjorn Helgaas [this message]
2023-09-05 10:39 ` [EXTERNAL] " Verma, Achal
2023-09-05 16:37 ` 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=20230817170417.GA320486@bhelgaas \
--to=helgaas@kernel.org \
--cc=a-verma1@ti.com \
--cc=bhelgaas@google.com \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=robh@kernel.org \
--cc=tjoseph@cadence.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).