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 CA0041AA792; Wed, 13 Nov 2024 09:02:52 +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=1731488572; cv=none; b=mc1mgFvGLGjGnqQ5qpVuA77XWqKPC80gm3qOUISs99GT3LO0+f1lp+PxTGPLHxC76hxOyJhQvxBpgH7Q48KQ5z8+v/7afEn3V5QlY5bHBPYwAbKYqXp2q0d8cn6fUnXzvGwMJ7FUIMzQGvUTYiw2LEU2+SALT8YeSj8zb62mtA0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731488572; c=relaxed/simple; bh=MzLQHt+3PfSd3dpTibUH9DS+k1l1DF3kNMz+O6gVQRE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MN/amnu62NYFBgQv8NlEq65KajtjPX1lW/HB9ttGO5F30PbDH7U/Q5PfqBbLgHZ3YZ2r6a7Fe83JUiHNBvjV7tOmVMYTz9pEtvO8BVZPnD9FZnh4bh2QtpWNoPyYFGjyezcJja0y0CMFSsayBsNScf45IeLsMevSC1d0w+iYkaM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bqbAeIzY; 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="bqbAeIzY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 388C7C4CECD; Wed, 13 Nov 2024 09:02:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731488572; bh=MzLQHt+3PfSd3dpTibUH9DS+k1l1DF3kNMz+O6gVQRE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bqbAeIzYcofcVumgxn76QLfoNSKtZtK9yVE0jAT3IhKetTbKxw/jwQfVziUGwd1ga 2dv1zvzx4fQxQwMV8TBU4HlYoi8sGZkiKzFgd28d/lpkgB+clwfTNrr+M7q08qJobN ryxPd2ItezUnYliYdmKQuo8T7AGYyXM/zrpNTvaCrql7yPNOdnJAe0WmLP0TdvY5In lxUvL0dPLdNN99CDzt3hT0w7EovxHQb0QzkwLZv7/A8ZCWTHY8nj7QUNqKcljwaLC2 cw7EwRqrRjAgRjAHMQpn7PDRLyKo2zk0aih4hDHLB0Lld0aMR63mAzJLkpp31jjRlb BnmXrZEWmfcBQ== Date: Wed, 13 Nov 2024 10:02:46 +0100 From: Niklas Cassel To: Frank Li Cc: Manivannan Sadhasivam , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Kishon Vijay Abraham I , Bjorn Helgaas , Arnd Bergmann , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, dlemoal@kernel.org, maz@kernel.org, tglx@linutronix.de, jdmason@kudzu.us Subject: Re: [PATCH v6 3/5] PCI: endpoint: pci-epf-test: Add doorbell test support Message-ID: References: <20241112-ep-msi-v6-0-45f9722e3c2a@nxp.com> <20241112-ep-msi-v6-3-45f9722e3c2a@nxp.com> Precedence: bulk X-Mailing-List: linux-pci@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: On Tue, Nov 12, 2024 at 03:37:34PM -0500, Frank Li wrote: > > > > Is there a reason why you chose to not incorporate the helper function > > that I suggested here: > > https://lore.kernel.org/linux-pci/ZzMtKUFi30_o6SwL@ryzen/ > > > > I didn't see any reply from you to that message. > > Oh, you said at > https://lore.kernel.org/imx/ZzIVzfkZe-hkAb4G@ryzen/T/#mc10e69e0e1e20cc8d8da9a8808177407d22bce06 > > I think you give up your idea about helper function, because it is one > for doorbell_offset, the other is for the atu address. bar's struct is > difference with reg. even it is similar, Yes, that is why the helper returns both base addess and offset (just like .align_addr()). > Do you means add help function, which wrap epc's .align_addr()? I know you > make some improvement about EP's alignment, but I have not realized that > related this thread at all. Look at the suggested helper that I wrote in: https://lore.kernel.org/linux-pci/ZzMtKUFi30_o6SwL@ryzen/ If you think that the code is cleaner, feel free to incorporate it in your next version, no need to add my SoB. .align_addr() is not related at all. (.align_addr() is for alignment for outbound PCI address, and theoretically the alignment requirement for outbound could be different from inbound address alignment requirement (which is defined in epc->features->align). The only relation is that both my suggested helper, and .align_addr() both return a base address and an offset. > May "I now see why you did this. > One function is using the db offset, and the other is using the db base." > mis-lead me. Yes, I can see that this sentence can be misunderstood. > If I understand correct here, I can add wrap function for epc's > .align_addr(). at next version. Please do not wrap .align_addr(). Kishon has been very clear that he wants outbound and inbound translation requirements to not depend on each other. Kind regards, Niklas