From: Jonathan Corbet <corbet@lwn.net>
To: Andrew Davis <afd@ti.com>, Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Davis <afd@ti.com>
Subject: Re: [PATCH v2] docs: driver-api: device-io: Split out relaxed access mention
Date: Mon, 09 Mar 2026 10:21:29 -0600 [thread overview]
Message-ID: <87a4whvura.fsf@trenco.lwn.net> (raw)
In-Reply-To: <20260303183628.80776-1-afd@ti.com>
Andrew Davis <afd@ti.com> writes:
> We list all the normal non-relaxed device io functions first, but also
> list just the "read" versions of the relaxed device io functions.
> Instead of adding the "write" versions to that list, fix a statement
> below which should describe the relaxed versions so it is understood
> that both read and write have relaxed versions.
>
> Signed-off-by: Andrew Davis <afd@ti.com>
> ---
>
> Changes for v2:
> - None, rebase on v7.0-rc2 and resend
>
> Documentation/driver-api/device-io.rst | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst
> index d1aaa961cac4d..5b94973f44762 100644
> --- a/Documentation/driver-api/device-io.rst
> +++ b/Documentation/driver-api/device-io.rst
> @@ -56,7 +56,6 @@ Both read and write accesses are supported; there is no prefetch support
> at this time.
>
> The functions are named readb(), readw(), readl(), readq(),
> -readb_relaxed(), readw_relaxed(), readl_relaxed(), readq_relaxed(),
> writeb(), writew(), writel() and writeq().
>
> Some devices (such as framebuffers) would like to use larger transfers than
> @@ -67,7 +66,7 @@ guaranteed to copy data in order.
>
> The read and write functions are defined to be ordered. That is the
> compiler is not permitted to reorder the I/O sequence. When the ordering
> -can be compiler optimised, you can use __readb() and friends to
> +can be compiler optimised, you can use readb_relaxed() and friends to
> indicate the relaxed ordering. Use this with care.
...and we really think it's better to not just list the functions that
are available?
Among other things, the list would then automatically link to the
documentation for each function ... assuming, of course, that we ever
got around to documenting them...
Thanks,
jon
next prev parent reply other threads:[~2026-03-09 16:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 18:36 [PATCH v2] docs: driver-api: device-io: Split out relaxed access mention Andrew Davis
2026-03-09 16:21 ` Jonathan Corbet [this message]
2026-03-09 18:26 ` Andrew Davis
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=87a4whvura.fsf@trenco.lwn.net \
--to=corbet@lwn.net \
--cc=afd@ti.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.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