Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp775646pxk; Thu, 1 Oct 2020 13:35:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmUwkJ3eqEvUbSXiPr5fXJDodrOF7ZU7nHVl0Bm88qr23GyXMTDoI7jIk/32v67h4OGWXi X-Received: by 2002:a17:906:2301:: with SMTP id l1mr9659236eja.488.1601584512095; Thu, 01 Oct 2020 13:35:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601584512; cv=none; d=google.com; s=arc-20160816; b=sff4CbmWxpl9dk5QvXAMoEfhIPknBg7PfIV/kloWywwSNKeoFtz3SsFZlVqnGHf44X Zsjeaj6D07PrgNqF6E2sVlPR3S9AH+DDnr/bnRIyN5tcWcK2fZk7vtNIrHRM2wu/RxPf 6wyjljw5S8Pek1zNHUZBA8OlQxIPJoFsAXMp04i67zZEiGm0Q8jdpiX3T95/O/OT08ac AOSf1p5QIJEf4FY1P5BoVY7LZvaNeg9fB90yo3ge0+6KTjJ64va7JKHMPTkiYLlsdRMw AmtqAutLduKiR+3J889NkaBD+QyRMpfGl0OwHsGnO3nYEw7CR90FrV+a46ehUFkdzZ6M reqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=HFskIQxSh3pcFkxZ3RI+nqtU31LBSYrV7T+aRIb+B54=; b=tBbYP9yXqJuCoMEF5POwpfXaW5qc7UT0gt55tBUXKjJPeQHyLSjxU4KuIY0ztoTmJY UDin4hQioMQUz3CYtcD16HQeLN9/8H7i0RidplQAhCByYxR140TSzDixrR4fxsDwGY+i t1+vcUxvOCG4Mj28ePZHYe55RBFMcVdE0AvGVE7qH93KmVUZ0QzJ4h8uq4dbl28ew7O8 muYvyFX46q8MOpXyAo0KHmH/qSOhSZ+bkZc07grCFrvKpdPjVvMBfzbrnUXhWU11d88a iIgbROmWmR4S1cB5Z1W8FMYJg/+u8Wwdz0M3Rc40t54ffkFuAoy4gxq43hCyZozNziRs BOiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ss8dIJh6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c14si4067420edj.174.2020.10.01.13.34.49; Thu, 01 Oct 2020 13:35:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ss8dIJh6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730008AbgJAUdn (ORCPT + 99 others); Thu, 1 Oct 2020 16:33:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726515AbgJAUdn (ORCPT ); Thu, 1 Oct 2020 16:33:43 -0400 Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90B11C0613D0; Thu, 1 Oct 2020 13:33:42 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id m5so209241lfp.7; Thu, 01 Oct 2020 13:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HFskIQxSh3pcFkxZ3RI+nqtU31LBSYrV7T+aRIb+B54=; b=ss8dIJh6Gvzh5FabnueDMuIgWAM2w32VQ/xq+kK5CLOYOKw2OlM7XLIsQ0cYHnx5ES 3BHVFeOTTpJgE2c3Y+V3nC7Gr/aHHuQ11LtIDJRGy2WTI2vZLZ7mkKeY2u3ZqoWLv5Dr lrb2tZsmmX2feonsncEhcrza8CMi+IHQL9/28Iz+9TS19gP8TIJMrB9Kcow9NAyjvWFd SKY3CU5jcl5YDlpVzxe8TRBPkM6DS97MnwlFKrgCSvVIFROKikpN7OeURpH51mUgrqfw 9C4xEDaQJPzDvTvsf7BemRUrWsU/cGNvyF6e+3qR9KZ6H8s7UmOqTqIrjd3tIu1HEOmB hkpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HFskIQxSh3pcFkxZ3RI+nqtU31LBSYrV7T+aRIb+B54=; b=JKxq3fxxjAMfVLKqHCOvlx4RyKiFyRlXZFkmrS/SH0cRclEFQKSCscpWNXaVrYT/rR fwdWKN2m04jeMk0b6vCQAjDYjs8zRrfodTNLwTRPjSXnzUmq+sYR7gZMzAhDt5WP0Iav gUnwoeHrzdgVC/rmhTu7vxVpwFBVoNY59T+w7iuHvWXB5w2sfzl1jmVt6MRYBclUMVOV IyH3UNrow8tVXG7/Sa3amSF9PnsYXzGZagACkRNrWWFXzFxDuqWsIua7I36AJT6IGaKd KE32dR2kpGRXCyo8PXpssUYnCRDQP44eYgGvymcbCn4R5SjpfT6WcdAkat4z+hazdomy 4G0w== X-Gm-Message-State: AOAM531nQp6dU/zrUaRQXncha60I6efk+ldx8Unxfa1KI6uRmM1qwDy4 GzUnSq2fUFT/h6fe5jnvjrQQoEDQ9eM= X-Received: by 2002:ac2:4d8e:: with SMTP id g14mr3647566lfe.386.1601584420568; Thu, 01 Oct 2020 13:33:40 -0700 (PDT) Received: from [192.168.2.145] ([109.252.91.252]) by smtp.googlemail.com with ESMTPSA id a12sm551799ljk.109.2020.10.01.13.33.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 13:33:39 -0700 (PDT) Subject: Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev To: Nicolin Chen , Thierry Reding Cc: joro@8bytes.org, krzk@kernel.org, vdumpa@nvidia.com, jonathanh@nvidia.com, linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org References: <20200930084258.25493-3-nicoleotsuka@gmail.com> <20200930153131.GB3833404@ulmo> <20200930203618.GC2110@Asurada-Nvidia> <13746922-0253-cda7-e9ac-2bd20bf1a17f@gmail.com> <20200930213244.GA10573@Asurada-Nvidia> <5945a63e-79d8-e3ae-ab53-cee8c220ac7d@gmail.com> <20201001012630.GA28240@Asurada-Nvidia> <72b11925-5857-8ce5-d084-cab01ca1b396@gmail.com> <20201001024850.GA28456@Asurada-Nvidia> <20201001102316.GF3919720@ulmo> <20201001110425.GB1272@Asurada> From: Dmitry Osipenko Message-ID: Date: Thu, 1 Oct 2020 23:33:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201001110425.GB1272@Asurada> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 01.10.2020 14:04, Nicolin Chen пишет: > On Thu, Oct 01, 2020 at 12:23:16PM +0200, Thierry Reding wrote: > > > >>>>>> It looks to me like the only reason why you need this new global API is >>>>>>>>>> because PCI devices may not have a device tree node with a phandle to >>>>>>>>>> the IOMMU. However, SMMU support for PCI will only be enabled if the >>>>>>>>>> root complex has an iommus property, right? In that case, can't we >>>>>>>>>> simply do something like this: >>>>>>>>>> >>>>>>>>>> if (dev_is_pci(dev)) >>>>>>>>>> np = find_host_bridge(dev)->of_node; >>>>>>>>>> else >>>>>>>>>> np = dev->of_node; > >>> I personally am not a fan of adding a path for PCI device either, >>> since PCI/IOMMU cores could have taken care of it while the same >>> path can't be used for other buses. >> >> There's already plenty of other drivers that do something similar to >> this. Take a look at the arm-smmu driver, for example, which seems to be >> doing exactly the same thing to finding the right device tree node to >> look at (see dev_get_dev_node() in drivers/iommu/arm-smmu/arm-smmu.c). > > Hmm..okay..that is quite convincing then... Not very convincing to me. I don't see a "plenty of other drivers", there is only one arm-smmu driver. The dev_get_dev_node() is under CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS (!). Guys, doesn't it look strange to you? :) The arm-smmu driver does a similar thing for the modern bindings to what Nicolin's v3 is doing. >>> If we can't come to an agreement on globalizing mc pointer, would >>> it be possible to pass tegra_mc_driver through tegra_smmu_probe() >>> so we can continue to use driver_find_device_by_fwnode() as v1? >>> >>> v1: https://lkml.org/lkml/2020/9/26/68 >> >> tegra_smmu_probe() already takes a struct tegra_mc *. Did you mean >> tegra_smmu_probe_device()? I don't think we can do that because it isn't > > I was saying to have a global parent_driver pointer: similar to > my v1, yet rather than "extern" the tegra_mc_driver, we pass it > through egra_smmu_probe() and store it in a static global value > so as to call tegra_smmu_get_by_fwnode() in ->probe_device(). > > Though I agree that creating a global device pointer (mc) might > be controversial, yet having a global parent_driver pointer may > not be against the rule, considering that it is common in iommu > drivers to call driver_find_device_by_fwnode in probe_device(). You don't need the global pointer if you have SMMU OF node. You could also get driver pointer from mc->dev->driver. But I don't think you need to do this at all. The probe_device() could be invoked only for the tegra_smmu_ops and then seems you could use dev_iommu_priv_set() in tegra_smmu_of_xlate(), like sun50i-iommu driver does.