[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <79a1f935-12c1-4e12-92c8-2214bf6b7a73@linux.intel.com>
Date: Sat, 18 Nov 2023 10:26:58 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: baolu.lu@...ux.intel.com, "Tian, Kevin" <kevin.tian@...el.com>,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] iommu/vt-d: Introduce dev_to_iommu()
On 11/17/23 9:07 PM, Jason Gunthorpe wrote:
> On Thu, Nov 16, 2023 at 11:23:56AM +0800, Baolu Lu wrote:
>> On 11/16/23 11:19 AM, Tian, Kevin wrote:
>>>> From: Lu Baolu<baolu.lu@...ux.intel.com>
>>>> Sent: Thursday, November 16, 2023 9:51 AM
>>>>
>>>> +static inline struct intel_iommu *dev_to_iommu(struct device *dev)
>>>> +{
>>>> + /*
>>>> + * Assume that valid per-device iommu structure must be installed
>>>> + * if iommu_probe_device() has succeeded. This helper could only
>>>> + * be used after device is probed.
>>>> + */
>>>> + return ((struct device_domain_info *)dev_iommu_priv_get(dev))-
>>>>> iommu;
>>>> +}
>>> Not sure whether this helper is useful. This is only used by 2 out of 5
>>> post-probe users. Probably just open-coding in all 5 places is clearer.
>> I thought it should get more users in the future development.
> The pattern in the SMMUv2 driver is like
>
> struct device_domain_info *info = dev_iommu_priv_get(dev);
> struct intel_iommu *iommu = info->iommu;
>
> Which really isn't worth the helper, unless you have lots of caes
> where info isn't needed at all?
No. As Kevin pointed out, there are only 2 places.
I will drop this helper.
Best regards,
baolu
Powered by blists - more mailing lists