linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@linaro.org>
To: Maxim Uvarov <maxim.uvarov@linaro.org>
Cc: Jerome Forissier <jerome@forissier.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Arnd Bergmann <arnd@linaro.org>,
	"tee-dev @ lists . linaro . org" <tee-dev@lists.linaro.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	linux-integrity@vger.kernel.org, peterhuewe@gmx.de
Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
Date: Fri, 26 Jun 2020 10:56:50 +0530	[thread overview]
Message-ID: <CAFA6WYPUzSNYjrktSPdzLDsKeO8Tipi6CuSjjN-MgdsvU2KzOA@mail.gmail.com> (raw)
In-Reply-To: <CAD8XO3ZDv-RZ-VPv-AFMRkMD_3uW9XYLeZQf0btGVK8m7GX2Dg@mail.gmail.com>

On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov <maxim.uvarov@linaro.org> wrote:
>
> On Wed, 24 Jun 2020 at 18:44, Jerome Forissier <jerome@forissier.org> wrote:
> >
> >
> >
> > 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@hansenpartnership.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
>
> I think your description is correct. But I think this problem  would
> be solved outside of the current patchset.
> All places should use one single format (LE):
> -  internal optee representation;
> -  device enumeration pta;
> -  this kernel driver which creates sysfs entry and sets
> uid_copy(&optee_device->id.uuid, device_uuid);
> -  matching function;
> -  drivers use UUID_INIT();
>
> In that way everything will be consistent. But it will require
> changing other pieces, not just the kernel. While
> these patches add functionality to support current device enumeration
> in optee os.
> So I think this version is ok to be applied.

I guess here you meant v9 patch-set. If yes then it's fine with me as well.

-Sumit

>
> Regards,
> Maxim.

  parent reply	other threads:[~2020-06-26  5:27 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04 17:58 [PATCHv8 0/3] optee: register drivers on optee bus Maxim Uvarov
2020-06-04 17:58 ` [PATCHv8 1/3] optee: use uuid for sysfs driver entry Maxim Uvarov
2020-06-16 20:50   ` Jarkko Sakkinen
2020-06-17  6:07     ` Sumit Garg
2020-06-17  6:45       ` Maxim Uvarov
2020-06-17 13:58   ` Sumit Garg
2020-06-17 14:12     ` Maxim Uvarov
2020-06-17 15:16     ` [Tee-dev] " Jerome Forissier
2020-06-17 19:52       ` Maxim Uvarov
2020-06-17 20:45         ` Jerome Forissier
2020-06-18  4:59       ` Sumit Garg
2020-06-18  5:12         ` Sumit Garg
2020-06-18 19:18           ` James Bottomley
2020-06-19  8:12             ` Sumit Garg
2020-06-19 15:00               ` James Bottomley
2020-06-24  9:50                 ` Jens Wiklander
2020-06-24 10:47                 ` Sumit Garg
2020-06-24 15:21                   ` James Bottomley
2020-06-24 15:44                     ` Jerome Forissier
2020-06-25 12:51                       ` Maxim Uvarov
2020-06-26  5:13                         ` Sumit Garg
2020-06-26  8:47                           ` Andy Shevchenko
2020-06-26  5:26                         ` Sumit Garg [this message]
2020-06-25 14:24                     ` Sumit Garg
2020-06-25 23:31                       ` James Bottomley
2020-06-26  5:10                         ` Sumit Garg
2020-06-26  7:26                           ` Sumit Garg
2020-06-26 11:29                           ` Daniel Thompson
2020-06-26 15:11                             ` James Bottomley
2020-06-29  6:55                               ` Sumit Garg
2020-06-29  7:03                               ` Jens Wiklander
2020-06-18  6:57         ` Jerome Forissier
2020-06-18  7:44           ` Maxim Uvarov
2020-06-04 17:58 ` [PATCHv8 2/3] optee: enable support for multi-stage bus enumeration Maxim Uvarov
2020-06-16 20:56   ` Jarkko Sakkinen
2020-06-04 17:58 ` [PATCHv8 3/3] tpm_ftpm_tee: register driver on TEE bus Maxim Uvarov
2020-06-16 20:57   ` Jarkko Sakkinen
2020-06-15 14:32 ` [PATCHv8 0/3] optee: register drivers on optee bus Maxim Uvarov
2020-06-16  8:29   ` Jens Wiklander
2020-06-17 14:26     ` Maxim Uvarov
2020-06-18  8:00       ` Jens Wiklander
2020-06-17 23:37     ` Jarkko Sakkinen
2020-06-18  7:56       ` Jens Wiklander
2020-06-23  0:50         ` Jarkko Sakkinen
2020-06-16 20:49   ` Jarkko Sakkinen
2020-06-16 20:54     ` Jarkko Sakkinen

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=CAFA6WYPUzSNYjrktSPdzLDsKeO8Tipi6CuSjjN-MgdsvU2KzOA@mail.gmail.com \
    --to=sumit.garg@linaro.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=arnd@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jerome@forissier.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxim.uvarov@linaro.org \
    --cc=peterhuewe@gmx.de \
    --cc=tee-dev@lists.linaro.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;
as well as URLs for NNTP newsgroup(s).