Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Randolph Lin <randolph@andestech.com>
Cc: linux-pci@vger.kernel.org, ben717@andestech.com, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, alex@ghiti.fr, jingoohan1@gmail.com,
	mani@kernel.org, lpieralisi@kernel.org, kwilczynski@kernel.org,
	bhelgaas@google.com, randolph.sklin@gmail.com,
	tim609@andestech.com, Frank Li <Frank.Li@nxp.com>
Subject: Re: [PATCH 5/6] PCI: andes: Add Andes QiLai SoC PCIe host driver support
Date: Mon, 8 Sep 2025 17:07:37 -0500	[thread overview]
Message-ID: <20250908220737.GA1467566@bhelgaas> (raw)
In-Reply-To: <aLF0-0u38hKC7JcP@atctrx.andestech.com>

[+cc Frank, who can probably answer faster than I can]

On Fri, Aug 29, 2025 at 05:41:17PM +0800, Randolph Lin wrote:
> Rn Wed, Aug 20, 2025 at 10:54:44AM -0500, Bjorn Helgaas wrote:
> > On Wed, Aug 20, 2025 at 07:18:42PM +0800, Randolph Lin wrote:
> > > Add driver support for DesignWare based PCIe controller in Andes
> > > QiLai SoC. The driver only supports the Root Complex mode.

> > > +#define PCIE_LOGIC_COHERENCY_CONTROL3                0x8e8
> > > +/* Write-Back, Read and Write Allocate */
> > > +#define IOCP_ARCACHE                         0xf
> > > +/* Write-Back, Read and Write Allocate */
> > > +#define IOCP_AWCACHE                         0xf
> > 
> > Are IOCP_ARCACHE and IOCP_AWCACHE supposed to be identical values with
> > identical comments?

Just pointing this out since you didn't respond to it.

> > > +static u64 qilai_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 cpu_addr)
> > > +{
> > > +     struct dw_pcie_rp *pp = &pci->pp;
> > > +
> > > +     return cpu_addr - pp->cfg0_base;
> > 
> > Sorry, we can't do this.  We're removing .cpu_addr_fixup() because
> > it's a workaround for defects in the DT description.  See these
> > commits, for example:
> > 
> >     befc86a0b354 ("PCI: dwc: Use parent_bus_offset to remove need for .cpu_addr_fixup()")
> >     b9812179f601 ("PCI: imx6: Remove imx_pcie_cpu_addr_fixup()")
> >     07ae413e169d ("PCI: intel-gw: Remove intel_pcie_cpu_addr()")
> 
> I’m a bit confused about the following question:
> After removing cpu_addr_fixup, should we use pci->parent_bus_offset
> to store the offset value, or should pci->parent_bus_offset remain
> 0?

If you needed qilai_pcie_cpu_addr_fixup(), I would expect your
dw_pcie.parent_bus_offset to be non-zero because parent_bus_offset is
used instead of ->cpu_addr_fixup().

> In the commit message:
> befc86a0b354 ("PCI: dwc: Use parent_bus_offset to remove need for .cpu_addr_fixup()")
>     We know the parent_bus_offset, either computed from a DT reg
>     property (the offset is the CPU physical addr - the
>     'config'/'addr_space' address on the parent bus) or from a
>     .cpu_addr_fixup() (which may have used a host bridge window
>     offset).
> 
> We know that "the offset is the CPU physical addr - the
> 'config'/'addr_space' address on the parent bus".
> 
> However, in dw_pcie_host_get_resources(), it passes pp->cfg0_base,
> which is parsed from the device tree using "config", as the
> cpu_phys_addr parameter to dw_pcie_parent_bus_offset(). It also
> passes "config" as the 2nd parameter to dw_pcie_parent_bus_offset().
> 
> In dw_pcie_parent_bus_offset(), the 2nd parameter is used to get the
> index from the devicetree "reg-names" field, and the result is used
> as the 'config'/'addr_space' address. 
> 
> It seems that the same value is being obtained through a different
> method, and the return value appears to be 0.  Could I be
> misunderstanding something?


  reply	other threads:[~2025-09-08 22:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20 11:18 [PATCH 0/6] Add support for Andes Qilai SoC PCIe controller Randolph Lin
2025-08-20 11:18 ` [PATCH 1/6] riscv: dts: andes: Define dma-ranges for coherent port Randolph Lin
2025-08-20 11:18 ` [PATCH 2/6] PCI: dwc: Add outbound ATU range check callback Randolph Lin
2025-08-20 15:52   ` Bjorn Helgaas
2025-08-20 11:18 ` [PATCH 3/6] dt-bindings: Add Andes QiLai PCIe support Randolph Lin
2025-08-21  6:11   ` Krzysztof Kozlowski
2025-08-20 11:18 ` [PATCH 4/6] riscv: dts: andes: Add PCIe node into the QiLai SoC Randolph Lin
2025-08-20 11:18 ` [PATCH 5/6] PCI: andes: Add Andes QiLai SoC PCIe host driver support Randolph Lin
2025-08-20 15:54   ` Bjorn Helgaas
2025-08-29  9:41     ` Randolph Lin
2025-09-08 22:07       ` Bjorn Helgaas [this message]
2025-09-09  8:14         ` Randolph Lin
2025-09-09 15:02           ` Frank Li
2025-09-08  7:02   ` Manivannan Sadhasivam
2025-09-09  6:59     ` Randolph Lin
2025-08-20 11:18 ` [PATCH 6/6] MAINTAINERS: Add maintainers for Andes QiLai PCIe driver Randolph Lin

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=20250908220737.GA1467566@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=ben717@andestech.com \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=randolph.sklin@gmail.com \
    --cc=randolph@andestech.com \
    --cc=robh@kernel.org \
    --cc=tim609@andestech.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