public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Manikandan Karunakaran Pillai <mpillai@cadence.com>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
	"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
	"kw@linux.com" <kw@linux.com>,
	"manivannan.sadhasivam@linaro.org"
	<manivannan.sadhasivam@linaro.org>,
	"robh@kernel.org" <robh@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/7] PCI: cadence: Add support for PCIe Endpoint HPA controllers
Date: Wed, 9 Apr 2025 17:15:59 -0500	[thread overview]
Message-ID: <20250409221559.GA299990@bhelgaas> (raw)
In-Reply-To: <CH2PPF4D26F8E1C61F700C22A738FF8846DA2A12@CH2PPF4D26F8E1C.namprd07.prod.outlook.com>

On Thu, Mar 27, 2025 at 11:40:36AM +0000, Manikandan Karunakaran Pillai wrote:
> Add support for the second generation(HPA) Cadence PCIe endpoint
> controller by adding the required functions based on the HPA registers
> and register bit definitions

Add period.

> @@ -93,7 +93,10 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
>  	 * for 64bit values.
>  	 */
>  	sz = 1ULL << fls64(sz - 1);
> -	aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
> +	/*
> +	 * 128B -> 0, 256B -> 1, 512B -> 2, ...
> +	 */
> +	aperture = ilog2(sz) - 7;

Unclear exactly how this is related to HPA and whether it affects
non-HPA.

> @@ -121,7 +124,7 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
>  		reg = CDNS_PCIE_LM_EP_VFUNC_BAR_CFG(bar, fn);
>  	else
>  		reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG(bar, fn);
> -	b = (bar < BAR_4) ? bar : bar - BAR_4;
> +	b = (bar < BAR_3) ? bar : bar - BAR_3;

Unclear what's going on here because this doesn't look specific to
HPA.  Should this be a separate patch that fixes an existing defect?

>  	if (vfn == 0 || vfn == 1) {
>  		cfg = cdns_pcie_readl(pcie, reg);
> @@ -158,7 +161,7 @@ static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn, u8 vfn,
>  		reg = CDNS_PCIE_LM_EP_VFUNC_BAR_CFG(bar, fn);
>  	else
>  		reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG(bar, fn);
> -	b = (bar < BAR_4) ? bar : bar - BAR_4;
> +	b = (bar < BAR_3) ? bar : bar - BAR_3;

And here.

> @@ -569,7 +572,11 @@ static int cdns_pcie_ep_start(struct pci_epc *epc)
>  	 * BIT(0) is hardwired to 1, hence function 0 is always enabled
>  	 * and can't be disabled anyway.
>  	 */
> -	cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, epc->function_num_map);
> +	if (pcie->is_hpa)
> +		cdns_pcie_hpa_writel(pcie, REG_BANK_IP_REG,
> +				     CDNS_PCIE_HPA_LM_EP_FUNC_CFG, epc->function_num_map);
> +	else
> +		cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, epc->function_num_map);

Sprinkling tests of "is_hpa" around is not very extensible.  When the
next generation after HPA shows up, then it gets really messy.
Sometimes generation-specific function pointers can make this simpler.

> +static int cdns_pcie_hpa_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
> +				    struct pci_epf_bar *epf_bar)
> +{
> +	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> +	struct cdns_pcie_epf *epf = &ep->epf[fn];
> +	struct cdns_pcie *pcie = &ep->pcie;
> +	dma_addr_t bar_phys = epf_bar->phys_addr;
> +	enum pci_barno bar = epf_bar->barno;
> +	int flags = epf_bar->flags;
> +	u32 addr0, addr1, reg, cfg, b, aperture, ctrl;
> +	u64 sz;
> +
> +	/*
> +	 * BAR size is 2^(aperture + 7)
> +	 */
> +	sz = max_t(size_t, epf_bar->size, CDNS_PCIE_EP_MIN_APERTURE);
> +	/*

Add blank line between code and comment.

> +	 * roundup_pow_of_two() returns an unsigned long, which is not suited
> +	 * for 64bit values.
> +	 */
> +	sz = 1ULL << fls64(sz - 1);
> +	/*

Again.  Check for other places in this series.

> +	 * 128B -> 0, 256B -> 1, 512B -> 2, ...
> +	 */
> +	aperture = ilog2(sz) - 7;

  reply	other threads:[~2025-04-09 22:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250327105429.2947013-1-mpillai@cadence.com>
2025-03-27 10:59 ` [PATCH 0/7] Enhance the PCIe controller driver Manikandan Karunakaran Pillai
     [not found]   ` <20250327111106.2947888-1-mpillai@cadence.com>
2025-03-27 11:19     ` [PATCH 1/7] dt-bindings: pci: cadence: Extend compatible for new platform configurations Manikandan Karunakaran Pillai
2025-03-27 14:15       ` Krzysztof Kozlowski
2025-03-28  5:07         ` Manikandan Karunakaran Pillai
2025-03-28  7:20           ` Krzysztof Kozlowski
2025-03-28  8:22       ` Krzysztof Kozlowski
2025-03-28  8:48         ` Hans Zhang
2025-03-28  9:17           ` Krzysztof Kozlowski
2025-03-30 14:59             ` Hans Zhang
     [not found]   ` <20250327111127.2947944-1-mpillai@cadence.com>
2025-03-27 11:26     ` [PATCH 2/7] PCI: cadence: Add header support for PCIe next generation controllers Manikandan Karunakaran Pillai
2025-03-27 12:01       ` Hans Zhang
2025-04-09 20:39       ` Bjorn Helgaas
2025-04-11  4:16         ` Manikandan Karunakaran Pillai
     [not found]   ` <20250327111200.2948071-1-mpillai@cadence.com>
2025-03-27 11:40     ` [PATCH 4/7] PCI: cadence: Add support for PCIe Endpoint HPA controllers Manikandan Karunakaran Pillai
2025-04-09 22:15       ` Bjorn Helgaas [this message]
2025-04-11  4:23         ` Manikandan Karunakaran Pillai
     [not found]   ` <20250327111241.2948184-1-mpillai@cadence.com>
2025-03-27 11:42     ` [PATCH 6/7] PCI: cadence: Add callback functions for Root Port and EP controller Manikandan Karunakaran Pillai
2025-04-09 22:45       ` Bjorn Helgaas
2025-04-11  4:26         ` Manikandan Karunakaran Pillai
     [not found]   ` <20250327111256.2948250-1-mpillai@cadence.com>
2025-03-27 11:43     ` [PATCH 7/7] PCI: cadence: Update support for TI J721e boards Manikandan Karunakaran Pillai
2025-03-27 12:03   ` [PATCH 0/7] Enhance the PCIe controller driver Hans Zhang
2025-03-27 14:16   ` Krzysztof Kozlowski
2025-03-27 14:43     ` Manikandan Karunakaran Pillai
2025-03-27 14:46       ` Krzysztof Kozlowski
2025-04-09 17:08   ` manivannan.sadhasivam
2025-04-11  4:08     ` Manikandan Karunakaran Pillai
2025-04-09 20:11   ` Bjorn Helgaas
2025-04-11  4:10     ` Manikandan Karunakaran Pillai

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=20250409221559.GA299990@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=mpillai@cadence.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