From: jonathanh@nvidia.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] bus: tegra-aconnect: make it explicitly non-modular
Date: Mon, 4 Jul 2016 14:47:26 +0100 [thread overview]
Message-ID: <577A68EE.3040402@nvidia.com> (raw)
In-Reply-To: <20160704134123.GV26134@windriver.com>
On 04/07/16 14:41, Paul Gortmaker wrote:
> [Re: [PATCH 3/4] bus: tegra-aconnect: make it explicitly non-modular] On 04/07/2016 (Mon 10:17) Jon Hunter wrote:
>
>> Hi Paul,
>>
>> On 03/07/16 18:30, Paul Gortmaker wrote:
>>> The Kconfig currently controlling compilation of this code is:
>>>
>>> drivers/bus/Kconfig:config TEGRA_ACONNECT
>>> drivers/bus/Kconfig: bool "Tegra ACONNECT Bus Driver"
>>>
>>> ...meaning that it currently is not being built as a module by anyone.
>>>
>>> Lets remove the modular code that is essentially orphaned, so that
>>> when reading the driver there is no doubt it is builtin-only.
>>>
>>> We explicitly disallow a driver unbind, since that doesn't have a
>>> sensible use case anyway, and it allows us to drop the ".remove"
>>> code for non-modular drivers.
>>>
>>> Since module_platform_driver() uses the same init level priority as
>>> builtin_platform_driver() the init ordering remains unchanged with
>>> this commit.
>>>
>>> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>>>
>>> We also delete the MODULE_LICENSE tag etc. since all that information
>>> was (or is now) contained at the top of the file in the comments.
>>
>> In version 3 of the aconnect series [0] I had made this a tristate
>> because we allowed it to be removed and you had submitted a patch to
>> export the PM_CLK APIs. However, when discussing with Thierry he said
>> that we were unable to merge with tristate because of the dependency on
>> your patch. So he suggested we merge with bool for now and then change
>> it back to tristate for v4.9.
>
> Oh I see. The exported clock syms were for the 210 DMA driver and it
> never crossed my mind that this driver needed the same syms in order for
> it to be tristate. Guess the exports proved useful afterall. :)
Yes indeed and I did learn my lesson after your previous catch for the
ADMA ;-)
>>
>> I understand that we should not do this, but we do plan to make this
>> modular in the future.
>
> No problem ; I will drop this patch in favor of a one line Kconfig patch
> in my test queue so it doesn't trip the regular audit, just like I have
> for the 210 below -- not yet submitted for the same dependency reason.
>
> P.
> ---
>
>
> From fe5bdc6348828c157deb14e8d75c732abcc2ad2b Mon Sep 17 00:00:00 2001
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Fri, 20 May 2016 14:30:43 -0400
> Subject: [PATCH] dma: tegra210-adma: convert TEGRA210_ADMA from bool to
> tristate
>
> This driver currently uses modular infrastructure but is controlled
> by a bool Kconfig.
>
> There is a general consensus from the DMA reviewers and maintainers
> that "if it can be modular, it should be modular" in order to keep
> the bzImage size under control for multi platform kernels.
>
> Build tested only. Also needs some new pm_clk symbols exported
> before this commit is applied to tree in order to avoid modpost
> errors like:
>
> ERROR: "pm_clk_add_clk" [drivers/dma/tegra210-adma.ko] undefined!
> ERROR: "pm_clk_create" [drivers/dma/tegra210-adma.ko] undefined!
> ERROR: "pm_clk_destroy" [drivers/dma/tegra210-adma.ko] undefined!
> ERROR: "pm_clk_suspend" [drivers/dma/tegra210-adma.ko] undefined!
> ERROR: "pm_clk_resume" [drivers/dma/tegra210-adma.ko] undefined!
>
> Cc: Laxman Dewangan <ldewangan@nvidia.com>
> Cc: Jon Hunter <jonathanh@nvidia.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: dmaengine at vger.kernel.org
> Cc: linux-tegra at vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> drivers/dma/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 8c98779a12b1..866068d84ca2 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -468,7 +468,7 @@ config TEGRA20_APB_DMA
> or vice versa. It does not support memory to memory data transfer.
>
> config TEGRA210_ADMA
> - bool "NVIDIA Tegra210 ADMA support"
> + tristate "NVIDIA Tegra210 ADMA support"
> depends on ARCH_TEGRA_210_SOC
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
Thanks! FWIW ...
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
next prev parent reply other threads:[~2016-07-04 13:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-03 17:30 [PATCH v2 0/4] bus: remove unused modular code from non-modular drivers Paul Gortmaker
2016-07-03 17:30 ` [PATCH 1/4] bus: brcmstb_gisb: make it explicitly non-modular Paul Gortmaker
2016-07-14 22:34 ` Florian Fainelli
2016-07-03 17:30 ` [PATCH 2/4] bus: imx-weim: " Paul Gortmaker
2016-07-03 17:30 ` [PATCH 3/4] bus: tegra-aconnect: " Paul Gortmaker
2016-07-04 9:17 ` Jon Hunter
2016-07-04 13:41 ` Paul Gortmaker
2016-07-04 13:47 ` Jon Hunter [this message]
2016-07-03 17:30 ` [PATCH 4/4] bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate Paul Gortmaker
2016-07-04 14:18 ` Geert Uytterhoeven
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=577A68EE.3040402@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.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 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).