From: Jason Gunthorpe <jgg@nvidia.com>
To: Shanker Donthineni <sdonthineni@nvidia.com>
Cc: Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Vladimir Murzin <vladimir.murzin@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Vikram Sethi <vsethi@nvidia.com>,
Jason Sequeira <jsequeira@nvidia.com>
Subject: Re: [PATCH v3] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
Date: Fri, 12 Jun 2026 09:48:25 -0300 [thread overview]
Message-ID: <20260612124825.GF1962447@nvidia.com> (raw)
In-Reply-To: <851c4107-3f6d-46f3-b659-212ce4f69e6e@nvidia.com>
On Thu, Jun 11, 2026 at 08:13:48PM -0500, Shanker Donthineni wrote:
> For the scalar MMIO helpers, the workaround promotes the raw writes to
> store-release on affected CPUs as v1/v2 shown below. For the memcpy-toIO
> helpers, could you please clarify the specific reason for adding a dmb despite
> the documented no-ordering contract? Is the concern that some drivers may
> be relying on ordering across memcpy_toio_*() today even though the API
> does not guarantee it, and that we should cover those cases defensively?
I think given how arm implements them today the iocopy's are actually
the _relaxed variations.. I wonder if this matters to any user?
Jason
prev parent reply other threads:[~2026-06-12 12:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 16:48 [PATCH v3] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum Shanker Donthineni
2026-06-11 13:34 ` Will Deacon
2026-06-11 14:08 ` Shanker Donthineni
2026-06-11 15:08 ` Vladimir Murzin
2026-06-11 16:00 ` Shanker Donthineni
2026-06-11 17:49 ` Jason Gunthorpe
[not found] ` <IA1PR12MB6089049028A73A2078FC6831C71B2@IA1PR12MB6089.namprd12.prod.outlook.com>
2026-06-12 1:13 ` Shanker Donthineni
2026-06-12 12:48 ` Jason Gunthorpe [this message]
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=20260612124825.GF1962447@nvidia.com \
--to=jgg@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=jsequeira@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=sdonthineni@nvidia.com \
--cc=vladimir.murzin@arm.com \
--cc=vsethi@nvidia.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.