| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <37b6b890-e537-7424-6b26-04565681f40a@c-s.fr>
Date: Wed, 15 Apr 2020 18:52:24 +0200
From: Christophe Leroy <christophe.leroy@....fr>
To: Wang Wenhu <wenhu.wang@...o.com>, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, oss@...error.net,
linuxppc-dev@...ts.ozlabs.org
Cc: kernel@...o.com, Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> A driver for freescale 85xx platforms to access the Cache-Sram form
> user level. This is extremely helpful for some user-space applications
> that require high performance memory accesses.
>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@....fr>
> Cc: Scott Wood <oss@...error.net>
> Cc: Michael Ellerman <mpe@...erman.id.au>
> Cc: linuxppc-dev@...ts.ozlabs.org
> Signed-off-by: Wang Wenhu <wenhu.wang@...o.com>
> ---
> Changes since v1:
> * Addressed comments of Greg K-H
> * Moved kfree(info->name) into uio_info_free_internal()
> ---
> drivers/uio/Kconfig | 8 ++
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_fsl_85xx_cache_sram.c | 182 ++++++++++++++++++++++++++
> 3 files changed, 191 insertions(+)
> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81cfc2b..afd38ec13de0 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -105,6 +105,14 @@ config UIO_NETX
> To compile this driver as a module, choose M here; the module
> will be called uio_netx.
>
> +config UIO_FSL_85XX_CACHE_SRAM
> + tristate "Freescale 85xx Cache-Sram driver"
> + depends on FSL_85XX_CACHE_SRAM
Is there any point having FSL_85XX_CACHE_SRAM without this ?
Should it be the other way round, leave FSL_85XX_CACHE_SRAM unselectable
by user, and this driver select FSL_85XX_CACHE_SRAM instead of depending
on it ?
> + help
> + Generic driver for accessing the Cache-Sram form user level. This
> + is extremely helpful for some user-space applications that require
> + high performance memory accesses.
> +
> config UIO_FSL_ELBC_GPCM
> tristate "eLBC/GPCM driver"
> depends on FSL_LBC
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2a4539..be2056cffc21 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o
> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
> obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o
> +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o
> obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
> diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c
> new file mode 100644
> index 000000000000..fb6903fdaddb
> --- /dev/null
> +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
> + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@...o.com>
> + * All rights reserved.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/uio_driver.h>
> +#include <linux/stringify.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <asm/fsl_85xx_cache_sram.h>
> +
> +#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
> +#define UIO_NAME "uio_cache_sram"
> +
> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> + { .compatible = "uio,fsl,p2020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p2010-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1011-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1013-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1022-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1021-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1012-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1025-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1016-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1024-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1015-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1010-l2-cache-controller", },
> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", },
> + {},
> +};
> +
> +static void uio_info_free_internal(struct uio_info *info)
> +{
> + struct uio_mem *uiomem = &info->mem[0];
> +
> + while (uiomem < &info->mem[MAX_UIO_MAPS]) {
> + if (uiomem->size) {
> + mpc85xx_cache_sram_free(uiomem->internal_addr);
> + kfree(uiomem->name);
> + }
> + uiomem++;
> + }
> +
> + kfree(info->name);
> +}
> +
> +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev)
> +{
> + struct device_node *parent = pdev->dev.of_node;
> + struct device_node *node = NULL;
> + struct uio_info *info;
> + struct uio_mem *uiomem;
> + const char *dt_name;
> + u32 mem_size;
> + u32 align;
Align is not used outside of the for loop, it should be declared in the
loop block.
> + void *virt;
Same for virt
> + phys_addr_t phys;
Same for phys
> + int ret = -ENODEV;
It looks like this init value is unneeded, you should leave 'ret'
uninitialised (unless I missed some way out and you get a warning).
> +
> + /* alloc uio_info for one device */
> + info = kzalloc(sizeof(*info), GFP_KERNEL);
> + if (!info) {
> + ret = -ENOMEM;
> + goto err_out;
Nothing special is done at err_out, you should instead do:
if (!info)
return -ENOMEM;
> + }
> +
> + /* get optional uio name */
> + if (of_property_read_string(parent, "uio_name", &dt_name))
> + dt_name = UIO_NAME;
> +
> + info->name = kstrdup(dt_name, GFP_KERNEL);
> + if (!info->name) {
> + ret = -ENOMEM;
> + goto err_info_free;
> + }
> +
> + uiomem = &info->mem[0];
I'd prefer
uiomem = info->mem;
> + for_each_child_of_node(parent, node) {
> + ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
> + if (ret) {
> + ret = -EINVAL;
> + goto err_info_free_internel;
> + }
> +
> + if (mem_size == 0) {
> + dev_err(&pdev->dev, "cache-mem-size should not be 0\n");
> + ret = -EINVAL;
> + goto err_info_free_internel;
> + }
> +
> + align = 2;
> + while (align < mem_size)
> + align *= 2;
I think ilog2() or one of it friends should be used here, maybe
roundup_pow_of_two()
> + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align);
> + if (!virt) {
> + /* mpc85xx_cache_sram_alloc to define the cause */
> + ret = -EINVAL;
Should it be -ENOMEM like any allocation failure ?
> + goto err_info_free_internel;
> + }
> +
> + uiomem->memtype = UIO_MEM_PHYS;
> + uiomem->addr = phys;
> + uiomem->size = mem_size;
> + uiomem->name = kstrdup(node->name, GFP_KERNEL);;
> + uiomem->internal_addr = virt;
> + ++uiomem;
Usually people use
uiomem++;
> +
> + if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
I'd prefer
if (uiomem - info->mem >= MAX_UIO_MAPS) {
> + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n",
> + MAX_UIO_MAPS);
> + break;
> + }
> + }
> +
> + while (uiomem < &info->mem[MAX_UIO_MAPS]) {
I'd prefer
while (uiomem - info->mem < MAX_UIO_MAPS) {
> + uiomem->size = 0;
> + ++uiomem;
> + }
> +
> + if (info->mem[0].size == 0) {
Is there any point in doing all the clearing loop above if it's to bail
out here ?
Wouldn't it be cleaner to do the test above the clearing loop, by just
checking whether uiomem is still equal to info->mem ?
> + dev_err(&pdev->dev, "error no valid uio-map configured\n");
> + ret = -EINVAL;
> + goto err_info_free_internel;
> + }
> +
> + info->version = "0.1.0";
Could you define some DRIVER_VERSION in the top of the file next to
DRIVER_NAME instead of hard coding in the middle on a function ?
> +
> + /* register uio device */
> + if (uio_register_device(&pdev->dev, info)) {
> + dev_err(&pdev->dev, "uio registration failed\n");
> + ret = -ENODEV;
> + goto err_info_free_internel;
> + }
> +
> + platform_set_drvdata(pdev, info);
> +
> + return 0;
> +err_info_free_internel:
Do you mean 'internal' instead of 'internel' ?
> + uio_info_free_internal(info);
> +err_info_free:
> + kfree(info);
> +err_out:
> + return ret;
> +}
> +
> +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev)
> +{
> + struct uio_info *info = platform_get_drvdata(pdev);
> +
> + uio_unregister_device(info);
> +
> + uio_info_free_internal(info);
> +
> + kfree(info);
> +
> + return 0;
> +}
> +
> +static struct platform_driver uio_fsl_85xx_cache_sram = {
> + .probe = uio_fsl_85xx_cache_sram_probe,
> + .remove = uio_fsl_85xx_cache_sram_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = uio_mpc85xx_l2ctlr_of_match,
> + },
> +};
> +
> +module_platform_driver(uio_fsl_85xx_cache_sram);
> +
> +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@...o.com>");
> +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_LICENSE("GPL v2");
>
Christophe
Powered by blists - more mailing lists