Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Bhupesh Sharma <bhsharma@redhat.com>
To: Sumit Garg <sumit.garg@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	 linux-crypto@vger.kernel.org
Cc: mark.rutland@arm.com, daniel.thompson@linaro.org,
	herbert@gondor.apana.org.au, arnd@arndb.de,
	ard.biesheuvel@linaro.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, tee-dev@lists.linaro.org,
	robh+dt@kernel.org, mpm@selenic.com, jens.wiklander@linaro.org
Subject: Re: [PATCH v3 1/4] tee: add bus driver framework for TEE based devices
Date: Fri, 11 Jan 2019 20:39:13 +0530
Message-ID: <6a01fee4-4331-be63-9a78-c4d646b43d29@redhat.com> (raw)
In-Reply-To: <1547207251-9372-2-git-send-email-sumit.garg@linaro.org>

Hi Sumit,

Thanks for the patch. Some nitpicks in-line:

On 01/11/2019 05:17 PM, Sumit Garg wrote:
> Introduce a generic TEE bus driver concept for TEE based kernel drivers
> which would like to communicate with TEE based devices/services.
> 
> In this TEE bus concept, devices/services are identified via Universally
> Unique Identifier (UUID) and drivers register a table of device UUIDs
> which they can support.
> 
> So this TEE bus framework registers a match() callback function which
> iterates over the driver UUID table to find a corresponding match for
> device UUID. If a match is found, then this particular device is probed
> via corresponding probe api registered by the driver. This process
> happens whenever a device or a driver is registered with TEE bus.
> 
> Also this framework allows for device enumeration to be specific to
> corresponding TEE implementation like OP-TEE etc.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>   drivers/tee/tee_core.c  | 43 ++++++++++++++++++++++++++++++++++++++++---
>   include/linux/tee_drv.h | 36 ++++++++++++++++++++++++++++++++++++
>   2 files changed, 76 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> index 7b2bb4c..a685940 100644
> --- a/drivers/tee/tee_core.c
> +++ b/drivers/tee/tee_core.c
> @@ -15,7 +15,6 @@
>   #define pr_fmt(fmt) "%s: " fmt, __func__
>   
>   #include <linux/cdev.h>
> -#include <linux/device.h>
>   #include <linux/fs.h>
>   #include <linux/idr.h>
>   #include <linux/module.h>
> @@ -1027,6 +1026,30 @@ int tee_client_invoke_func(struct tee_context *ctx,
>   }
>   EXPORT_SYMBOL_GPL(tee_client_invoke_func);
>   
> +static int tee_client_device_match(struct device *dev,
> +				   struct device_driver *drv)
> +{
> +	struct tee_client_device *tee_device;
> +	const struct tee_client_device_id *id_table;
> +
> +	tee_device = to_tee_client_device(dev);
> +	id_table = to_tee_client_driver(drv)->id_table;
> +
> +	while (!uuid_is_null(&id_table->uuid)) {
> +		if (uuid_equal(&tee_device->id.uuid, &id_table->uuid))
> +			return 1;
> +		id_table++;
> +	}
> +
> +	return 0;
> +}
> +
> +struct bus_type tee_bus_type = {
> +	.name		= "tee",
> +	.match		= tee_client_device_match,
> +};
> +EXPORT_SYMBOL_GPL(tee_bus_type);
> +
>   static int __init tee_init(void)
>   {
>   	int rc;
> @@ -1040,10 +1063,23 @@ static int __init tee_init(void)
>   	rc = alloc_chrdev_region(&tee_devt, 0, TEE_NUM_DEVICES, "tee");
>   	if (rc) {
>   		pr_err("failed to allocate char dev region\n");
> -		class_destroy(tee_class);
> -		tee_class = NULL;
> +		goto chrdev_err;
>   	}
>   
> +	rc = bus_register(&tee_bus_type);
> +	if (rc) {
> +		pr_err("failed to register tee bus\n");
> +		goto bus_err;
> +	}
> +
> +	return 0;
> +
> +bus_err:
> +	unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES);
> +chrdev_err:
> +	class_destroy(tee_class);
> +	tee_class = NULL;
> +

Hmm.. these error paths/labels look out-of-order.
See 'drivers/i2c/i2c-dev.c' for example.

Normally our error paths in an __init function is of the same order as 
the __exit function implementation. So this should be changed to 
something like:

   +out_unreg_class:
   +	class_destroy(tee_class);
   +	tee_class = NULL;
   +out_unreg_chrdev:
   +	unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES);

>   	return rc;
>   }
>   
> @@ -1052,6 +1088,7 @@ static void __exit tee_exit(void)
>   	class_destroy(tee_class);
>   	tee_class = NULL;
>   	unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES);
> +	bus_unregister(&tee_bus_type);

Since the __exit function order is the reverse of the __init one, lets 
reorder this as:

  +	bus_unregister(&tee_bus_type);
   	class_destroy(tee_class);
    	tee_class = NULL;
    	unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES);

See 'drivers/i2c/i2c-dev.c' for example.

>   }
>   
>   subsys_initcall(tee_init);
> diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
> index 6cfe058..ed16bf1 100644
> --- a/include/linux/tee_drv.h
> +++ b/include/linux/tee_drv.h
> @@ -20,6 +20,8 @@
>   #include <linux/kref.h>
>   #include <linux/list.h>
>   #include <linux/tee.h>
> +#include <linux/device.h>
> +#include <linux/uuid.h>

If possible, let's keep alphabetical order of header files when making 
changes in the patch.

>   
>   /*
>    * The file describes the API provided by the generic TEE driver to the
> @@ -538,4 +540,38 @@ static inline bool tee_param_is_memref(struct tee_param *param)
>   	}
>   }
>   
> +extern struct bus_type tee_bus_type;
> +
> +/**
> + * struct tee_client_device_id - tee based device identifier
> + * @uuid:		For TEE based client devices we use the device uuid
> + *			as the identifier.
> + */
> +struct tee_client_device_id {
> +	uuid_t uuid;
> +};

Hmm.. Do we really need a struct for a single element, rather lets use a 
simple typedef here.

> +
> +/**
> + * struct tee_client_device - tee based device
> + * @id:			device identifier
> + * @dev:		device structure
> + */
> +struct tee_client_device {
> +	struct tee_client_device_id id;
> +	struct device dev;
> +};

Add a blank line here.

> +#define to_tee_client_device(d) container_of(d, struct tee_client_device, dev)
> +
> +/**
> + * struct tee_client_driver - tee client driver
> + * @id_table:		device id table supported by this driver
> + * @driver:		driver structure
> + */
> +struct tee_client_driver {
> +	const struct tee_client_device_id *id_table;
> +	struct device_driver driver;
> +};

Add a blank line here.
> +#define to_tee_client_driver(d) \
> +		container_of(d, struct tee_client_driver, driver)
> +
>   #endif /*__TEE_DRV_H*/
> 

Thanks,
Bhupesh

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

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 11:47 [PATCH v3 0/4] Introduce TEE bus driver framework Sumit Garg
2019-01-11 11:47 ` [PATCH v3 1/4] tee: add bus driver framework for TEE based devices Sumit Garg
2019-01-11 15:09   ` Bhupesh Sharma [this message]
2019-01-15 11:53     ` Sumit Garg
2019-01-11 11:47 ` [PATCH v3 2/4] tee: add supp_nowait flag in tee_context struct Sumit Garg
2019-01-11 11:47 ` [PATCH v3 3/4] tee: optee: add TEE bus device enumeration support Sumit Garg
2019-01-11 11:47 ` [PATCH v3 4/4] hwrng: add OP-TEE based rng driver Sumit Garg

Reply instructions:

You may reply publically 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=6a01fee4-4331-be63-9a78-c4d646b43d29@redhat.com \
    --to=bhsharma@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=daniel.thompson@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mpm@selenic.com \
    --cc=robh+dt@kernel.org \
    --cc=sumit.garg@linaro.org \
    --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

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org infradead-linux-arm-kernel@archiver.kernel.org
	public-inbox-index linux-arm-kernel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox