Re: [PATCH 2/3] staging: android: ion: Add ion driver for Hi6220 SoC platform

From: Dan Carpenter
Date: Fri Oct 09 2015 - 04:54:13 EST


On Thu, Oct 08, 2015 at 03:55:12PM +0800, Chen Feng wrote:
> Signed-off-by: Chen Feng <puck.chen@xxxxxxxxxxxxx>
> Signed-off-by: Yu Dongbin <yudongbin@xxxxxxxxxxxxx>
> ---
> drivers/staging/android/ion/Kconfig | 7 +
> drivers/staging/android/ion/Makefile | 1 +
> drivers/staging/android/ion/hisilicon/Kconfig | 5 +
> drivers/staging/android/ion/hisilicon/Makefile | 1 +
> drivers/staging/android/ion/hisilicon/hi6220_ion.c | 201 +++++++++++++++++++++
> 5 files changed, 215 insertions(+)
> create mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
> create mode 100644 drivers/staging/android/ion/hisilicon/Makefile
> create mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>
> diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
> index 3452346..19c1572 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -33,3 +33,10 @@ config ION_TEGRA
> help
> Choose this option if you wish to use ion on an nVidia Tegra.
>
> +config ION_HISI
> + tristate "Ion for Hisilicon"
> + depends on ARCH_HISI && ION
> + help
> + Choose this option if you wish to use ion on Hisilicon Platform.
> +
> +source "drivers/staging/android/ion/hisilicon/Kconfig"
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index b56fd2b..18cc2aa 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -7,4 +7,5 @@ endif
>
> obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
> obj-$(CONFIG_ION_TEGRA) += tegra/
> +obj-$(CONFIG_ION_HISI) += hisilicon/
>
> diff --git a/drivers/staging/android/ion/hisilicon/Kconfig b/drivers/staging/android/ion/hisilicon/Kconfig
> new file mode 100644
> index 0000000..2b4bd07
> --- /dev/null
> +++ b/drivers/staging/android/ion/hisilicon/Kconfig
> @@ -0,0 +1,5 @@
> +config HI6220_ION
> + bool "Hi6220 ION Driver"
> + depends on ARCH_HISI && ION
> + help
> + Build the Hisilicon Hi6220 ion driver.
> diff --git a/drivers/staging/android/ion/hisilicon/Makefile b/drivers/staging/android/ion/hisilicon/Makefile
> new file mode 100644
> index 0000000..2a89414
> --- /dev/null
> +++ b/drivers/staging/android/ion/hisilicon/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
> diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
> new file mode 100644
> index 0000000..b7d39b8
> --- /dev/null
> +++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
> @@ -0,0 +1,201 @@
> +#define pr_fmt(fmt) "Ion: " fmt
> +
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/mm.h>
> +#include "../ion_priv.h"
> +#include "../ion.h"
> +
> +struct hi6220_ion_type_table {
> + const char *name;
> + enum ion_heap_type type;
> +};
> +
> +static struct hi6220_ion_type_table ion_type_table[] = {
> + {"ion_system", ION_HEAP_TYPE_SYSTEM},
> + {"ion_system_contig", ION_HEAP_TYPE_SYSTEM_CONTIG},
> + {"ion_carveout", ION_HEAP_TYPE_CARVEOUT},
> + {"ion_chunk", ION_HEAP_TYPE_CHUNK},
> + {"ion_dma", ION_HEAP_TYPE_DMA},
> + {"ion_custom", ION_HEAP_TYPE_CUSTOM},
> +};
> +
> +static struct ion_device *idev;
> +static int num_heaps;
> +static struct ion_heap **heaps;
> +static struct ion_platform_heap **heaps_data;
> +
> +static int get_type_by_name(const char *name, enum ion_heap_type *type)
> +{
> + int i, n;
> +
> + n = ARRAY_SIZE(ion_type_table);
> + for (i = 0; i < n; i++) {

No need for the "n" variable.

> + if (strncmp(name, ion_type_table[i].name, strlen(name)))
> + continue;
> +
> + *type = ion_type_table[i].type;
> + return 0;
> + }
> +
> + return -1;

return -EINVAL;

> +}
> +
> +static int hi6220_set_platform_data(struct platform_device *pdev)
> +{
> + unsigned int base;
> + unsigned int size;
> + unsigned int id;
> + const char *heap_name;
> + const char *type_name;
> + enum ion_heap_type type;
> + int ret;
> + struct device_node *np;
> + struct ion_platform_heap *p_data;
> + const struct device_node *dt_node = pdev->dev.of_node;
> + int index = 0;
> +
> + for_each_child_of_node(dt_node, np)
> + num_heaps++;

Indent this line.

> +
> + heaps_data = devm_kzalloc(&pdev->dev,
> + sizeof(struct ion_platform_heap *) * num_heaps,
> + GFP_KERNEL);

Add a NULL check.

> +
> + for_each_child_of_node(dt_node, np) {
> + p_data = devm_kzalloc(&pdev->dev,
> + sizeof(struct ion_platform_heap),
> + GFP_KERNEL);

I would move this allocation closer to the place where it "p_data" is
used so that it comes after all the validation. Also we need to check
for allocation errors.

> +
> + ret = of_property_read_string(np, "heap-name", &heap_name);
> + if (ret < 0) {
> + pr_err("check the name of node %s\n", np->name);
> + continue;
> + }
> +
> + ret = of_property_read_u32(np, "heap-id", &id);
> + if (ret < 0) {
> + pr_err("check the id %s\n", np->name);
> + continue;
> + }
> +
> + ret = of_property_read_u32(np, "heap-base", &base);
> + if (ret < 0) {
> + pr_err("check the base of node %s\n", np->name);
> + continue;
> + }
> +
> + ret = of_property_read_u32(np, "heap-size", &size);
> + if (ret < 0) {
> + pr_err("check the size of node %s\n", np->name);
> + continue;
> + }
> +
> + ret = of_property_read_string(np, "heap-type", &type_name);
> + if (ret < 0) {
> + pr_err("check the type of node %s\n", np->name);
> + continue;
> + }
> +
> + ret = get_type_by_name(type_name, &type);
> + if (ret < 0) {
> + pr_err("type name error %s!\n", type_name);
> + continue;
> + }
> + pr_info("heap index %d : name %s base 0x%x size 0x%x id %d type %d\n",
> + index, heap_name, base, size, id, type);
> +
> + p_data->name = heap_name;
> + p_data->base = base;
> + p_data->size = size;
> + p_data->id = id;
> + p_data->type = type;
> +
> + heaps_data[index] = p_data;
> + index++;
> + }
> + return 0;
> +}
> +
> +static int __init hi6220_ion_probe(struct platform_device *pdev)
> +{
> + int i;
> + int err = 0;
> + static struct ion_platform_heap *p_heap;
> +
> + idev = ion_device_create(NULL);
> + if (IS_ERR_OR_NULL(idev)) {
> + pr_err("ion_device_create err %lx\n", PTR_ERR(idev));

ion_device_create() can never return NULL. It's important to get these
things correct because passing PTR_ERR(NULL) will introduce a static
checker warning because that means success.

> + return PTR_ERR(idev);

Returning success if NULL here.

> + }
> +
> + hi6220_set_platform_data(pdev);
> +
> + heaps = devm_kzalloc(&pdev->dev,
> + sizeof(struct ion_heap *) * num_heaps,
> + GFP_KERNEL);

Use devm_kcalloc(). Null check.

> +
> + /*
> + * create the heaps as specified in the dts file
> + */
> + for (i = 0; i < num_heaps; i++) {
> + p_heap = heaps_data[i];
> + heaps[i] = ion_heap_create(p_heap);
> + if (IS_ERR_OR_NULL(heaps[i])) {
> + err = PTR_ERR(heaps[i]);

Same IS_ERR_OR_NULL() or NULL issues.

> + goto out;
> + }
> +
> + ion_device_add_heap(idev, heaps[i]);
> +
> + pr_info("%s: adding heap %s of type %d with %lx@%lx\n",
> + __func__, p_heap->name, p_heap->type,
> + p_heap->base, (unsigned long)p_heap->size);
> + }
> + return err;

Hopefully this is equivalent to:

return 0;

> +out:

Labels named "out" are bug prone because handling everything is harder
than using named labels and unwinding one step at a time. The bug here
is that we don't call ion_device_destroy().

> + for (i = 0; i < num_heaps; ++i)
> + ion_heap_destroy(heaps[i]);
> + return err;

Write it like this:

err_free_heaps:
for (i = 0; i < num_heaps; ++i)
ion_heap_destroy(heaps[i]);
err_free_idev:
ion_device_destroy(idev);

return err;

> +}
> +
> +static int hi6220_ion_remove(struct platform_device *pdev)
> +{
> + int i;
> +
> + ion_device_destroy(idev);
> + for (i = 0; i < num_heaps; i++) {
> + if (!heaps[i])
> + continue;

We don't really need this NULL check and it isn't there in the
hi6220_ion_probe() unwind code.

> + ion_heap_destroy(heaps[i]);
> + heaps[i] = NULL;
> + }
> +
> + return 0;
> +}

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/