All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>, <joro@8bytes.org>,
	<will@kernel.org>, <dwmw2@infradead.org>,
	<baolu.lu@linux.intel.com>
Cc: <linux-kernel@vger.kernel.org>,
	<iommu@lists.linux-foundation.org>, <linuxarm@huawei.com>,
	<thunder.leizhen@huawei.com>, <chenxiang66@hisilicon.com>
Subject: Re: [PATCH v12 5/5] iommu: Remove mode argument from iommu_set_dma_strict()
Date: Mon, 14 Jun 2021 18:24:39 +0100	[thread overview]
Message-ID: <0e477a85-db02-1513-a449-02a9fbfccdfa@huawei.com> (raw)
In-Reply-To: <56f1fc88-baec-e1cf-109e-59978e2d16a8@arm.com>

On 14/06/2021 18:19, Robin Murphy wrote:
>>> We shouldn't need to keep IOMMU_CMD_LINE_STRICT at all now, since it 
>>> was only to prevent a driver's "default lazy" setting passed in here 
>>> from downgrading an explicitly-set strict mode.
>>>
>>> With that cleaned up too,
>>>
>>
>> Patch 1/5 mentions whether the invalidation policy comes from the 
>> cmdline - similar to the default domain type print - so I was going to 
>> keep that.
> 
> Oh, silly me, I'd forgotten that already and was just looking at my 
> local tree... Let's keep it for consistency with how we report the 
> domain type then.
> 
>> And then maybe we should also set it from the deprecated x86 
>> driver-specific params.
> 
> I don't think it's worth exporting more low-level guts to allow that to 
> happen - tying in to iommu_set_dma_strict() would be too late, as 
> before. I think the separate pr_warn()s which announce the relevant 
> parameter is deprecated (but has still taken effect) should be enough.
> 

Fine, I suppose someone using a deprecated interface can't complain 
about imperfect prints.

And I'll pick up your RB tag (unless you mention otherwise).

Thanks,
John



WARNING: multiple messages have this Message-ID (diff)
From: John Garry <john.garry@huawei.com>
To: Robin Murphy <robin.murphy@arm.com>, <joro@8bytes.org>,
	<will@kernel.org>,  <dwmw2@infradead.org>,
	<baolu.lu@linux.intel.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	linuxarm@huawei.com
Subject: Re: [PATCH v12 5/5] iommu: Remove mode argument from iommu_set_dma_strict()
Date: Mon, 14 Jun 2021 18:24:39 +0100	[thread overview]
Message-ID: <0e477a85-db02-1513-a449-02a9fbfccdfa@huawei.com> (raw)
In-Reply-To: <56f1fc88-baec-e1cf-109e-59978e2d16a8@arm.com>

On 14/06/2021 18:19, Robin Murphy wrote:
>>> We shouldn't need to keep IOMMU_CMD_LINE_STRICT at all now, since it 
>>> was only to prevent a driver's "default lazy" setting passed in here 
>>> from downgrading an explicitly-set strict mode.
>>>
>>> With that cleaned up too,
>>>
>>
>> Patch 1/5 mentions whether the invalidation policy comes from the 
>> cmdline - similar to the default domain type print - so I was going to 
>> keep that.
> 
> Oh, silly me, I'd forgotten that already and was just looking at my 
> local tree... Let's keep it for consistency with how we report the 
> domain type then.
> 
>> And then maybe we should also set it from the deprecated x86 
>> driver-specific params.
> 
> I don't think it's worth exporting more low-level guts to allow that to 
> happen - tying in to iommu_set_dma_strict() would be too late, as 
> before. I think the separate pr_warn()s which announce the relevant 
> parameter is deprecated (but has still taken effect) should be enough.
> 

Fine, I suppose someone using a deprecated interface can't complain 
about imperfect prints.

And I'll pick up your RB tag (unless you mention otherwise).

Thanks,
John


_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-06-14 17:30 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 12:20 [PATCH v12 0/5] Enhance IOMMU default DMA mode build options John Garry
2021-06-11 12:20 ` John Garry
2021-06-11 12:20 ` [PATCH v12 1/5] iommu: Print strict or lazy mode at init time John Garry
2021-06-11 12:20   ` John Garry
2021-06-14 15:54   ` Robin Murphy
2021-06-14 15:54     ` Robin Murphy
2021-06-11 12:20 ` [PATCH v12 2/5] iommu: Enhance IOMMU default DMA mode build options John Garry
2021-06-11 12:20   ` John Garry
2021-06-12  1:21   ` Lu Baolu
2021-06-12  1:21     ` Lu Baolu
2021-06-14  8:11     ` John Garry
2021-06-14  8:11       ` John Garry
2021-06-12  2:12   ` Lu Baolu
2021-06-12  2:12     ` Lu Baolu
2021-06-14 16:03   ` Robin Murphy
2021-06-14 16:03     ` Robin Murphy
2021-06-11 12:20 ` [PATCH v12 3/5] iommu/vt-d: Add support for " John Garry
2021-06-11 12:20   ` John Garry
2021-06-12  2:14   ` Lu Baolu
2021-06-12  2:14     ` Lu Baolu
2021-06-14  8:03     ` John Garry
2021-06-14  8:03       ` John Garry
2021-06-15  7:26       ` Lu Baolu
2021-06-15  7:26         ` Lu Baolu
2021-06-15  8:25         ` Robin Murphy
2021-06-15  8:25           ` Robin Murphy
2021-06-16  8:42           ` Lu Baolu
2021-06-16  8:42             ` Lu Baolu
2021-06-12  2:22   ` Lu Baolu
2021-06-12  2:22     ` Lu Baolu
2021-06-14  7:53     ` John Garry
2021-06-14  7:53       ` John Garry
2021-06-14 14:11       ` Robin Murphy
2021-06-14 14:11         ` Robin Murphy
2021-06-14 14:19         ` John Garry
2021-06-14 14:19           ` John Garry
2021-06-14 15:05           ` Robin Murphy
2021-06-14 15:05             ` Robin Murphy
2021-06-11 12:20 ` [PATCH v12 4/5] iommu/amd: " John Garry
2021-06-11 12:20   ` John Garry
2021-06-11 12:20 ` [PATCH v12 5/5] iommu: Remove mode argument from iommu_set_dma_strict() John Garry
2021-06-11 12:20   ` John Garry
2021-06-12  2:23   ` Lu Baolu
2021-06-12  2:23     ` Lu Baolu
2021-06-14  7:46     ` John Garry
2021-06-14  7:46       ` John Garry
2021-06-14 16:25   ` Robin Murphy
2021-06-14 16:25     ` Robin Murphy
2021-06-14 17:03     ` John Garry
2021-06-14 17:03       ` John Garry
2021-06-14 17:19       ` Robin Murphy
2021-06-14 17:19         ` Robin Murphy
2021-06-14 17:24         ` John Garry [this message]
2021-06-14 17:24           ` John Garry

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=0e477a85-db02-1513-a449-02a9fbfccdfa@huawei.com \
    --to=john.garry@huawei.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=robin.murphy@arm.com \
    --cc=thunder.leizhen@huawei.com \
    --cc=will@kernel.org \
    /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.