From: Bjorn Helgaas <helgaas@kernel.org>
To: Jim Quinlan <james.quinlan@broadcom.com>
Cc: linux-pci@vger.kernel.org,
"Nicolas Saenz Julienne" <nsaenz@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Cyril Brulebois" <kibi@debian.org>,
"Stanimir Varbanov" <svarbanov@suse.de>,
bcm-kernel-feedback-list@broadcom.com, jim2101024@gmail.com,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Rob Herring" <robh@kernel.org>,
"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
<linux-rpi-kernel@lists.infradead.org>,
"moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 1/6] PCI: brcmstb: Refactor max speed limit functionality
Date: Thu, 6 Feb 2025 11:04:17 -0600 [thread overview]
Message-ID: <20250206170417.GA989059@bhelgaas> (raw)
In-Reply-To: <20250205191213.29202-2-james.quinlan@broadcom.com>
On Wed, Feb 05, 2025 at 02:12:01PM -0500, Jim Quinlan wrote:
> Make changes to the code that limits the PCIe max speed.
>
> (1) Do the changes before link-up, not after. We do not want
> to temporarily rise to a higher speed than desired.
This is a functional change that should be split into its own patch.
That will also make it obvious that this is not simple refactoring as
the subject line advertises.
> (2) Use constants from pci_reg.h when possible
> (3) Use uXX_replace_bits(...) for setting a register field.
> (4) Use the internal link capabilities register for writing
> the max speed, not the official config space register
> where the speed field is RO. Updating this field is
> not necessary to limit the speed so this mistake was
> harmless.
Also a bug fix (though harmless in this case) that deserves to be
split out so the distinction between the internal and the architected
paths to the register is highlighted and may help prevent the same
mistake in the future.
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 546056f7f0d3..f8fc3d620ee2 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -47,6 +47,7 @@
>
> #define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY 0x04dc
> #define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_ASPM_SUPPORT_MASK 0xc00
> +#define PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_SPEED_MASK 0xf
If the format of this internal register is different, of course we
need a new #define for this. But if this is just a different path to
LNKCAP, and both paths read the same bits in the same format, I don't
see the point of a new #define.
> #define PCIE_RC_CFG_PRIV1_ROOT_CAP 0x4f8
> #define PCIE_RC_CFG_PRIV1_ROOT_CAP_L1SS_MODE_MASK 0xf8
> @@ -413,12 +414,12 @@ static int brcm_pcie_set_ssc(struct brcm_pcie *pcie)
> static void brcm_pcie_set_gen(struct brcm_pcie *pcie, int gen)
> {
> u16 lnkctl2 = readw(pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
> - u32 lnkcap = readl(pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
> + u32 lnkcap = readl(pcie->base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
>
> - lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
> - writel(lnkcap, pcie->base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
> + u32p_replace_bits(&lnkcap, gen, PCIE_RC_CFG_PRIV1_LINK_CAPABILITY_MAX_LINK_SPEED_MASK);
> + writel(lnkcap, pcie->base + PCIE_RC_CFG_PRIV1_LINK_CAPABILITY);
>
> - lnkctl2 = (lnkctl2 & ~0xf) | gen;
> + u16p_replace_bits(&lnkctl2, gen, PCI_EXP_LNKCTL2_TLS);
OK. I am not really a fan of the uXX_replace_bits() thing because
it's not widely used (I found 341 instances tree-wide, compared to
14000+ for FIELD_PREP()), grep can't find the definition easily, and
stylistically it doesn't fit with GENMASK(), FIELD_PREP(), etc.
But it's already used throughout brcmstb.c, so we should be
consistent.
next prev parent reply other threads:[~2025-02-06 17:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 19:12 [PATCH v1 0/6] PCI: brcmstb: Misc small tweaks and fixes Jim Quinlan
2025-02-05 19:12 ` [PATCH v1 1/6] PCI: brcmstb: Refactor max speed limit functionality Jim Quinlan
2025-02-06 17:04 ` Bjorn Helgaas [this message]
2025-02-06 18:27 ` Jim Quinlan
2025-02-06 20:18 ` Bjorn Helgaas
2025-02-05 19:12 ` [PATCH v1 2/6] PCI: brcmstb: Fix error path upon call of regulator_bulk_get() Jim Quinlan
2025-02-06 17:29 ` Bjorn Helgaas
2025-02-06 18:22 ` Jim Quinlan
2025-02-06 18:34 ` Bjorn Helgaas
2025-02-06 19:39 ` Jim Quinlan
2025-02-05 19:12 ` [PATCH v1 3/6] PCI: brcmstb: Fix potential premature regluator disabling Jim Quinlan
2025-02-06 17:32 ` Bjorn Helgaas
2025-02-06 17:57 ` Jim Quinlan
2025-02-05 19:12 ` [PATCH v1 4/6] PCI: brcmstb: Use same constant table for config space access Jim Quinlan
2025-02-05 19:12 ` [PATCH v1 5/6] PCI: brcmstb: Make two changes in MDIO register fields Jim Quinlan
2025-02-05 19:12 ` [PATCH v1 6/6] PCI: brcmstb: Cast an int variable to an irq_hw_number_t Jim Quinlan
2025-02-06 22:19 ` Stefan Wahren
2025-02-14 16:17 ` Jim Quinlan
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=20250206170417.GA989059@bhelgaas \
--to=helgaas@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=james.quinlan@broadcom.com \
--cc=jim2101024@gmail.com \
--cc=kibi@debian.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=nsaenz@kernel.org \
--cc=robh@kernel.org \
--cc=svarbanov@suse.de \
/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).