From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 55323CD4F3D for ; Fri, 22 May 2026 22:43:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=5PJOo0ni1XYQzQF6Rj7ozcEQoTTxGYPgOEd77Drbvg8=; b=u3QkAK3xmKxz0j TLi84ftWUmcLNLkLOx0OZT7cOpPgemvUsh1en28ORXWdoNsLVZ0VrGBsY7PEgjufol11xNplpR9AS NTuU2lGW0AgvqaVwmMeX/0MoixYico8NUQCH7Es9P7IRIqHVSZcvV5OZW4xUd+Rl0AKSxYRRBrY7e Va/cvEn/RaNVXLWVA8ecyFN/Zq7d92YpxWL8wMKPbgzeB/SqU6OyeZMw44i4tV+3vYc/UpWzQkL6I DsfKRPWWY/nyVZMiZRNTSmajwsMU52XP3LJZ1PIAywZWzx15OYcZ1ohlmXwnuiGhtxAmtYgSkWcvB lmrrCtkWvG1xwCDQgWEw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wQYaX-0000000C8IJ-3g3e; Fri, 22 May 2026 22:43:29 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wQYaV-0000000C8Ho-2Wmz for linux-mediatek@lists.infradead.org; Fri, 22 May 2026 22:43:28 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with UTF8SMTP id 9DCE4441CB; Fri, 22 May 2026 22:43:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id 4C9E71F000E9; Fri, 22 May 2026 22:43:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779489806; bh=5PJOo0ni1XYQzQF6Rj7ozcEQoTTxGYPgOEd77Drbvg8=; h=Date:From:To:Cc:Subject:In-Reply-To; b=IdDfrQIg+fZetrCkoTY0IauSrN4pHDMvMCxGY6SoKkgD5tgrspCUzYZQpQzHAOqbT QXQVrtWcPrQRkxosIwSpEtDfOS6rSrlACxGKW/PBv03KOsoX65Mdy9MA/+f6JUR9eR ueexrCTVtPqe8ESjPDSBLkhBS9ILa5ej8UiYVIqanlW8ZSkA3LbEZgblgPNt+R9Bnu 7Gf+STLjWCmo6hB1EnAMIetldKDp0DZm4HMq7+j375HUETEZmukv7vdE2CZHXuoARU PTcWt87VHL7K0liTAXhPMgXbUTxGR3EgigqlVeGe450cRjU4RGrzQmVqyAoFRi58vb BFnpd67/wiXWw== Date: Fri, 22 May 2026 17:43:25 -0500 From: Bjorn Helgaas To: Manivannan Sadhasivam Cc: Caleb James DeLisle , linux-pci@vger.kernel.org, linux-mips@vger.kernel.org, naseefkm@gmail.com, ryder.lee@mediatek.com, lpieralisi@kernel.org, kwilczynski@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, ansuelsmth@gmail.com, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Manivannan Sadhasivam Subject: Re: [PATCH v8 1/3] PCI: mediatek: Use actual physical address instead of virt_to_phys() Message-ID: <20260522224325.GA195169@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7xfp5nbtd4qtonoqurfwoedsix7vondrnfeip53uwjintuvc6a@cg3ez6z3pii5> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260522_154327_686902_D670C2E9 X-CRM114-Status: GOOD ( 51.26 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Thu, May 21, 2026 at 10:44:51AM +0530, Manivannan Sadhasivam wrote: > On Wed, May 20, 2026 at 02:59:00PM -0500, Bjorn Helgaas wrote: > > On Wed, May 20, 2026 at 09:17:35PM +0200, Caleb James DeLisle wrote: > > > > > > On 20/05/2026 20:55, Bjorn Helgaas wrote: > > > > On Wed, May 20, 2026 at 06:38:25PM +0000, Caleb James DeLisle wrote: > > > > > From: Manivannan Sadhasivam > > > > > > > > > > The driver previously used virt_to_phys() on the ioremapped register base > > > > > (port->base) to compute the MSI message address. Using virt_to_phys() on an > > > > > IO mapped address is incorrect because it expects a kernel virtual address. > > > > > > > > > > To fix it, store the physical start of the I/O register region in > > > > > mtk_pcie_port->phys_base and use it to build the MSI address. This replaces > > > > > the incorrect virt_to_phys() usage and ensures MSI addresses are generated > > > > > correctly. > > > > > > > > > > Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") > > > > > Signed-off-by: Manivannan Sadhasivam > > > > > Tested-by: Caleb James DeLisle > > > > > --- > > > > > drivers/pci/controller/pcie-mediatek.c | 16 +++++++++++++--- > > > > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c > > > > > index 75722524fe74..c503fbd774d0 100644 > > > > > --- a/drivers/pci/controller/pcie-mediatek.c > > > > > +++ b/drivers/pci/controller/pcie-mediatek.c > > > > > @@ -175,6 +175,7 @@ struct mtk_pcie_soc { > > > > > /** > > > > > * struct mtk_pcie_port - PCIe port information > > > > > * @base: IO mapped register base > > > > > + * @phys_base: Physical address of the I/O register base region > > > > > * @list: port list > > > > > * @pcie: pointer to PCIe host info > > > > > * @reset: pointer to port reset control > > > > > @@ -196,6 +197,7 @@ struct mtk_pcie_soc { > > > > > */ > > > > > struct mtk_pcie_port { > > > > > void __iomem *base; > > > > > + phys_addr_t phys_base; > > > > > struct list_head list; > > > > > struct mtk_pcie *pcie; > > > > > struct reset_control *reset; > > > > > @@ -405,7 +407,7 @@ static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) > > > > > phys_addr_t addr; > > > > > /* MT2712/MT7622 only support 32-bit MSI addresses */ > > > > > - addr = virt_to_phys(port->base + PCIE_MSI_VECTOR); > > > > > + addr = port->phys_base + PCIE_MSI_VECTOR; > > > > > > > > This doesn't look right because the MSI address is a PCI bus address, > > > > and port->phys_base is a CPU physical address. Often a PCI bus > > > > address is the same as the CPU physical address, but not always. > > > > I think the DT 'ranges' property tells you the translation. > > > > Oops, sorry, I muddied the waters here. > > > > 'ranges' tells you the translation applied by a bridge, e.g., when > > a CPU does a load/store, the PCI host bridge turns it into a PCI > > read/write transaction. The bridge might add an offset to the CPU > > load/store physical address to get the PCI read/write bus address. > > > > But that's not the issue here. The MSI is basically a DMA write > > performed by the PCI device, not a store done by a CPU, so I don't > > think 'ranges' is the right thing to look at. > > Yeah, it is so easy to confuse both. To summarise, 'ranges' > describes the outbound translation and 'dma-ranges' describes the > inbound translation from host perspective. > > > Based on this: > > https://elinux.org/Device_Tree_Usage#PCI_DMA_Address_Translation I > > think 'dma-ranges' is the relevant property. I don't think your > > DT includes a 'dma-ranges' property, and in that case the default > > is that the system bus (CPU) address is the same as the PCI > > address. > > > > So I think this patch works because it assumes DMA addresses like > > the MSI address are mapped to identical system bus addresses. > > > > It still seems to me that drivers should be prepared for the > > presence of dma-ranges and use it when computing the MSI target > > address. But I don't think any drivers really do that, so for now > > I think you should pretend that I never responded about this > > patch. > > Your observations are correct. This driver assumes that the > identical mapping exists between CPU and PCI bus addresses. Usually, > the drivers make use of phys_to_dma() to handle the translations. What does this look like in the native host bridge drivers? I don't see any direct calls of phys_to_dma(), but there are some higher-level interfaces that use it. I don't really see a consistent style of constructing MSI addresses, e.g., in *_compose_msi_msg() implementations. > This API internally makes use of the 'dma_range_map' which gets > populated by the OF core based on the 'dma-ranges' property (if > present in DT). > > But it makes sense to use it irrespective of whether the platform > supports non-identical DMA/inbound translation or not. Since this > API behaves like a no-op and returns the CPU physical address if > there is an identical mapping, there is literally zero overhead in > using it. Thanks for rescuing me. I wonder if there should be something in Documentation/core-api/dma-api* about this. I guess that is mostly oriented toward things like PCI device drivers, not so much PCI host bridge drivers. But it would be nice to have a little intro to dma-ranges and maybe even the restricted DMA usage. Bjorn