Linux ACPI
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Haakon Bugge <haakon.bugge@oracle.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Alex Williamson <alex@shazbot.org>,
	Johannes Thumshirn	 <morbidrsa@gmail.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org"	 <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org"	 <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] PCI: Initialize RCB from pci_configure_device
Date: Fri, 23 Jan 2026 19:54:07 +0100	[thread overview]
Message-ID: <ae149906c5e27513235c7f347b8b1dfed82b8dd1.camel@linux.ibm.com> (raw)
In-Reply-To: <7E4D523D-5105-4173-AC1A-8B7898DC48A8@oracle.com>

On Fri, 2026-01-23 at 17:38 +0000, Haakon Bugge wrote:
> > > On Thu, 2026-01-22 at 14:09 +0100, Håkon Bugge wrote:
> > > Commit e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff
> > > Root Port supports it (_HPX)") fixed a bogus _HPX type 2 record, which
> > > instructed program_hpx_type2() to set the RCB in an endpoint,
> > > although it's RC did not have the RCB bit set.
> > > 
> > > --- snip ---
> > > 
> > > +static bool pcie_read_root_rcb(struct pci_dev *dev, bool *rcb)
> > > +{
> > > +	struct pci_dev *rp = pcie_find_root_port(dev);
> > > +	u16 lnkctl;
> > > +
> > > +	if (!rp)
> > > +		return false;
> > > +
> > > +	pcie_capability_read_word(rp, PCI_EXP_LNKCTL, &lnkctl);
> > > +
> > > +	*rcb = !!(lnkctl & PCI_EXP_LNKCTL_RCB);
> > > +	return true;
> > > +}
> > 
> > In principle this is one of these things where platforms like s390
> > where the root port is hidden (only s390?) might want a hook to use
> > firmware supplied information to determine if the hidden root port
> > supports the setting. I wonder if this would make sense as a __weak
> > pcibios_read_rcb_supported() function. Not saying we need this now,
> > just thinking out loud.
> 
> That may be a good idea. But I am not quite sure how we can find the Root Port from an "orphan" bridge or endpoint through the pci_bios_read set of interfaces.

I only meant to have it as a function in a similar manner to e.g.
pcibios_enable_device() that we could override. But I don't think that
needs or even should be part of this patch as there wouldn't be a user
of the override yet.

> 
> > > +
> > > +static void pci_configure_rcb(struct pci_dev *dev)
> 
--- snip ---
> > > +
> > > +	pcie_capability_read_word(dev, PCI_EXP_LNKCTL, &lnkctl);
> > > +	if (rcb) {
> > > +		if (lnkctl & PCI_EXP_LNKCTL_RCB)
> > > +			return;
> > > +
> > > +		lnkctl |= PCI_EXP_LNKCTL_RCB;
> > > +	} else {
> > > +		if (!(lnkctl & PCI_EXP_LNKCTL_RCB))
> > > +			return;
> > > +
> > > +		pci_info(dev, FW_INFO "clearing RCB (RCB not set in Root Port)\n");
> > 
> > The FW_INFO in here seems to be a remnant from ACPI code. As far as I
> > know this isn't usually used in core PCI code and seems conceptually
> > misleading to me since this doesn't come out of ACPI or other firmware
> > code.
> 
> I humbly disagree. As per PCIe r7.0, sec 7.5.3.7: "Default value of this bit is 0b". So, if we find it set, and it is not set in the Root Port, to me, it must be a firmware bug. And that is exactly what FW_INFO is intended for: "Introduce FW_BUG, FW_WARN and FW_INFO to consistenly tell users about BIOS bugs" (commit a0ad05c75aa3).

Ah thanks for the pointer, I wasn't aware of this explicit "for
reporting FW issues" use. Reading commit a0ad05c75aa3 ("Introduce
FW_BUG, FW_WARN and FW_INFO to consistenly tell users about BIOS bugs")
now I agree this makes sense after all.

> 
> > > +		lnkctl &= ~PCI_EXP_LNKCTL_RCB;
> > > +	}
> > > +
> > > +	pcie_capability_write_word(dev, PCI_EXP_LNKCTL, lnkctl);
> > 
--- snip ---
> > 
> > I tested that this patch series does not create problems on s390 and
> > would leave the RCB setting as is if our firmware set it. Since the
> > second patch doesn't touch code that is build on s390 I think the
> > Tested-by only makes sense for this one.
> > 
> > So feel free to add my:
> > 
> > Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
> 
> Thanks a lot for the testing!
> 
> > Furthermore with either the FW_INFO dropped or Ilpo's suggestion
> > incorporated feel free to also add:
> > 
> > Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
> 
> Thanks for the conditional r-b. I'll like Bjorn to chime in here, as he introduced FW_INFO and did not object to the existing (non Ilpo variant).

As stated above with the additional explanation this makes sense to me
now so no need for the conditional anymore either ;)

Thanks,
Niklas

  reply	other threads:[~2026-01-23 18:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 13:09 [PATCH v3 0/2] PCI: Init RCB from pci_configure_device and fix program_hpx_type2 Håkon Bugge
2026-01-22 13:09 ` [PATCH v3 1/2] PCI: Initialize RCB from pci_configure_device Håkon Bugge
2026-01-22 13:45   ` Ilpo Järvinen
2026-01-22 15:53     ` Haakon Bugge
2026-01-27 21:58     ` Bjorn Helgaas
2026-01-23 13:05   ` Niklas Schnelle
2026-01-23 17:38     ` Haakon Bugge
2026-01-23 18:54       ` Niklas Schnelle [this message]
2026-01-27 17:28         ` Haakon Bugge
2026-01-27 22:11   ` Bjorn Helgaas
2026-01-28 17:08     ` Haakon Bugge
2026-01-28 17:20       ` Bjorn Helgaas
2026-01-22 13:09 ` [PATCH v3 2/2] PCI/ACPI: Confine program_hpx_type2 to the AER bits Håkon Bugge
2026-01-27 22:24   ` Bjorn Helgaas
2026-01-28 17:19     ` Haakon Bugge
2026-01-29 16:36       ` Haakon Bugge

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=ae149906c5e27513235c7f347b8b1dfed82b8dd1.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=alex@shazbot.org \
    --cc=bhelgaas@google.com \
    --cc=haakon.bugge@oracle.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=morbidrsa@gmail.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