On Mon, Apr 20, 2015 at 12:20:52PM -0600, Jason Gunthorpe wrote:
> On Mon, Apr 20, 2015 at 08:20:44AM +0200, Jens Wiklander wrote:
>
> > I'm not sure I understand what you mean. This function is a building
> > block for the TEE driver to supply whatever interface is needed for user
> > space. For
On Mon, Apr 20, 2015 at 11:55:15AM -0600, Jason Gunthorpe wrote:
> On Mon, Apr 20, 2015 at 03:02:03PM +0200, Jens Wiklander wrote:
> > > It appeared to me this driver was copying TPM's old architecture,
> > > which is very much known to be broken.
> >
> > The struct tee_device holds a shared
On Mon, Apr 20, 2015 at 11:55:15AM -0600, Jason Gunthorpe wrote:
On Mon, Apr 20, 2015 at 03:02:03PM +0200, Jens Wiklander wrote:
It appeared to me this driver was copying TPM's old architecture,
which is very much known to be broken.
The struct tee_device holds a shared memory pool
On Mon, Apr 20, 2015 at 12:20:52PM -0600, Jason Gunthorpe wrote:
On Mon, Apr 20, 2015 at 08:20:44AM +0200, Jens Wiklander wrote:
I'm not sure I understand what you mean. This function is a building
block for the TEE driver to supply whatever interface is needed for user
space. For a
On Mon, Apr 20, 2015 at 08:20:44AM +0200, Jens Wiklander wrote:
> I'm not sure I understand what you mean. This function is a building
> block for the TEE driver to supply whatever interface is needed for user
> space. For a Global Platform like TEE it will typically have support for
>
On Mon, Apr 20, 2015 at 03:02:03PM +0200, Jens Wiklander wrote:
> > It appeared to me this driver was copying TPM's old architecture,
> > which is very much known to be broken.
>
> The struct tee_device holds a shared memory pool from which shared
> memory objects are allocated. These shared
On Mon, Apr 20, 2015 at 09:56:48AM -0600, Jason Gunthorpe wrote:
> On Mon, Apr 20, 2015 at 04:54:32PM +0200, Greg Kroah-Hartman wrote:
> > On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
> > > I still suspect the expected way to write a new mid layer is to create
> > > your own
On Mon, Apr 20, 2015 at 04:54:32PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
> > I still suspect the expected way to write a new mid layer is to create
> > your own struct device and not rely on misc_device,
>
> Yes, that is the way. You
On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
> I still suspect the expected way to write a new mid layer is to create
> your own struct device and not rely on misc_device,
Yes, that is the way. You can not use misc_device for anything other
than creating the char node that
On Sat, Apr 18, 2015 at 11:29:23AM -0600, Jason Gunthorpe wrote:
> On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
> > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > > +
Hi Arnd,
On Fri, Apr 17, 2015 at 10:07:02PM +0200, Arnd Bergmann wrote:
> On Friday 17 April 2015 09:50:56 Jens Wiklander wrote:
> > Documentation/ioctl/ioctl-number.txt | 1 +
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 1 +
> >
On Sat, Apr 18, 2015 at 11:29:23AM -0600, Jason Gunthorpe wrote:
On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev =
On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
I still suspect the expected way to write a new mid layer is to create
your own struct device and not rely on misc_device,
Yes, that is the way. You can not use misc_device for anything other
than creating the char node that your
On Mon, Apr 20, 2015 at 03:02:03PM +0200, Jens Wiklander wrote:
It appeared to me this driver was copying TPM's old architecture,
which is very much known to be broken.
The struct tee_device holds a shared memory pool from which shared
memory objects are allocated. These shared memory
On Mon, Apr 20, 2015 at 08:20:44AM +0200, Jens Wiklander wrote:
I'm not sure I understand what you mean. This function is a building
block for the TEE driver to supply whatever interface is needed for user
space. For a Global Platform like TEE it will typically have support for
On Mon, Apr 20, 2015 at 04:54:32PM +0200, Greg Kroah-Hartman wrote:
On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
I still suspect the expected way to write a new mid layer is to create
your own struct device and not rely on misc_device,
Yes, that is the way. You can not
On Mon, Apr 20, 2015 at 09:56:48AM -0600, Jason Gunthorpe wrote:
On Mon, Apr 20, 2015 at 04:54:32PM +0200, Greg Kroah-Hartman wrote:
On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
I still suspect the expected way to write a new mid layer is to create
your own struct
Hi Arnd,
On Fri, Apr 17, 2015 at 10:07:02PM +0200, Arnd Bergmann wrote:
On Friday 17 April 2015 09:50:56 Jens Wiklander wrote:
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/tee/Kconfig
On Sat, Apr 18, 2015 at 10:57:55PM +0100, Russell King - ARM Linux wrote:
> > But then we trundle down to:
> >
> > + ctx->teedev->desc->ops->get_version(ctx, _version,
> > + vers.uuid);
> >
> > If we kref teedev so it is valid then calling a driver call back after
> > (or during) it's remove
On Sat, Apr 18, 2015 at 09:50:19PM +0100, Russell King - ARM Linux wrote:
> On Sat, Apr 18, 2015 at 10:37:16PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
> > > On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
>
On Sat, Apr 18, 2015 at 09:50:19PM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 10:37:16PM +0200, Greg Kroah-Hartman wrote:
On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
On
On Sat, Apr 18, 2015 at 10:57:55PM +0100, Russell King - ARM Linux wrote:
But then we trundle down to:
+ ctx-teedev-desc-ops-get_version(ctx, vers.spec_version,
+ vers.uuid);
If we kref teedev so it is valid then calling a driver call back after
(or during) it's remove function
On Sat, Apr 18, 2015 at 11:29:23AM -0600, Jason Gunthorpe wrote:
> On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
> > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > > +
On Sat, Apr 18, 2015 at 10:37:16PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
>
On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
> On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
> > > On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
>
On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > >
On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
> On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > +struct tee_device {
> > > + char name[TEE_MAX_DEV_NAME_LEN];
> > > + const
On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
> > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > + teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
> > [..]
> > > + rc =
On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > +struct tee_device {
> > + char name[TEE_MAX_DEV_NAME_LEN];
> > + const struct tee_desc *desc;
> > + struct device *dev;
>
> No, please embed the device
On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
> On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > + teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
> [..]
> > + rc = misc_register(>miscdev);
> [..]
> > +void tee_unregister(struct tee_device
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> +struct tee_device {
> + char name[TEE_MAX_DEV_NAME_LEN];
> + const struct tee_desc *desc;
> + struct device *dev;
No, please embed the device in your structure, don't have a pointer to
it.
> + struct miscdevice
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> +/**
> + * struct tee_cmd_data - Opaque command argument
> + * @buf_ptr: [in] A __user pointer to a command buffer
> + * @buf_len: [in] Length of the buffer above
> + *
> + * Opaque command data which is passed on to the specific
On Fri, 2015-04-17 at 22:07 +0200, Arnd Bergmann wrote:
> On Friday 17 April 2015 09:50:56 Jens Wiklander wrote:
> > +static const struct file_operations tee_fops = {
> > + .owner = THIS_MODULE,
> > + .open = tee_open,
> > + .release = tee_release,
> > + .unlocked_ioctl = tee_ioctl
> > +};
On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
+ rc =
On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+struct tee_device {
+ char name[TEE_MAX_DEV_NAME_LEN];
+ const struct tee_desc
On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+struct
On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
On
On Sat, Apr 18, 2015 at 10:37:16PM +0200, Greg Kroah-Hartman wrote:
On Sat, Apr 18, 2015 at 08:02:24PM +0100, Russell King - ARM Linux wrote:
On Sat, Apr 18, 2015 at 08:47:13PM +0200, Greg Kroah-Hartman wrote:
On Sat, Apr 18, 2015 at 10:04:20AM +0100, Russell King - ARM Linux wrote:
On
On Sat, Apr 18, 2015 at 11:29:23AM -0600, Jason Gunthorpe wrote:
On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev =
On Fri, 2015-04-17 at 22:07 +0200, Arnd Bergmann wrote:
On Friday 17 April 2015 09:50:56 Jens Wiklander wrote:
+static const struct file_operations tee_fops = {
+ .owner = THIS_MODULE,
+ .open = tee_open,
+ .release = tee_release,
+ .unlocked_ioctl = tee_ioctl
+};
Add a
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+/**
+ * struct tee_cmd_data - Opaque command argument
+ * @buf_ptr: [in] A __user pointer to a command buffer
+ * @buf_len: [in] Length of the buffer above
+ *
+ * Opaque command data which is passed on to the specific driver.
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+struct tee_device {
+ char name[TEE_MAX_DEV_NAME_LEN];
+ const struct tee_desc *desc;
+ struct device *dev;
No, please embed the device in your structure, don't have a pointer to
it.
+ struct miscdevice
On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
+ rc = misc_register(teedev-miscdev);
[..]
+void tee_unregister(struct tee_device *teedev)
On Sat, Apr 18, 2015 at 10:57:12AM +0200, Greg Kroah-Hartman wrote:
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+struct tee_device {
+ char name[TEE_MAX_DEV_NAME_LEN];
+ const struct tee_desc *desc;
+ struct device *dev;
No, please embed the device in your
On Friday 17 April 2015 09:50:56 Jens Wiklander wrote:
> Documentation/ioctl/ioctl-number.txt | 1 +
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/tee/Kconfig | 8 +
> drivers/tee/Makefile | 3 +
>
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> + teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
> + rc = misc_register(>miscdev);
[..]
> +void tee_unregister(struct tee_device *teedev)
> +{
[..]
> + misc_deregister(>miscdev);
> +}
[..]
>+static int
Initial patch for generic TEE subsystem.
This subsystem provides:
* Registration/un-registration of TEE drivers.
* Shared memory between normal world and secure world.
* Ioctl interface for interaction with user space.
A TEE (Trusted Execution Environment) driver is a driver that interfaces
with
Initial patch for generic TEE subsystem.
This subsystem provides:
* Registration/un-registration of TEE drivers.
* Shared memory between normal world and secure world.
* Ioctl interface for interaction with user space.
A TEE (Trusted Execution Environment) driver is a driver that interfaces
with
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
+ teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
+ rc = misc_register(teedev-miscdev);
[..]
+void tee_unregister(struct tee_device *teedev)
+{
[..]
+ misc_deregister(teedev-miscdev);
+}
[..]
+static
On Friday 17 April 2015 09:50:56 Jens Wiklander wrote:
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/tee/Kconfig | 8 +
drivers/tee/Makefile | 3 +
50 matches
Mail list logo
