| 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: <20200415140705.116850-1-wenhu.wang@vivo.com>
Date: Wed, 15 Apr 2020 07:07:05 -0700
From: Wang Wenhu <wenhu.wang@...o.com>
To: gregkh@...uxfoundation.org
Cc: christophe.leroy@....fr, kernel@...o.com,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
mpe@...erman.id.au, oss@...error.net, wenhu.wang@...o.com
Subject: Re: [PATCH 5/5] drivers: uio: new driver for fsl_85xx_cache_sram>On Wed, Apr 15, 2020 at 05:33:46AM -0700, Wang Wenhu wrote:
Hi, Greg k-h!
Thank you for you fast reply. All the comments will
be addressed with v2 soon. Detailed explanations are
just below specific comment.
>> 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>
>> ---
>> drivers/uio/Kconfig | 8 ++
>> drivers/uio/Makefile | 1 +
>> drivers/uio/uio_fsl_85xx_cache_sram.c | 195 ++++++++++++++++++++++++++
>> 3 files changed, 204 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
>> + 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..e11202dd5b93
>> --- /dev/null
>> +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
>> @@ -0,0 +1,195 @@
>> +// 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.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published
>> + * by the Free Software Foundation.
>
>Nit, you don't need this sentance anymore now that you have the SPDX
>line above
>
Got, I will delete it with v2.
>> + */
>> +
>> +#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_VERSION "0.1.0"
>
>Don't do DRIVER_VERSIONs, they never work once the code is in the kernel
>tree.
>
>> +#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
>
>KBUILD_MODNAME?
Yes, and sorry for that I did not get what should have been done?
>
>> +#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++;
>> + }
>> +}
>> +
>> +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;
>> + void *virt;
>> + phys_addr_t phys;
>> + int ret = -ENODEV;
>> +
>> + /* alloc uio_info for one device */
>> + info = kzalloc(sizeof(*info), GFP_KERNEL);
>> + if (!info) {
>> + dev_err(&pdev->dev, "kzalloc uio_info failed\n");
>
>kzalloc already says this.
>
Surely, I will delete with v2.
>> + ret = -ENOMEM;
>> + goto err_out;
>> + }
>> +
>> + /* 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) {
>> + dev_err(&pdev->dev, "error kstrdup uio_name\n");
>
>kstrdup should have given you an error string already, right?
>
Surely, I will delete with v2.
>> + ret = -ENOMEM;
>> + goto err_info_free;
>> + }
>> +
>> + uiomem = &info->mem[0];
>> + for_each_child_of_node(parent, node) {
>> + if (!node) {
>> + dev_err(&pdev->dev, "device's OF-node is NULL\n");
>
>How can this happen?
>
My fault, this would never happen. I will address it in v2.
>> + continue;
>
>Why not error out?
>
>> + }
>> +
>> + ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
>> + if (ret) {
>> + dev_err(&pdev->dev, "missing cache-mem-size value\n");
>
>You don't exit?
>
>> + continue;
>> + }
>> +
>> + if (mem_size == 0) {
>> + dev_err(&pdev->dev, "cache-mem-size should not be 0\n");
>
>Again, you don't exit?
>
>> + continue;
>> + }
>> +
>> + align = 2;
>> + while (align < mem_size)
>> + align *= 2;
>> + virt = mpc85xx_cache_sram_alloc(mem_size, &phys, align);
>> + if (!virt) {
>> + dev_err(&pdev->dev, "allocate 0x%x cache-mem failed\n", mem_size);
>
>You don't exit?
>
Actual all these situations should error out. For the continue branches,
we got a situation that we accept all the possibly correct child node
configurations, and it works. But it is not the common circumstance.
I have tested all these situations and I will change all these to error
out processes with v2.
>> + continue;
>> + }
>> +
>> + uiomem->memtype = UIO_MEM_PHYS;
>> + uiomem->addr = phys;
>> + uiomem->size = mem_size;
>> + uiomem->name = kstrdup(node->name, GFP_KERNEL);;
>> + uiomem->internal_addr = virt;
>> + ++uiomem;
>> +
>> + if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
>> + dev_warn(&pdev->dev, "device has more than "
>> + __stringify(MAX_UIO_MAPS)
>> + " I/O memory resources.\n");
>
>What can someone do with that?
>
Surely it should be more friendly. I will address it with v2.
>thanks,
>
>greg k-h
Powered by blists - more mailing lists