All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Vidya Sagar" <vidyas@nvidia.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH V2] PCI: tegra: Fix building Tegra194 PCIe driver
Date: Thu, 20 May 2021 17:19:48 -0500	[thread overview]
Message-ID: <20210520221948.GA352305@bjorn-Precision-5520> (raw)
In-Reply-To: <20210520090123.11814-1-jonathanh@nvidia.com>

On Thu, May 20, 2021 at 10:01:23AM +0100, Jon Hunter wrote:
> Commit 7f100744749e ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM
> errata") caused a few build regressions for the Tegra194 PCIe driver
> which are:
> 
> 1. The Tegra194 PCIe driver can no longer be built as a module. This
>    was caused by removing the Makefile entry to build the pcie-tegra.c
>    based upon the CONFIG_PCIE_TEGRA194 option. Therefore, restore this
>    so that we can build the driver as a module if ACPI support is not
>    enabled in the kernel.

I'm not sure what "if ACPI support is not enabled in the kernel" is
telling me.  Does it mean that we can only build tegra194 as a module
if ACPI is not enabled?  I don't think so (at least, I don't think
Kconfig enforces that).

Should the "if ACPI support is not enabled ..." part just be dropped?

I assume it should be possible to build the kernel with ACPI enabled
and with pcie-tegra194 as a module?

> 2. If CONFIG_PCIE_TEGRA194 is configured to build the driver as a
>    module, at the same time that CONFIG_ACPI and CONFIG_PCI_QUIRKS are
>    selected to build the driver into the kernel, then the necessary
>    functions in the driver to probe and remove the device when booting
>    with device-tree and not compiled into to the driver. This prevents
>    the PCIe devices being probed when booting with device-tree. Fix this
>    by using the IS_ENABLED() macro.

The #ifdef vs IS_ENABLED() difference is kind of subtle and I have to
figure it out every time.  Maybe something like this?

  7f100744749e ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM
  errata") added "#ifdef CONFIG_PCIE_TEGRA194" around the native
  driver.

  But if we set CONFIG_PCIE_TEGRA194=m to build the driver as a
  module, autoconf.h contains "#define CONFIG_PCIE_TEGRA194_MODULE 1"
  (not "#define CONFIG_PCIE_TEGRA194 1"), so the #ifdef excludes the
  driver.

  Instead, use "IS_ENABLED(CONFIG_PCIE_TEGRA194)", which checks for
  either CONFIG_PCIE_TEGRA194 or CONFIG_PCIE_TEGRA194_MODULE.

> 3. The below build warnings to be seen with particular kernel
>    configurations. Fix these by adding the necessary guards around these
>    variable definitions.
> 
>   drivers/pci/controller/dwc/pcie-tegra194.c:259:18: warning:
>   	‘event_cntr_data_offset’ defined but not used [-Wunused-const-variable=]
>   drivers/pci/controller/dwc/pcie-tegra194.c:250:18: warning:
>   	‘event_cntr_ctrl_offset’ defined but not used [-Wunused-const-variable=]
>   drivers/pci/controller/dwc/pcie-tegra194.c:243:27: warning:
>   	‘pcie_gen_freq’ defined but not used [-Wunused-const-variable=]
> 
> Fixes: 7f100744749e ("PCI: tegra: Add Tegra194 MCFG quirks for ECAM errata")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>

This is a candidate for v5.13, since we merged 7f100744749e for
v5.13-rc1.

> ---
>  drivers/pci/controller/dwc/Makefile        | 1 +
>  drivers/pci/controller/dwc/pcie-tegra194.c | 6 +++++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
> index eca805c1a023..f0d1e2d8c022 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
>  # depending on whether ACPI, the DT driver, or both are enabled.
>  
>  obj-$(CONFIG_PCIE_AL) += pcie-al.o
> +obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
>  obj-$(CONFIG_PCI_HISI) += pcie-hisi.o

It sounds like the interesting case is this:

  CONFIG_ARM64=y
  CONFIG_ACPI=y
  CONFIG_PCI_QUIRKS=y
  CONFIG_PCIE_TEGRA194=m

I don't know how this works in this case:

  obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
  obj-$(CONFIG_ARM64) += pcie-tegra194.o

We want tegra194_acpi_init() and the rest of the ECAM quirk to be
compiled into the static kernel.  And we want tegra_pcie_dw_probe(),
tegra_pcie_dw_remove(), etc, compiled into a module.

Does kbuild really compile pcie-tegra194.c twice?  And if so, it's not
a problem that both the static kernel and the module contain a
tegra194_pcie_ops symbol?

>  ifdef CONFIG_ACPI
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index b19775ab134e..ae70e53a7826 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -240,13 +240,16 @@
>  #define EP_STATE_DISABLED	0
>  #define EP_STATE_ENABLED	1
>  
> +#if IS_ENABLED(CONFIG_PCIE_TEGRA194)
>  static const unsigned int pcie_gen_freq[] = {
>  	GEN1_CORE_CLK_FREQ,
>  	GEN2_CORE_CLK_FREQ,
>  	GEN3_CORE_CLK_FREQ,
>  	GEN4_CORE_CLK_FREQ
>  };
> +#endif

This makes the minimal patch, but as Krzysztof suggests, I would
prefer to move the whole struct so it's just inside the
CONFIG_PCIE_TEGRA194 #ifdef.

> +#if defined(CONFIG_PCIEASPM)
>  static const u32 event_cntr_ctrl_offset[] = {
>  	0x1d8,
>  	0x1a8,
> @@ -264,6 +267,7 @@ static const u32 event_cntr_data_offset[] = {
>  	0x1c8,
>  	0x1dc
>  };
> +#endif

Similar for the CONFIG_PCIEASPM #ifdef.

>  struct tegra_pcie_dw {
>  	struct device *dev;
> @@ -409,7 +413,7 @@ const struct pci_ecam_ops tegra194_pcie_ops = {
>  };
>  #endif /* defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS) */
>  
> -#ifdef CONFIG_PCIE_TEGRA194
> +#if IS_ENABLED(CONFIG_PCIE_TEGRA194)
>  static inline struct tegra_pcie_dw *to_tegra_pcie(struct dw_pcie *pci)
>  {
> -- 
> 2.25.1
> 

  parent reply	other threads:[~2021-05-20 22:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20  9:01 [PATCH V2] PCI: tegra: Fix building Tegra194 PCIe driver Jon Hunter
2021-05-20  9:57 ` Krzysztof Wilczyński
2021-05-20 22:19 ` Bjorn Helgaas [this message]
2021-05-21 13:11   ` Jon Hunter
2021-06-07 23:50     ` Bjorn Helgaas
2021-06-08  7:44       ` Jon Hunter
2021-06-08 13:02         ` Bjorn Helgaas
2021-06-08 13:20           ` Jon Hunter
2021-06-08 18:34             ` Vidya Sagar
2021-06-08 20:11               ` Jon Hunter
2021-06-09 10:23                 ` Jon Hunter
2021-06-09 14:00                   ` Vidya Sagar
2021-06-09 16:18                 ` Bjorn Helgaas
2021-06-09 17:07                   ` Jon Hunter

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=20210520221948.GA352305@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=jonathanh@nvidia.com \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=thierry.reding@gmail.com \
    --cc=vidyas@nvidia.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.