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:15 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 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.