mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Yeoreum Yun" <yeoreum.yun@arm.com>,
	"Sudeep Holla" <sudeep.holla@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, nd@arm.com
Subject: Re: [PATCH v2 2/2] firmware/arm_ffa: remove __le64_to_cpu() when set uuid for direct msg v2
Date: Mon, 09 Dec 2024 16:27:14 +0100	[thread overview]
Message-ID: <9e60e996-070e-43a7-80e9-efdfda9f6223@app.fastmail.com> (raw)
In-Reply-To: <20241203143109.1030514-3-yeoreum.yun@arm.com>

On Tue, Dec 3, 2024, at 15:31, Yeoreum Yun wrote:
> From: Levi Yun <yeoreum.yun@arm.com>

I just saw this commit in the pull request, and I'm very
confused because the description does not match the
patch contents.

> Accoding to FF-A specification[0] 15.4 FFA_MSG_SEND_DRIECT_REQ2,
> then UUID is saved in register:
>     UUID Lo  x2  Bytes[0...7] of UUID with byte 0 in the low-order bits.
>     UUID Hi  x3  Bytes[8...15] of UUID with byte 8 in the low-order bits.

The specification you cite here clearly describes little-endian
format, i.e. the low-order byte corresponds to the first
memory address.

> That means, we don't need to swap the uuid when it send via direct
> message request version 2, just send it as saved in memory.

"As saved in memory" does not sound like a useful description
when passing arguments through registers, as the register
contents are not defined in terms of byte offsets.

Can you describe what bug you found? If the byteorder on
big-endian kernels is wrong in the current version and your
patch fixes it, it sounds like the specification needs to
be updated describe both big-endian and little-endian
byte-order, and how the firmware detects which one is used.

> Remove le64_to_cpu() for uuid in direct message request version 2,
> and change uuid_regs' type to unsigned long.

'unsigned long' makes the code unnecessarily incompatible
with 32-bit builds.

     Arnd

  reply	other threads:[~2024-12-09 15:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-03 14:31 [PATCH v2 0/2] small fixes for arm_ffa driver Yeoreum Yun
2024-12-03 14:31 ` [PATCH v2 1/2] firmware/arm_ffa: change ffa_device_register()'s parameters and return Yeoreum Yun
2024-12-03 14:31 ` [PATCH v2 2/2] firmware/arm_ffa: remove __le64_to_cpu() when set uuid for direct msg v2 Yeoreum Yun
2024-12-09 15:27   ` Arnd Bergmann [this message]
2024-12-09 16:59     ` Sudeep Holla
2024-12-09 20:04       ` Arnd Bergmann
2024-12-10  7:36         ` Yeoreum Yun
2024-12-10  8:45           ` Arnd Bergmann
2024-12-10 10:08             ` Sudeep Holla
2024-12-10  9:49         ` Sudeep Holla
2024-12-05 10:35 ` [PATCH v2 0/2] small fixes for arm_ffa driver Sudeep Holla

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=9e60e996-070e-43a7-80e9-efdfda9f6223@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nd@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=yeoreum.yun@arm.com \
    /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

all inboxes | Powered by JetHome®