From: Nicolin Chen <nicolinc@nvidia.com>
To: Pranjal Shrivastava <praan@google.com>
Cc: <jgg@nvidia.com>, <will@kernel.org>, <joro@8bytes.org>,
<robin.murphy@arm.com>, <linux-arm-kernel@lists.infradead.org>,
<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3: Replace vsmmu_size/type with get_viommu_size
Date: Fri, 25 Jul 2025 09:03:39 -0700 [thread overview]
Message-ID: <aIOq2ysFPfZsNUix@Asurada-Nvidia> (raw)
In-Reply-To: <aIMR6xxR3Jdpy8kX@google.com>
On Fri, Jul 25, 2025 at 05:11:07AM +0000, Pranjal Shrivastava wrote:
> On Thu, Jul 24, 2025 at 02:49:28PM -0700, Nicolin Chen wrote:
> I'm agreeing with all of it, it's just that the comment says something
> was rejected in by the size op, which raises confusion as to why we're
> in the init op. The init op rejecting something due to data corruption
> is a different thing..
>
> I totally get the point about data corruption, i.e.:
>
> size op -> returned something valid
> <data corruption>
> init op -> rejecting corrupted type
>
> Wheras I was just trying to understand a case where as per the comment:
> "Unsupported type was rejected in tegra241_cmdqv_get_vintf_size()",
> i.e. ->size op returned 0, yet we ended up calling the init op
Is the updated one in v4 fine to you?
/*
* Unsupported type should be rejected by tegra241_cmdqv_get_vintf_size.
* Seeing one here indicates a kernel bug or some data corruption.
*/
Nicolin
next prev parent reply other threads:[~2025-07-25 16:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 20:04 [PATCH v3 0/2] iommu/arm-smmu-v3: Two vsmmu impl_ops cleanups Nicolin Chen
2025-07-21 20:04 ` [PATCH v3 1/2] iommu/arm-smmu-v3: Do not bother impl_ops if IOMMU_VIOMMU_TYPE_ARM_SMMUV3 Nicolin Chen
2025-07-23 13:19 ` Pranjal Shrivastava
2025-07-21 20:04 ` [PATCH v3 2/2] iommu/arm-smmu-v3: Replace vsmmu_size/type with get_viommu_size Nicolin Chen
2025-07-23 13:37 ` Pranjal Shrivastava
2025-07-23 18:05 ` Nicolin Chen
2025-07-23 18:58 ` Pranjal Shrivastava
2025-07-24 20:55 ` Pranjal Shrivastava
2025-07-24 21:49 ` Nicolin Chen
2025-07-25 5:11 ` Pranjal Shrivastava
2025-07-25 16:03 ` Nicolin Chen [this message]
2025-07-25 17:47 ` Pranjal Shrivastava
2025-07-25 9:18 ` Mostafa Saleh
2025-07-25 16:24 ` Nicolin Chen
2025-07-25 18:12 ` Mostafa Saleh
2025-07-25 19:01 ` 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=aIOq2ysFPfZsNUix@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).