On Wed, Jan 13, 2021 at 10:44 AM Sudeep Holla [off-list ref] wrote:
[...]

quoted

quoted

quoted

+static int ffa_partition_probe(const char *uuid_str,
+                              struct ffa_partition_info *buffer)
+{
+       int count;
+       uuid_t uuid;
+       u32 uuid0_4[4] = { 0 };
+
+       if (uuid_parse(uuid_str, &uuid)) {
+               pr_err("invalid uuid (%s)\n", uuid_str);
+               return -ENODEV;
+       }
+
+       export_uuid((u8 *)uuid0_4, &uuid);
+       count = __ffa_partition_info_get(uuid0_4[0], uuid0_4[1], uuid0_4[2],
+                                        uuid0_4[3], &buffer);

Wrong byte order?
According to section 5.3 of the SMCCC, UUIDs are returned as a single
128-bit value using the SMC32 calling convention. This value is mapped
to argument registers x0-x3 on AArch64 (resp. r0-r3 on AArch32). x0
for example shall hold bytes 0 to 3, with byte 0 in the low-order
bits.

I need to spend some time to understand the concern here. Initially I agreed
with your analysis and then a quick review make be realise it is all OK.
I need to check if my understanding is correct again. I thought I will
take example and check here itself.

UUID: "fd02c9da-306c-48c7-a49c-bbd827ae86ee"

UUID[0]   UUID[1]  UUID[2]  UUID[3] (referring uuid0_4 above)
dac902fd c7486c30 d8bb9ca4 ee86ae27

It seems correct as per SMCCC convention to me, or am I missing something
obvious ?

In this example I'd expect the first register to hold 0xfd02c9da
regardless of the byte order of the machine. If there is a different
byte order in the receiver it will still be received as 0xfd02c9da.
That's how I've understood the specification.

Cheers,
Jens

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel