All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Nicolin Chen <nicoleotsuka@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
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
Subject: Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev
Date: Thu, 1 Oct 2020 23:33:38 +0300	[thread overview]
Message-ID: <b966844e-4289-3ff0-9512-852f8419a664@gmail.com> (raw)
In-Reply-To: <20201001110425.GB1272@Asurada>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Nicolin Chen <nicoleotsuka@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: linux-kernel@vger.kernel.org, krzk@kernel.org,
	jonathanh@nvidia.com, iommu@lists.linux-foundation.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev
Date: Thu, 1 Oct 2020 23:33:38 +0300	[thread overview]
Message-ID: <b966844e-4289-3ff0-9512-852f8419a664@gmail.com> (raw)
In-Reply-To: <20201001110425.GB1272@Asurada>

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.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-10-01 20:33 UTC|newest]

Thread overview: 132+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30  8:42 [PATCH v3 0/3] iommu/tegra-smmu: Add PCI support Nicolin Chen
2020-09-30  8:42 ` Nicolin Chen
2020-09-30  8:42 ` [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller() Nicolin Chen
2020-09-30  8:42   ` Nicolin Chen
2020-09-30  9:07   ` Krzysztof Kozlowski
2020-09-30  9:07     ` Krzysztof Kozlowski
2020-09-30  9:41     ` Nicolin Chen
2020-09-30  9:41       ` Nicolin Chen
2020-09-30 10:27       ` Krzysztof Kozlowski
2020-09-30 10:27         ` Krzysztof Kozlowski
2020-09-30 14:41   ` Dmitry Osipenko
2020-09-30 14:41     ` Dmitry Osipenko
2020-09-30 14:45     ` Krzysztof Kozlowski
2020-09-30 14:45       ` Krzysztof Kozlowski
2020-09-30 15:22       ` Dmitry Osipenko
2020-09-30 15:22         ` Dmitry Osipenko
2020-09-30 15:23   ` Thierry Reding
2020-09-30 15:23     ` Thierry Reding
2020-09-30 15:27     ` Dmitry Osipenko
2020-09-30 15:27       ` Dmitry Osipenko
2020-09-30 15:53     ` Dmitry Osipenko
2020-09-30 15:53       ` Dmitry Osipenko
2020-09-30 16:03       ` Thierry Reding
2020-09-30 16:03         ` Thierry Reding
2020-09-30 16:06         ` Dmitry Osipenko
2020-09-30 16:06           ` Dmitry Osipenko
2020-09-30 16:15           ` Thierry Reding
2020-09-30 16:15             ` Thierry Reding
2020-09-30 16:26             ` Dmitry Osipenko
2020-09-30 16:26               ` Dmitry Osipenko
2020-09-30 16:38               ` Thierry Reding
2020-09-30 16:38                 ` Thierry Reding
2020-09-30 17:32                 ` Dmitry Osipenko
2020-09-30 17:32                   ` Dmitry Osipenko
2020-09-30  8:42 ` [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev Nicolin Chen
2020-09-30  8:42   ` Nicolin Chen
2020-09-30  9:21   ` Krzysztof Kozlowski
2020-09-30  9:21     ` Krzysztof Kozlowski
2020-09-30  9:40     ` Nicolin Chen
2020-09-30  9:40       ` Nicolin Chen
2020-09-30 10:19       ` Krzysztof Kozlowski
2020-09-30 10:19         ` Krzysztof Kozlowski
2020-09-30 14:41   ` Dmitry Osipenko
2020-09-30 14:41     ` Dmitry Osipenko
2020-09-30 15:09   ` Dmitry Osipenko
2020-09-30 15:09     ` Dmitry Osipenko
2020-09-30 20:51     ` Nicolin Chen
2020-09-30 20:51       ` Nicolin Chen
2020-09-30 15:31   ` Thierry Reding
2020-09-30 15:31     ` Thierry Reding
2020-09-30 15:36     ` Dmitry Osipenko
2020-09-30 15:36       ` Dmitry Osipenko
2020-09-30 16:06       ` Thierry Reding
2020-09-30 16:06         ` Thierry Reding
2020-09-30 16:25         ` Dmitry Osipenko
2020-09-30 16:25           ` Dmitry Osipenko
2020-09-30 16:47           ` Thierry Reding
2020-09-30 16:47             ` Thierry Reding
2020-10-01  2:11             ` Dmitry Osipenko
2020-10-01  2:11               ` Dmitry Osipenko
2020-10-01  7:58               ` Thierry Reding
2020-10-01  7:58                 ` Thierry Reding
2020-10-01 19:04                 ` Dmitry Osipenko
2020-10-01 19:04                   ` Dmitry Osipenko
2020-10-05  9:16                   ` Thierry Reding
2020-10-05  9:16                     ` Thierry Reding
2020-10-05  9:38                     ` Dmitry Osipenko
2020-10-05  9:38                       ` Dmitry Osipenko
2020-10-05 10:27                       ` Thierry Reding
2020-10-05 10:27                         ` Thierry Reding
2020-09-30 16:10       ` Thierry Reding
2020-09-30 16:10         ` Thierry Reding
2020-09-30 16:29         ` Dmitry Osipenko
2020-09-30 16:29           ` Dmitry Osipenko
2020-10-01  7:59           ` Thierry Reding
2020-10-01  7:59             ` Thierry Reding
2020-09-30 20:36     ` Nicolin Chen
2020-09-30 20:36       ` Nicolin Chen
2020-09-30 21:24       ` Dmitry Osipenko
2020-09-30 21:24         ` Dmitry Osipenko
2020-09-30 21:32         ` Nicolin Chen
2020-09-30 21:32           ` Nicolin Chen
2020-09-30 21:56           ` Dmitry Osipenko
2020-09-30 21:56             ` Dmitry Osipenko
2020-10-01  1:26             ` Nicolin Chen
2020-10-01  1:26               ` Nicolin Chen
2020-10-01  2:06               ` Dmitry Osipenko
2020-10-01  2:06                 ` Dmitry Osipenko
2020-10-01  2:48                 ` Nicolin Chen
2020-10-01  2:48                   ` Nicolin Chen
2020-10-01  4:04                   ` Dmitry Osipenko
2020-10-01  4:04                     ` Dmitry Osipenko
2020-10-01 10:23                   ` Thierry Reding
2020-10-01 10:23                     ` Thierry Reding
2020-10-01 11:04                     ` Nicolin Chen
2020-10-01 11:04                       ` Nicolin Chen
2020-10-01 20:33                       ` Dmitry Osipenko [this message]
2020-10-01 20:33                         ` Dmitry Osipenko
2020-10-02  1:07                         ` Nicolin Chen
2020-10-02  1:07                           ` Nicolin Chen
2020-10-02  1:55                           ` Dmitry Osipenko
2020-10-02  1:55                             ` Dmitry Osipenko
2020-10-02  2:54                             ` Nicolin Chen
2020-10-02  2:54                               ` Nicolin Chen
2020-10-05  7:24                             ` Thierry Reding
2020-10-05  7:24                               ` Thierry Reding
2020-10-05  7:13                         ` Thierry Reding
2020-10-05  7:13                           ` Thierry Reding
2020-10-05  8:14                           ` Dmitry Osipenko
2020-10-05  8:14                             ` Dmitry Osipenko
2020-10-05  9:31                             ` Thierry Reding
2020-10-05  9:31                               ` Thierry Reding
2020-10-01  9:54                 ` Thierry Reding
2020-10-01  9:54                   ` Thierry Reding
2020-10-01  9:51               ` Thierry Reding
2020-10-01  9:51                 ` Thierry Reding
2020-10-01 10:33                 ` Nicolin Chen
2020-10-01 10:33                   ` Nicolin Chen
2020-10-01 10:42                   ` Thierry Reding
2020-10-01 10:42                     ` Thierry Reding
2020-10-01  9:47       ` Thierry Reding
2020-10-01  9:47         ` Thierry Reding
2020-10-01 10:46       ` Thierry Reding
2020-10-01 10:46         ` Thierry Reding
2020-10-02  1:29         ` Nicolin Chen
2020-10-02  1:29           ` Nicolin Chen
2020-09-30  8:42 ` [PATCH v3 3/3] iommu/tegra-smmu: Add PCI support Nicolin Chen
2020-09-30  8:42   ` Nicolin Chen
2020-09-30 14:53   ` Dmitry Osipenko
2020-09-30 14:53     ` Dmitry Osipenko
2020-09-30 20:03     ` Nicolin Chen
2020-09-30 20:03       ` Nicolin Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b966844e-4289-3ff0-9512-852f8419a664@gmail.com \
    --to=digetx@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicoleotsuka@gmail.com \
    --cc=thierry.reding@gmail.com \
    --cc=vdumpa@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.