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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9EBDC433F5 for ; Tue, 30 Nov 2021 18:35:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245485AbhK3Si2 (ORCPT ); Tue, 30 Nov 2021 13:38:28 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:44552 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244668AbhK3Si0 (ORCPT ); Tue, 30 Nov 2021 13:38:26 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 16A16B818F9; Tue, 30 Nov 2021 18:35:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4D51C53FC7; Tue, 30 Nov 2021 18:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638297303; bh=dmWxrwodX74CblEMoop7i738yKwTIqHPQZdl6UnJp0U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bMmOHGM+iQXJLxU2/6t+I0YU0yYQpg0uyrnHGKd76mveQerfjBwJFNfcDX+fBOMlV oi5/ZoRSFmqECvaht3bsXVaM86DJ6zGMShb8QWyFdPWBJjBw0+y/xRM44OHo7EutSC j4WIGP+Y/2pddIfqWShg/As1sR3wfbbNBgyjVevXaKx0h2RTmd9anqvz1DU+e6JrZN 13eVFRBrR4SNqhsWAmDmAeFkdliOPhA7kUmA/kbN8UjHhVTHC7+jgHzDwXLETtrbid cffp8LRfKq4cHAKtKLiSXQ0FmUh2d9yhB4t/Tz/u+uCFoAbYTw6s2MqAoghwLsfXGE 60fGBOpaqHcYA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ms7y1-008xP9-Lt; Tue, 30 Nov 2021 18:35:01 +0000 Date: Tue, 30 Nov 2021 18:35:01 +0000 Message-ID: <87czmhmqzu.wl-maz@kernel.org> From: Marc Zyngier To: Bjorn Helgaas Cc: Manivannan Sadhasivam , lorenzo.pieralisi@arm.com, bhelgaas@google.com, svarbanov@mm-sol.com, bjorn.andersson@linaro.org, robh@kernel.org, linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, kernel test robot , Alyssa Rosenzweig , Sven Peter Subject: Re: [PATCH] PCI: qcom: Fix warning generated due to the incorrect data type In-Reply-To: <20211130160338.GA2739234@bhelgaas> References: <20211130062137.GD205712@thinkpad> <20211130160338.GA2739234@bhelgaas> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: helgaas@kernel.org, manivannan.sadhasivam@linaro.org, lorenzo.pieralisi@arm.com, bhelgaas@google.com, svarbanov@mm-sol.com, bjorn.andersson@linaro.org, robh@kernel.org, linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, lkp@intel.com, alyssa@rosenzweig.io, sven@svenpeter.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, 30 Nov 2021 16:03:38 +0000, Bjorn Helgaas wrote: > > [+cc Marc, Alyssa, Sven for RID-to-SID mapping insight. The patch at > https://lore.kernel.org/all/20211130062137.GD205712@thinkpad/ merely > fixes a warning. My meta-question is about the qcom BDF-to-SID > mapping.] > > On Tue, Nov 30, 2021 at 11:51:37AM +0530, Manivannan Sadhasivam wrote: > > On Mon, Nov 29, 2021 at 09:36:14PM -0600, Bjorn Helgaas wrote: > > > ... > > > I'm also curious why pcie-qcom.c is the only driver that does this. > > > "iommu-map" is not specific to qcom, but no other drivers do similar > > > things with it. > > > > Yes, on the recent qcom platforms starting from sm8250 we need to program > > the BDF to SID mapping in the controller and that's the reason we are > > extracting the "iommu-map" property in DT. > > This sounds like something that may not really be specific to sm8250. > > It looks vaguely similar to apple_pcie_add_device(). Compare the qcom > code at [1] with the Apple code at [2]. It looks indeed similar in spirit, though the implementation seems different. The qcom code seems to brute-force the mappings upfront, while the apple driver relies on bus notifiers to map things on demand. The annoying thing with these blocks is that they are neither part of the IOMMU nor the PCIe block. It is just a piece of glue logic in the middle... Thanks, M. -- Without deviation from the norm, progress is not possible.