From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC5F83CF04D; Wed, 11 Mar 2026 10:39:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773225540; cv=none; b=UzOBBPCxAQQv5kg/zT1hqixT4xTLLs+gTWtS1wkcU1tZ19mDujasgiPAVcvmrCwJnEAnfa21Fi/vSQIkFKb36bEELD1Wvs+N/C/IyEt4cgmL/uUkag5oMprTJuBTchAA3/UWkOO0+5OOQYvqPC4K5DD28voZiB1JsSdBfItRC8A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773225540; c=relaxed/simple; bh=W7ULGNJxGs/DGU9Myuy1oXiG5LI/4bcuMikaWvPhafA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Vm+aP3yctBDRtCWqnFAbrhsLMv+GvCt7vAiOubkbb6owKfm1QtaPFF2r1dRxYhrliQ5saMHzH6WYaSEkEd8vQklpxTi+JQbZIB6rJ1YAW/iXzsBJtnbdRnPx1pr9l7rOqQuwGg+a/ZLITo4LFcdwOWRrTa0jestAHF7/3OD4AjE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EPXTMuVt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EPXTMuVt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4256C2BC86; Wed, 11 Mar 2026 10:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773225540; bh=W7ULGNJxGs/DGU9Myuy1oXiG5LI/4bcuMikaWvPhafA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EPXTMuVttZqUZ/o7JPPcYnite3Um4wggHLpvXqpIoWuC2usNA6k425SfK6rMs77rB CYWeP0jsQTNUcUIy8PnTh9S3O1nsMJGjNBhq2Dq0SHWq7cP3w5ZyXyw9RdDTA3R1eW S440F5uh0GmInYEkvybjOxJt938zdDJqpyKVdapOCNKsje+vi1+1YLP/xkfpiLNDws 05TBCJ8PNE7rD4f12++HjlcvSoHkNaTbYC0bbQKnbCiOof2KrsmYEZaZiY5R+JFXdj /8xPc+/68mvyzrREgIspZOqMj2/RD7sCmgpK/s0D84g4YnUN/WpSgEaH93P51o62GI KrW++eDJAd9HA== Date: Wed, 11 Mar 2026 11:38:50 +0100 From: Niklas Cassel To: Manivannan Sadhasivam Cc: Minghuan Lian , Mingkai Hu , Roy Zang , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Bjorn Helgaas , Srikanth Thokala , Thierry Reding , Jonathan Hunter , Kunihiko Hayashi , Masami Hiramatsu , Marek Vasut , Yoshihiro Shimoda , Geert Uytterhoeven , Magnus Damm , Kishon Vijay Abraham I , Manikanta Maddireddy , Koichiro Den , Damien Le Moal , Frank Li , linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev, linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH v3 1/9] PCI: endpoint: Introduce pci_epc_bar_type BAR_64BIT_UPPER Message-ID: References: <20260302095913.48155-11-cassel@kernel.org> <20260302095913.48155-12-cassel@kernel.org> Precedence: bulk X-Mailing-List: linux-tegra@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hello Mani, On Wed, Mar 11, 2026 at 12:05:59PM +0530, Manivannan Sadhasivam wrote: (snip) > This also brings the question, do we really need to mark the preceding BAR? >From a pure code PoV, marking the preceding BAR is enough even with the current code: https://github.com/torvalds/linux/blob/v7.0-rc3/drivers/pci/endpoint/pci-epc-core.c#L101-L103 However, the current documentation claims that the succeeding BAR must be marked as BAR_RESERVED: https://github.com/torvalds/linux/blob/v7.0-rc3/include/linux/pci-epc.h#L207-L210 I want to change this to BAR_64BIT_UPPER / BAR_64BIT_UPPER_BASE, so we can use BAR_RESERVED for BARs that expose fixed hardware resources (e.g. eDMA regs). Thus, an EPC driver does not strictly need mark the succeeding BAR with anything. This was done mostly for clarity. (E.g. with BAR_64BIT_UPPER_BASE it is obvious that this BAR cannot be a standalone 32-bit BAR.) If we don't mark the succeeding BAR with anything, IMO, it is less obvious that the succeeding BAR cannot be used as a standalone 32-bit BAR. But... since the code already does the "right thing". We could simply nuke this part of the documentation, and drop the .type for all BARs succeeding a .only_64bit BAR, if you prefer that option over having a dedicated type for the "upper base of a 64-bit BAR". > Why can't we let the PCI EPC core to always assume that if the previous BAR > has 'only_64bit' bit set, next BAR cannot be used as a standalone 32bit BAR? > > I find it weird or redundant to mark both BARs. Redundant, yes, but in my opinion marking both BARs makes it unambigious that two BARs are used when a BAR is "only_64bit". E.g. Manikanta originally wanted to add code comments for the upper part of the 64-bit BAR: https://lore.kernel.org/linux-pci/20260217-master-v1-2-727e26cdfaf5@nvidia.com/ Sure, we can just skip the .type for the succeeding BAR... But is that really better than clearly showing that a "forced" 64-bit BAR will always occupy two BARs? Tell me what you prefer: 1) s/BAR_RESERVED/BAR_64BIT_UPPER_BASE/ 2) Change documentation and drop .type for a BAR following a .only_64bit BAR. And I will respin with that. Kind regards, Niklas