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: Tue, 8 Jun 2021 08:02:07 -0500	[thread overview]
Message-ID: <20210608130207.GA2597738@bjorn-Precision-5520> (raw)
In-Reply-To: <4aecc0f0-692c-026b-f1dd-0a03ccf4312b@nvidia.com>

On Tue, Jun 08, 2021 at 08:44:49AM +0100, Jon Hunter wrote:
> On 08/06/2021 00:50, Bjorn Helgaas wrote:
> 
> ...
> 
> > My understanding is that we want pcie-tegra194.c to be:
> > 
> >   - Built into the kernel when CONFIG_PCIE_TEGRA194=m or =y and
> >     CONFIG_ACPI=y and CONFIG_PCI_QUIRKS=y.  If we're using the ACPI
> >     pci_root.c driver, we must have the MCFG quirk built-in, and this
> >     case worked as I expected (this is on x86):
> > 
> >       $ grep -E "CONFIG_(ACPI\>|PCI_QUIRKS|PCIE_TEGRA194)" .config
> >       CONFIG_ACPI=y
> >       CONFIG_PCI_QUIRKS=y
> >       CONFIG_PCIE_TEGRA194=y
> >       CONFIG_PCIE_TEGRA194_HOST=m
> >       CONFIG_PCIE_TEGRA194_EP=y
> > 
> >       $ rm drivers/pci/controller/dwc/pcie-tegra194.*o
> >       $ make drivers/pci/controller/dwc/
> > 	...
> > 	CC      drivers/pci/controller/dwc/pcie-tegra194.o
> > 	AR      drivers/pci/controller/dwc/built-in.a
> > 
> >   - Built as a module when CONFIG_PCIE_TEGRA194=m and CONFIG_ACPI is
> >     not set.  In this case, we're not using the ACPI pci_root.c
> >     driver, and we don't need the MCFG quirk built-in, so it should be
> >     OK to build a module, and IIUC this patch is supposed to *allow*
> >     that.  But in my testing, it did *not* build a module.  Am I
> >     missing something?
> > 
> >       $ grep -E "CONFIG_(ACPI\>|PCI_QUIRKS|PCIE_TEGRA194)" .config
> >       # CONFIG_ACPI is not set
> >       # CONFIG_PCI_QUIRKS is not set
> >       CONFIG_PCIE_TEGRA194=y
> >       CONFIG_PCIE_TEGRA194_HOST=m
> >       CONFIG_PCIE_TEGRA194_EP=y
> 
> The problem appears to be that you still have CONFIG_PCIE_TEGRA194=y and
> CONFIG_PCIE_TEGRA194_EP=y above. If I have ...

Huh.  I can't set CONFIG_PCIE_TEGRA194 directly; it's only selectable
by PCIE_TEGRA194_HOST and PCIE_TEGRA194_EP.  PCIE_TEGRA194 is
tristate, but apparently kconfig sets it to the most restrictive,
which I guess makes sense.

So I would expect the shared infrastructure to be built-in if either
driver is built-in, but it's somewhat confusing that
CONFIG_PCIE_TEGRA194_HOST=m results in a builtin driver.  If I can set
CONFIG_PCIE_TEGRA194_HOST and CONFIG_PCIE_TEGRA194_EP independently,
it seems like they should *be* independent.

What is the purpose of PCIE_TEGRA194_EP (added by c57247f940e8 ("PCI:
tegra: Add support for PCIe endpoint mode in Tegra194") [1])?  I don't
see any reference to it in a makefile or a source file.

It looks like one can build a single driver that works in either host
or endpoint mode, depending on whether a DT node matches
"nvidia,tegra194-pcie" or "nvidia,tegra194-pcie-ep".

So I think PCIE_TEGRA194_EP is superfluous and should be removed and
you should have a single tristate Kconfig option.

Tangentially related, this cast in tegra_pcie_dw_probe() looks
unnecessary:

  pcie->mode = (enum dw_pcie_device_mode)data->mode;

Looks like it was copied from similar code in dra7xx_pcie_probe(),
artpec6_pcie_probe(), and dw_plat_pcie_probe(), which are all littered
with similar unnecessary casts.  But that should be solved separately
from the Kconfig question.

[1] https://git.kernel.org/linus/c57247f940e8

> $ grep -E "CONFIG_(ACPI\>|PCI_QUIRKS|PCIE_TEGRA194)" .config
> # CONFIG_ACPI is not set
> CONFIG_PCI_QUIRKS=y
> CONFIG_PCIE_TEGRA194=m
> CONFIG_PCIE_TEGRA194_HOST=m
> # CONFIG_PCIE_TEGRA194_EP is not set
> 
> 
> > 
> >       $ rm drivers/pci/controller/dwc/pcie-tegra194.*o
> >       $ make drivers/pci/controller/dwc/
> > 	...
> > 	CC      drivers/pci/controller/dwc/pcie-tegra194.o
> > 	AR      drivers/pci/controller/dwc/built-in.a
> 
> Then I see ...
> 
> $ rm drivers/pci/controller/dwc/pcie-tegra194.*o
> $ make drivers/pci/controller/dwc/
>   ...
>   CC [M]  drivers/pci/controller/dwc/pcie-tegra194.o
> 
> Cheers
> Jon
> 
> -- 
> nvpublic

  reply	other threads:[~2021-06-08 13:02 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
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 [this message]
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=20210608130207.GA2597738@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.