[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3aa8705a-0342-25ea-00c4-d5370d91ddb4@forissier.org>
Date: Wed, 24 Jun 2020 17:44:45 +0200
From: Jerome Forissier <jerome@...issier.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>,
Sumit Garg <sumit.garg@...aro.org>
Cc: Maxim Uvarov <maxim.uvarov@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Arnd Bergmann <arnd@...aro.org>,
"tee-dev @ lists . linaro . org" <tee-dev@...ts.linaro.org>,
Jason Gunthorpe <jgg@...pe.ca>,
linux-integrity@...r.kernel.org, peterhuewe@....de
Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
On 6/24/20 5:21 PM, James Bottomley wrote:
> On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote:
>> Apologies for delay in my reply as I was busy with some other stuff.
>>
>> On Fri, 19 Jun 2020 at 20:30, James Bottomley
>> <James.Bottomley@...senpartnership.com> wrote:
> [...]
>>> it's about consistency with what the kernel types mean. When some
>>> checker detects your using little endian operations on a big endian
>>> structure (like in the prink for instance) they're going to keep
>>> emailing you about it.
>>
>> As mentioned above, using different terminology is meant to cause
>> more confusion than just difference in endianness which is manageable
>> inside TEE.
>>
>> And I think it's safe to say that the kernel implements UUID in big
>> endian format and thus uses %pUb whereas OP-TEE implements UUID in
>> little endian format and thus uses %pUl.
>
> So what I think you're saying is that if we still had uuid_be and
> uuid_le you'd use uuid_le, because that's exactly the structure
> described in the docs. But because we renamed
>
> uuid_be -> uuid_t
> uuid_le -> guid_t
>
> You can't use guid_t as a kernel type because it has the wrong name?
Let me try to clear the confusion that I introduce myself I believe :-/
IMO:
- optee_register_device(const uuid_t *device_uuid) *is* the correct
prototype.
- device_uuid is *guaranteed* to be BE because OP-TEE makes this
guarantee (it converts from its internal LE representation to BE when
enumerating the devices, but it doesn't matter to the kernel).
- Therefore %pUb is the correct format.
I'm sorry for doubting the BE order initially. I am so used to OP-TEE
using LE internally, that I missed the fact that we have an explicit
conversion...
Does this sound good?
Thanks,
--
Jerome
Powered by blists - more mailing lists