public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@kernel.org>
To: Mikko Perttunen <mperttunen@nvidia.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Jon Hunter" <jonathanh@nvidia.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2 4/5] PCI: tegra: Add Tegra264 support
Date: Thu, 26 Mar 2026 11:45:48 +0100	[thread overview]
Message-ID: <acUFJlWDAQQsr6Tm@orome> (raw)
In-Reply-To: <177441053067.494795.3366002972241434311.b4-review@b4>

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

On Wed, Mar 25, 2026 at 12:48:50PM +0900, Mikko Perttunen wrote:
> On Fri, 20 Mar 2026 23:54:36 +0100, Thierry Reding <thierry.reding@kernel.org> wrote:
> > diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> > new file mode 100644
> > index 000000000000..3ce1ad971bdb
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-tegra264.c
> > @@ -0,0 +1,527 @@
> > [ ... skip 123 lines ... ]
> > +	err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> > +	if (err)
> > +		dev_info(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
> > +			 pcie->ctl_id, ERR_PTR(err));
> > +
> > +	if (msg.rx.ret)
> > +		dev_info(pcie->dev, "failed to turn off PCIe #%u: %d\n",
> > +			 pcie->ctl_id, msg.rx.ret);
> > +}
> 
> Ideally we would distinguish by message in these two cases. I suppose
> the %pe vs. %d does that, but it's not quite obvious.

Agreed. I think something like:

	"BPMP transfer failed for PCIe #%u: %pe"

would work better for the first message. That's roughly in line with
other error messages for BPMP message transfer errors (as opposed to the
errors returned from BPMP as a result of a successful transfer).

> 
> > +
> > +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> > +{
> > +	u32 value, speed, width, bw;
> > +	int err;
> > +
> > +	value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> > +	speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> > +	width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> > +
> > +	bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
> 
> PCIE_SPEED2MBS_ENC takes enum pci_bus_speed values rather than
> LNKSTA_CLS values. Perhaps it should be converted to a static inline
> function to catch such issues.

Nice catch. speed should be indexing pcie_link_speed to get the right
enum value. I've fixed that up.

> 
> > +	value = MBps_to_icc(bw);
> 
> The result of this is unused.

Ugh... this is supposed to be the value that's passed to icc_set_bw()
but I forgot to plumb that through. Fixed now.

> 
> > [ ... skip 271 lines ... ]
> > +	pcie->ecam = pcie->cfg->win;
> > +
> > +	tegra264_pcie_init(pcie);
> > +
> > +	if (!pcie->link_up)
> > +		goto free;
> 
> This path causes things to be freed, but the driver still probes. The
> remove callback will then try to remove things again.

I think the intent of the original code was to allow the driver to
continue to probe, so that the root complex would show up, but with no
devices enumerated. I don't know if we really need that, since we also
have no hotplug support there's never going to be any devices added to
the bus if the initial link up fails, as far as I can tell. I'll turn
this into a failure for now, we can revisit this if we ever need hotplug
support.

Thanks,
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-03-26 10:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20 22:54 [PATCH v2 0/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-03-20 22:54 ` [PATCH v2 1/5] soc/tegra: Update BPMP ABI header Thierry Reding
2026-03-20 22:54 ` [PATCH v2 2/5] firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function Thierry Reding
2026-03-25  2:28   ` Mikko Perttunen
2026-03-26 10:00     ` Thierry Reding
2026-03-20 22:54 ` [PATCH v2 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller Thierry Reding
2026-03-25  1:24   ` Rob Herring (Arm)
2026-03-20 22:54 ` [PATCH v2 4/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-03-24  8:22   ` kernel test robot
2026-03-25  3:48   ` Mikko Perttunen
2026-03-26 10:45     ` Thierry Reding [this message]
2026-03-20 22:54 ` [PATCH v2 5/5] arm64: tegra: Add PCI controllers on Tegra264 Thierry Reding

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=acUFJlWDAQQsr6Tm@orome \
    --to=thierry.reding@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=mperttunen@nvidia.com \
    --cc=robh@kernel.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