* Re: [PATCH v2] powerpc/setup_64: Set cache-line-size based on cache-block-size
From: Michael Ellerman @ 2020-04-16 11:43 UTC (permalink / raw)
To: Chris Packham, christophe.leroy@c-s.fr, paulus@samba.org,
benh@kernel.crashing.org, oss@buserror.net, tglx@linutronix.de
Cc: Hamish Martin, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <343c0e8b01ab74481e0b8dfbe588b1c84127a487.camel@alliedtelesis.co.nz>
Chris Packham <Chris.Packham@alliedtelesis.co.nz> writes:
> Hi All,
>
> On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote:
>> If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not,
>> use
>> the block-size value for both. Per the devicetree spec cache-line-
>> size
>> is only needed if it differs from the block size.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> It looks as though the bsizep = lsizep is not required per the spec
>> but it's
>> probably safer to retain it.
>>
>> Changes in v2:
>> - Scott pointed out that u-boot should be filling in the cache
>> properties
>> (which it does). But it does not specify a cache-line-size because
>> it
>> provides a cache-block-size and the spec says you don't have to if
>> they are
>> the same. So the error is in the parsing not in the devicetree
>> itself.
>>
>
> Ping? This thread went kind of quiet.
I replied in the other thread:
https://lore.kernel.org/linuxppc-dev/87369xx99u.fsf@mpe.ellerman.id.au/
But then the merge window happened which is a busy time.
What I'd really like is a v3 that incorporates the info I wrote in the
other thread and a Fixes tag.
If you feel like doing that, that would be great. Otherwise I'll do it
tomorrow.
cheers
^ permalink raw reply
* [PATCH RESEND, v3, 0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 11:16 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
This series add a new uio driver for freescale 85xx platforms to
access the Cache-Sram form user level. This is extremely helpful
for the user-space applications that require high performance memory
accesses.
It fixes the compile errors and warning of the hardware level drivers
and implements the uio driver in uio_fsl_85xx_cache_sram.c.
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Drop the patch that modifies Kconfigs of arch/powerpc/platforms
and modified the sequence of patches:
01:dropped, 02->03, 03->02, 04->01, 05->04
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
Wang Wenhu (4):
powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
drivers: uio: new driver for fsl_85xx_cache_sram
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++
5 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
--
2.17.1
^ permalink raw reply
* [PATCH RESEND, v3, 1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
From: Wang Wenhu @ 2020-04-16 11:16 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416111609.4191-1-wenhu.wang@vivo.com>
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^~~~~~~~
pci_iomap
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 2d0af0c517bb..7533572492f0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/of_address.h>
#include <asm/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND, v3, 3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 11:16 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416111609.4191-1-wenhu.wang@vivo.com>
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Warning information:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram()
The function mpc85xx_l2ctlr_of_probe() references
the function __init instantiate_cache_sram().
This is often because mpc85xx_l2ctlr_of_probe lacks a __init
annotation or the annotation of instantiate_cache_sram is wrong.
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index be3aef4229d7..3de5ac8382c0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
}
EXPORT_SYMBOL(mpc85xx_cache_sram_free);
-int __init instantiate_cache_sram(struct platform_device *dev,
+int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params)
{
int ret = 0;
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND, v3, 2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 11:16 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416111609.4191-1-wenhu.wang@vivo.com>
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^~~~~~~~~~~~~~~~
bitmap_complement
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration]
iounmap(cache_sram->base_virt);
^~~~~~~
roundup
cc1: all warnings being treated as errors
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index f6c665dac725..be3aef4229d7 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <asm/pgtable.h>
#include <asm/fsl_85xx_cache_sram.h>
+#include <linux/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH RESEND, v3, 4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 11:16 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416111609.4191-1-wenhu.wang@vivo.com>
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@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calculation
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
---
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++++++
3 files changed, 168 insertions(+)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81cfc2b..9c3b47461b71 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -105,6 +105,15 @@ 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_SOC_BOOKE && PPC32
+ select 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..8701df695307
--- /dev/null
+++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
+ * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.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_INFO_VER "devicetree,pseudo"
+#define UIO_NAME "uio_cache_sram"
+
+static void uio_info_free_internal(struct uio_info *info)
+{
+ struct uio_mem *uiomem = info->mem;
+
+ while (uiomem < &info->mem[MAX_UIO_MAPS]) {
+ if (uiomem->internal_addr) {
+ mpc85xx_cache_sram_free(uiomem->internal_addr);
+ kfree(uiomem->name);
+ memset(uiomem, 0, sizeof(*uiomem));
+ }
+ 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;
+ int ret;
+
+ /* alloc uio_info for one device */
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ 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;
+ for_each_child_of_node(parent, node) {
+ void *virt;
+ phys_addr_t phys;
+
+ ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
+ if (ret) {
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ if (mem_size == 0) {
+ dev_err(&pdev->dev, "cache-mem-size should not be 0\n");
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ virt = mpc85xx_cache_sram_alloc(mem_size,
+ &phys,
+ roundup_pow_of_two(mem_size));
+ if (!virt) {
+ /* mpc85xx_cache_sram_alloc to define the real cause */
+ ret = -ENOMEM;
+ goto err_info_free_internal;
+ }
+
+ 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, "more than %d uio-maps for device.\n",
+ MAX_UIO_MAPS);
+ break;
+ }
+ }
+
+ if (uiomem == info->mem) {
+ dev_err(&pdev->dev, "error no valid uio-map configured\n");
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ info->version = UIO_INFO_VER;
+
+ /* register uio device */
+ if (uio_register_device(&pdev->dev, info)) {
+ dev_err(&pdev->dev, "uio registration failed\n");
+ ret = -ENODEV;
+ goto err_info_free_internal;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ return 0;
+err_info_free_internal:
+ uio_info_free_internal(info);
+err_info_free:
+ kfree(info);
+ 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 const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
+ { .compatible = "uio,mpc85xx-cache-sram", },
+ {},
+};
+
+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@vivo.com>");
+MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: 王文虎 @ 2020-04-16 11:14 UTC (permalink / raw)
To: Christophe Leroy; +Cc: oss, gregkh, linuxppc-dev, linux-kernel, kernel
In-Reply-To: <a3032813-ba1e-101a-0b73-cc477d702aac@c-s.fr>
Hi,
From: Christophe Leroy <christophe.leroy@c-s.fr>
Date: 2020-04-16 18:36:38
To:"王文虎" <wenhu.wang@vivo.com>
cc: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,linuxppc-dev@lists.ozlabs.org,kernel@vivo.com
Subject: Re: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>
>
>Le 16/04/2020 à 11:29, 王文虎 a écrit :
>> Hi,
>> Seems there is something wrong with the server that multiple dumplications
>> of the v3 patches were sent out, please ignore the rest and take this newest
>> series as formal count.
>
>Which series ?
>
>It seems you sent 3 times, at 9:29, 9:41 and 9:49 (Paris Time)
>
> From the series of 9:29, I received patches 0 to 3
> From the series of 9:41, I received patches 0 to 3
> From the series of 9:49, I received patches 0 and 4.
>
>Looks like powerpc patchwork
>(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=78320)
>got:
> From the series of 9:29, I received patches 0 to 4
> From the series of 9:41, I received patches 1 to 4
> From the series of 9:49, I received patches 1 to 4
>
>So this seems to be something wrong somewhere.
>
>Christophe
>
Hi Christophe,
Sorry again, and I don't know which best fit you all. I guess a RESEND tag might help.
So I will send another series with RESEND tag, please just drop all this three.
Hope that relly won't trouble you yelling, and hope the mail server would work well.
Thanks,
Wenhu
>>
>> From: Wang Wenhu <wenhu.wang@vivo.com>
>> Date: 2020-04-16 15:49:14
>> To: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,christophe.leroy@c-s.fr,linuxppc-dev@lists.ozlabs.org
>> Cc: kernel@vivo.com,Wang Wenhu <wenhu.wang@vivo.com>
>> Subject: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>This series add a new uio driver for freescale 85xx platforms to
>>> access the Cache-Sram form user level. This is extremely helpful
>>> for the user-space applications that require high performance memory
>>> accesses.
>>>
>>> It fixes the compile errors and warning of the hardware level drivers
>>> and implements the uio driver in uio_fsl_85xx_cache_sram.c.
>>>
>>> Changes since v1:
>>> * Addressed comments from Greg K-H
>>> * Moved kfree(info->name) into uio_info_free_internal()
>>>
>>> Changes since v2:
>>> * Drop the patch that modifies Kconfigs of arch/powerpc/platforms
>>> and modified the sequence of patches:
>>> 01:dropped, 02->03, 03->02, 04->01, 05->04
>>> * Addressed comments from Greg, Scott and Christophe
>>> * Use "uiomem->internal_addr" as if condition for sram memory free,
>>> and memset the uiomem entry
>>> * Modified of_match_table make the driver apart from Cache-Sram HW info
>>> which belong to the HW level driver fsl_85xx_cache_sram to match
>>> * Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
>>> * Remove useless clear block of uiomem entries.
>>> * Use UIO_INFO_VER micro for info->version, and define it as
>>> "devicetree,pseudo", meaning this is pseudo device and probed from
>>> device tree configuration
>>> * Select FSL_85XX_CACHE_SRAM rather than depends on it
>>>
>>> Wang Wenhu (4):
>>> powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
>>> powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
>>> powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
>>> drivers: uio: new driver for fsl_85xx_cache_sram
>>>
>>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
>>> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
>>> drivers/uio/Kconfig | 9 ++
>>> drivers/uio/Makefile | 1 +
>>> drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++
>>> 5 files changed, 171 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>>>
>>> --
>>> 2.17.1
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: Christophe Leroy @ 2020-04-16 10:36 UTC (permalink / raw)
To: 王文虎; +Cc: oss, gregkh, linuxppc-dev, linux-kernel, kernel
In-Reply-To: <AIgAKQBlCIqtPx5U5P0kFqpr.3.1587029369636.Hmail.wenhu.wang@vivo.com>
Le 16/04/2020 à 11:29, 王文虎 a écrit :
> Hi,
> Seems there is something wrong with the server that multiple dumplications
> of the v3 patches were sent out, please ignore the rest and take this newest
> series as formal count.
Which series ?
It seems you sent 3 times, at 9:29, 9:41 and 9:49 (Paris Time)
From the series of 9:29, I received patches 0 to 3
From the series of 9:41, I received patches 0 to 3
From the series of 9:49, I received patches 0 and 4.
Looks like powerpc patchwork
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=78320)
got:
From the series of 9:29, I received patches 0 to 4
From the series of 9:41, I received patches 1 to 4
From the series of 9:49, I received patches 1 to 4
So this seems to be something wrong somewhere.
Christophe
>
> Thanks,
> Wenhu
>
> From: Wang Wenhu <wenhu.wang@vivo.com>
> Date: 2020-04-16 15:49:14
> To: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,christophe.leroy@c-s.fr,linuxppc-dev@lists.ozlabs.org
> Cc: kernel@vivo.com,Wang Wenhu <wenhu.wang@vivo.com>
> Subject: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>This series add a new uio driver for freescale 85xx platforms to
>> access the Cache-Sram form user level. This is extremely helpful
>> for the user-space applications that require high performance memory
>> accesses.
>>
>> It fixes the compile errors and warning of the hardware level drivers
>> and implements the uio driver in uio_fsl_85xx_cache_sram.c.
>>
>> Changes since v1:
>> * Addressed comments from Greg K-H
>> * Moved kfree(info->name) into uio_info_free_internal()
>>
>> Changes since v2:
>> * Drop the patch that modifies Kconfigs of arch/powerpc/platforms
>> and modified the sequence of patches:
>> 01:dropped, 02->03, 03->02, 04->01, 05->04
>> * Addressed comments from Greg, Scott and Christophe
>> * Use "uiomem->internal_addr" as if condition for sram memory free,
>> and memset the uiomem entry
>> * Modified of_match_table make the driver apart from Cache-Sram HW info
>> which belong to the HW level driver fsl_85xx_cache_sram to match
>> * Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
>> * Remove useless clear block of uiomem entries.
>> * Use UIO_INFO_VER micro for info->version, and define it as
>> "devicetree,pseudo", meaning this is pseudo device and probed from
>> device tree configuration
>> * Select FSL_85XX_CACHE_SRAM rather than depends on it
>>
>> Wang Wenhu (4):
>> powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
>> powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
>> powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
>> drivers: uio: new driver for fsl_85xx_cache_sram
>>
>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
>> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
>> drivers/uio/Kconfig | 9 ++
>> drivers/uio/Makefile | 1 +
>> drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++
>> 5 files changed, 171 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>>
>> --
>> 2.17.1
>>
>
>
^ permalink raw reply
* Re: [PATCH v2 0/2] Don't generate thousands of new warnings when building docs
From: Jani Nikula @ 2020-04-16 10:05 UTC (permalink / raw)
To: Jonathan Corbet, Mauro Carvalho Chehab
Cc: Ricardo Ribalda Delgado, Linux Doc Mailing List, target-devel,
Paul Mackerras, H. Peter Anvin, Alex Shi, linux-scsi, x86,
Tyler Hicks, Ingo Molnar, Jakub Kicinski, Jacopo Mondi,
Luca Ceresoli, Johannes Berg, ecryptfs, Matthias Maennich,
dmaengine, Borislav Petkov, Thomas Gleixner, Martin K. Petersen,
netdev, linux-kernel, Vinod Koul, Harry Wei, Greg Kroah-Hartman,
Hans Verkuil, linuxppc-dev, David S. Miller, Madhuparna Bhowmik
In-Reply-To: <20200320171020.78f045c5@lwn.net>
On Fri, 20 Mar 2020, Jonathan Corbet <corbet@lwn.net> wrote:
> On Fri, 20 Mar 2020 16:11:01 +0100
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
>> This small series address a regression caused by a new patch at
>> docs-next (and at linux-next).
>
> I don't know how I missed that mess, sorry. I plead distracting times or
> something like that. Heck, I think I'll blame everything on the plague
> for at least the next few weeks.
>
> Anyway, I've applied this, thanks for cleaning it up.
There's still more fallout from the autosectionlabel extension
introduced in 58ad30cf91f0 ("docs: fix reference to
core-api/namespaces.rst"), e.g. in i915.rst.
The biggest trouble is, if you have headings in kernel-doc comments,
Sphinx is unable pinpoint where the dupes are. For example:
Documentation/gpu/i915.rst:610: WARNING: duplicate label gpu/i915:layout, other instance in
Documentation/gpu/i915.rst
However there is no "layout" label in i915.rst. The one being warned
about I can dig into based on the line number, but not the second
one. You have to resort to grepping the source. And avoiding duplicate
subsection headings in completely isolated places is a minefield.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re:[PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: 王文虎 @ 2020-04-16 9:29 UTC (permalink / raw)
To: Wang Wenhu; +Cc: gregkh, linux-kernel, oss, kernel, linuxppc-dev
In-Reply-To: <20200416074918.3617-1-wenhu.wang@vivo.com>
Hi,
Seems there is something wrong with the server that multiple dumplications
of the v3 patches were sent out, please ignore the rest and take this newest
series as formal count.
Thanks,
Wenhu
From: Wang Wenhu <wenhu.wang@vivo.com>
Date: 2020-04-16 15:49:14
To: gregkh@linuxfoundation.org,linux-kernel@vger.kernel.org,oss@buserror.net,christophe.leroy@c-s.fr,linuxppc-dev@lists.ozlabs.org
Cc: kernel@vivo.com,Wang Wenhu <wenhu.wang@vivo.com>
Subject: [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram>This series add a new uio driver for freescale 85xx platforms to
>access the Cache-Sram form user level. This is extremely helpful
>for the user-space applications that require high performance memory
>accesses.
>
>It fixes the compile errors and warning of the hardware level drivers
>and implements the uio driver in uio_fsl_85xx_cache_sram.c.
>
>Changes since v1:
> * Addressed comments from Greg K-H
> * Moved kfree(info->name) into uio_info_free_internal()
>
>Changes since v2:
> * Drop the patch that modifies Kconfigs of arch/powerpc/platforms
> and modified the sequence of patches:
> 01:dropped, 02->03, 03->02, 04->01, 05->04
> * Addressed comments from Greg, Scott and Christophe
> * Use "uiomem->internal_addr" as if condition for sram memory free,
> and memset the uiomem entry
> * Modified of_match_table make the driver apart from Cache-Sram HW info
> which belong to the HW level driver fsl_85xx_cache_sram to match
> * Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
> * Remove useless clear block of uiomem entries.
> * Use UIO_INFO_VER micro for info->version, and define it as
> "devicetree,pseudo", meaning this is pseudo device and probed from
> device tree configuration
> * Select FSL_85XX_CACHE_SRAM rather than depends on it
>
>Wang Wenhu (4):
> powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
> powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
> powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
> drivers: uio: new driver for fsl_85xx_cache_sram
>
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
> drivers/uio/Kconfig | 9 ++
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++
> 5 files changed, 171 insertions(+), 1 deletion(-)
> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>
>--
>2.17.1
>
^ permalink raw reply
* Re: [Skiboot] [PATCH v7 0/4] Support for Self Save API in OPAL
From: Nicholas Piggin @ 2020-04-16 9:20 UTC (permalink / raw)
To: ego, linux-kernel, linuxppc-dev, linuxram, mpe, oohall,
pratik.r.sampat, Pratik Rajesh Sampat, skiboot
In-Reply-To: <20200416075341.75268-1-psampat@linux.ibm.com>
Excerpts from Pratik Rajesh Sampat's message of April 16, 2020 5:53 pm:
> v6: https://lists.ozlabs.org/pipermail/skiboot/2020-March/016645.html
> Changelog
> v6 --> v7
> 1. Addressed comments from Gautham for reporting warnings and errors
>
> Background
> ==========
>
> The power management framework on POWER systems include core idle
> states that lose context. Deep idle states namely "winkle" on POWER8
> and "stop4" and "stop5" on POWER9 can be entered by a CPU to save
> different levels of power, as a consequence of which all the
> hypervisor resources such as SPRs and SCOMs are lost.
>
> For most SPRs, saving and restoration of content for SPRs and SCOMs
> is handled by the hypervisor kernel prior to entering an post exit
> from an idle state respectively. However, there is a small set of
> critical SPRs and XSCOMs that are expected to contain sane values even
> before the control is transferred to the hypervisor kernel at system
> reset vector.
>
> For this purpose, microcode firmware provides a mechanism to restore
> values on certain SPRs. The communication mechanism between the
> hypervisor kernel and the microcode is a standard interface called
> sleep-winkle-engine (SLW) on Power8 and Stop-API on Power9 which is
> abstracted by OPAL calls from the hypervisor kernel. The Stop-API
> provides an interface known as the self-restore API, to which the SPR
> number and a predefined value to be restored on wake-up from a deep
> stop state is supplied.
>
>
> Motivation to introduce a new Stop-API
> ======================================
>
> The self-restore API expects not just the SPR number but also the
> value with which the SPR is restored. This is good for those SPRs such
> as HSPRG0 whose values do not change at runtime, since for them, the
> kernel can invoke the self-restore API at boot time once the values of
> these SPRs are determined.
>
> However, there are use-cases where-in the value to be saved cannot be
> known or cannot be updated in the layer it currently is.
> The shortcomings and the new use-cases which cannot be served by the
> existing self-restore API, serves as motivation for a new API:
Thanks for writing this up, it goes some way to help think about the
feature.
> Shortcoming1:
> ------------
> In a special wakeup scenario when a CPU is woken up in stop4/5 and
> after the task is done, the HCODE puts it back to stop. The value of
> PSSCR is passed to the HCODE via the self-restore API. The kernel
> currently provides the value of the deepest stop state due to being
> conservative. Thus if a core that was in stop4 was woken up due to
> special wakeup, the HCODE will now put it back to stop5 thus increasing
> the subsequent wakeup latency to ~200us.
> A mechanism is needed in place to update the PSSCR value each time the
> core is woken up due to special wakeup.
This seems like a shortcoming of the wakeup firmware that shouldn't need
any APIs to the kernel to solve, but the whole deep sleep wakeup seems
like a shortcoming so let's assume they won't do that for whatever
reason, then how much of a problem is this really? Are special wakeups
that frequent?
> Shortcoming2:
> ------------
> The value of LPCR is dynamic based on if the CPU is entered a stop
> state during cpu idle versus cpu hotplug.
> Today, an additional self-restore call is made before entering
> CPU-Hotplug to clear the PECE1 bit in stop-API so that if we are
> woken up by a special wakeup on an offlined CPU, we go back to stop
> with the the bit cleared.
> There is a overhead of an extra call
This is a self-restore call when we offline or online a CPU? That's not
a real problem either, is it?
> New Use-case:
> -------------
> In the case where the hypervisor is running on an
> ultravisor environment, the boot time is too late in the cycle to make
> the self-restore API calls, as these cannot be invoked from an
> non-secure context anymore
>
> To address these shortcomings, the firmware provides another API known
> as the self-save API. The self-save API only takes the SPR number as a
> parameter and will ensure that on wakeup from a deep-stop state the
> SPR is restored with the value that it contained prior to entering the
> deep-stop.
>
If the ultravisor is deployed in production only systems where we don't
use runtime deep-stop states, do we need to handle this case?
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function
From: Cornelia Huck @ 2020-04-16 8:50 UTC (permalink / raw)
To: Tianjia Zhang
Cc: christoffer.dall, wanpengli, kvm, david, heiko.carstens, peterx,
linux-kernel, hpa, kvmarm, linux-s390, frankja, Marc Zyngier,
joro, x86, borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, linux-mips, sean.j.christopherson, james.morse,
pbonzini, Vitaly Kuznetsov, linuxppc-dev
In-Reply-To: <8b92fb5b-5138-0695-fb90-6c36b8dfad00@linux.alibaba.com>
On Thu, 16 Apr 2020 16:45:33 +0800
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote:
> On 2020/4/16 16:28, Marc Zyngier wrote:
> > On 2020-04-16 08:03, Vitaly Kuznetsov wrote:
> >> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> writes:
> >>
> >>> In earlier versions of kvm, 'kvm_run' is an independent structure
> >>> and is not included in the vcpu structure. At present, 'kvm_run'
> >>> is already included in the vcpu structure, so the parameter
> >>> 'kvm_run' is redundant.
> >>>
> >>> This patch simplify the function definition, removes the extra
> >>> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure
> >>> if necessary.
> >>>
> >>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> >>> ---
> >>>
> >>> v2 change:
> >>> remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
> >>>
> >>> arch/mips/kvm/mips.c | 3 ++-
> >>> arch/powerpc/kvm/powerpc.c | 3 ++-
> >>> arch/s390/kvm/kvm-s390.c | 3 ++-
> >>> arch/x86/kvm/x86.c | 11 ++++++-----
> >>> include/linux/kvm_host.h | 2 +-
> >>> virt/kvm/arm/arm.c | 6 +++---
> >>> virt/kvm/kvm_main.c | 2 +-
> >>> 7 files changed, 17 insertions(+), 13 deletions(-)
> > Overall, there is a large set of cleanups to be done when both the vcpu
> > and the run
> > structures are passed as parameters at the same time. Just grepping the
> > tree for
> > kvm_run is pretty instructive.
> >
> > M.
>
> Sorry, it's my mistake, I only compiled the x86 platform, I will submit
> patch again.
I think it's completely fine (and even preferable) to do cleanups like
that on top.
[FWIW, I compiled s390 here.]
^ permalink raw reply
* Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function
From: Cornelia Huck @ 2020-04-16 8:10 UTC (permalink / raw)
To: Tianjia Zhang
Cc: wanpengli, kvm, david, heiko.carstens, peterx, linux-mips, hpa,
kvmarm, linux-s390, frankja, maz, joro, x86, borntraeger, mingo,
julien.thierry.kdev, thuth, gor, suzuki.poulose, kvm-ppc, bp,
tglx, linux-arm-kernel, jmattson, tsbogend, christoffer.dall,
sean.j.christopherson, linux-kernel, james.morse, pbonzini,
vkuznets, linuxppc-dev
In-Reply-To: <20200416051057.26526-1-tianjia.zhang@linux.alibaba.com>
On Thu, 16 Apr 2020 13:10:57 +0800
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote:
> In earlier versions of kvm, 'kvm_run' is an independent structure
> and is not included in the vcpu structure. At present, 'kvm_run'
> is already included in the vcpu structure, so the parameter
> 'kvm_run' is redundant.
>
> This patch simplify the function definition, removes the extra
s/simplify/simplifies/
> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure
s/extract/extracts/
> if necessary.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> ---
>
> v2 change:
> remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
>
> arch/mips/kvm/mips.c | 3 ++-
> arch/powerpc/kvm/powerpc.c | 3 ++-
> arch/s390/kvm/kvm-s390.c | 3 ++-
> arch/x86/kvm/x86.c | 11 ++++++-----
> include/linux/kvm_host.h | 2 +-
> virt/kvm/arm/arm.c | 6 +++---
> virt/kvm/kvm_main.c | 2 +-
> 7 files changed, 17 insertions(+), 13 deletions(-)
>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function
From: Tianjia Zhang @ 2020-04-16 9:08 UTC (permalink / raw)
To: Cornelia Huck
Cc: christoffer.dall, wanpengli, kvm, david, heiko.carstens, peterx,
linux-kernel, hpa, kvmarm, linux-s390, frankja, Marc Zyngier,
joro, x86, borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, linux-mips, sean.j.christopherson, james.morse,
pbonzini, Vitaly Kuznetsov, linuxppc-dev
In-Reply-To: <20200416105019.51191d79.cohuck@redhat.com>
On 2020/4/16 16:50, Cornelia Huck wrote:
> On Thu, 16 Apr 2020 16:45:33 +0800
> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> wrote:
>
>> On 2020/4/16 16:28, Marc Zyngier wrote:
>>> On 2020-04-16 08:03, Vitaly Kuznetsov wrote:
>>>> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> writes:
>>>>
>>>>> In earlier versions of kvm, 'kvm_run' is an independent structure
>>>>> and is not included in the vcpu structure. At present, 'kvm_run'
>>>>> is already included in the vcpu structure, so the parameter
>>>>> 'kvm_run' is redundant.
>>>>>
>>>>> This patch simplify the function definition, removes the extra
>>>>> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure
>>>>> if necessary.
>>>>>
>>>>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>>>>> ---
>>>>>
>>>>> v2 change:
>>>>> remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
>>>>>
>>>>> arch/mips/kvm/mips.c | 3 ++-
>>>>> arch/powerpc/kvm/powerpc.c | 3 ++-
>>>>> arch/s390/kvm/kvm-s390.c | 3 ++-
>>>>> arch/x86/kvm/x86.c | 11 ++++++-----
>>>>> include/linux/kvm_host.h | 2 +-
>>>>> virt/kvm/arm/arm.c | 6 +++---
>>>>> virt/kvm/kvm_main.c | 2 +-
>>>>> 7 files changed, 17 insertions(+), 13 deletions(-)
>
>>> Overall, there is a large set of cleanups to be done when both the vcpu
>>> and the run
>>> structures are passed as parameters at the same time. Just grepping the
>>> tree for
>>> kvm_run is pretty instructive.
>>>
>>> M.
>>
>> Sorry, it's my mistake, I only compiled the x86 platform, I will submit
>> patch again.
>
> I think it's completely fine (and even preferable) to do cleanups like
> that on top.
>
> [FWIW, I compiled s390 here.]
>
Very good, I will do a comprehensive cleanup of this type of code.
Thanks,
Tianjia
^ permalink raw reply
* Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function
From: Marc Zyngier @ 2020-04-16 8:58 UTC (permalink / raw)
To: Tianjia Zhang
Cc: christoffer.dall, wanpengli, kvm, david, heiko.carstens, peterx,
linux-kernel, hpa, kvmarm, linux-s390, frankja, joro, x86,
borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, cohuck, linux-mips, sean.j.christopherson, james.morse,
pbonzini, Vitaly Kuznetsov, linuxppc-dev
In-Reply-To: <8b92fb5b-5138-0695-fb90-6c36b8dfad00@linux.alibaba.com>
On 2020-04-16 09:45, Tianjia Zhang wrote:
> On 2020/4/16 16:28, Marc Zyngier wrote:
[...]
>> Overall, there is a large set of cleanups to be done when both the
>> vcpu and the run
>> structures are passed as parameters at the same time. Just grepping
>> the tree for
>> kvm_run is pretty instructive.
>>
>> M.
>
> Sorry, it's my mistake, I only compiled the x86 platform, I will
> submit patch again.
Not a mistake. All I'm saying is that there is an opportunity for a
larger
series that cleans up the code base, rather than just doing a couple of
localized changes.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function
From: Tianjia Zhang @ 2020-04-16 8:45 UTC (permalink / raw)
To: Marc Zyngier, Vitaly Kuznetsov
Cc: christoffer.dall, wanpengli, kvm, david, heiko.carstens, peterx,
linux-kernel, hpa, kvmarm, linux-s390, frankja, joro, x86,
borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, cohuck, linux-mips, sean.j.christopherson, james.morse,
pbonzini, linuxppc-dev
In-Reply-To: <1000159f971a6fa3b5bd9e5871ce4d82@kernel.org>
On 2020/4/16 16:28, Marc Zyngier wrote:
> On 2020-04-16 08:03, Vitaly Kuznetsov wrote:
>> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> writes:
>>
>>> In earlier versions of kvm, 'kvm_run' is an independent structure
>>> and is not included in the vcpu structure. At present, 'kvm_run'
>>> is already included in the vcpu structure, so the parameter
>>> 'kvm_run' is redundant.
>>>
>>> This patch simplify the function definition, removes the extra
>>> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure
>>> if necessary.
>>>
>>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>>> ---
>>>
>>> v2 change:
>>> remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
>>>
>>> arch/mips/kvm/mips.c | 3 ++-
>>> arch/powerpc/kvm/powerpc.c | 3 ++-
>>> arch/s390/kvm/kvm-s390.c | 3 ++-
>>> arch/x86/kvm/x86.c | 11 ++++++-----
>>> include/linux/kvm_host.h | 2 +-
>>> virt/kvm/arm/arm.c | 6 +++---
>>> virt/kvm/kvm_main.c | 2 +-
>>> 7 files changed, 17 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
>>> index 8f05dd0a0f4e..ec24adf4857e 100644
>>> --- a/arch/mips/kvm/mips.c
>>> +++ b/arch/mips/kvm/mips.c
>>> @@ -439,8 +439,9 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct
>>> kvm_vcpu *vcpu,
>>> return -ENOIOCTLCMD;
>>> }
>>>
>>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>>> {
>>> + struct kvm_run *run = vcpu->run;
>>> int r = -EINTR;
>>>
>>> vcpu_load(vcpu);
>>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>>> index e15166b0a16d..7e24691e138a 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>> @@ -1764,8 +1764,9 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu
>>> *vcpu, struct kvm_one_reg *reg)
>>> return r;
>>> }
>>>
>>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>>> {
>>> + struct kvm_run *run = vcpu->run;
>>> int r;
>>>
>>> vcpu_load(vcpu);
>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>> index 19a81024fe16..443af3ead739 100644
>>> --- a/arch/s390/kvm/kvm-s390.c
>>> +++ b/arch/s390/kvm/kvm-s390.c
>>> @@ -4333,8 +4333,9 @@ static void store_regs(struct kvm_vcpu *vcpu,
>>> struct kvm_run *kvm_run)
>>> store_regs_fmt2(vcpu, kvm_run);
>>> }
>>>
>>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>>> *kvm_run)
>>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>>> {
>>> + struct kvm_run *kvm_run = vcpu->run;
>>> int rc;
>>>
>>> if (kvm_run->immediate_exit)
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 3bf2ecafd027..a0338e86c90f 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -8707,8 +8707,9 @@ static void kvm_put_guest_fpu(struct kvm_vcpu
>>> *vcpu)
>>> trace_kvm_fpu(0);
>>> }
>>>
>>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>>> *kvm_run)
>>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>>> {
>>> + struct kvm_run *kvm_run = vcpu->run;
>>> int r;
>>>
>>> vcpu_load(vcpu);
>>> @@ -8726,18 +8727,18 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>>> *vcpu, struct kvm_run *kvm_run)
>>> r = -EAGAIN;
>>> if (signal_pending(current)) {
>>> r = -EINTR;
>>> - vcpu->run->exit_reason = KVM_EXIT_INTR;
>>> + kvm_run->exit_reason = KVM_EXIT_INTR;
>>> ++vcpu->stat.signal_exits;
>>> }
>>> goto out;
>>> }
>>>
>>> - if (vcpu->run->kvm_valid_regs & ~KVM_SYNC_X86_VALID_FIELDS) {
>>> + if (kvm_run->kvm_valid_regs & ~KVM_SYNC_X86_VALID_FIELDS) {
>>> r = -EINVAL;
>>> goto out;
>>> }
>>>
>>> - if (vcpu->run->kvm_dirty_regs) {
>>> + if (kvm_run->kvm_dirty_regs) {
>>> r = sync_regs(vcpu);
>>> if (r != 0)
>>> goto out;
>>> @@ -8767,7 +8768,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>>> *vcpu, struct kvm_run *kvm_run)
>>>
>>> out:
>>> kvm_put_guest_fpu(vcpu);
>>> - if (vcpu->run->kvm_valid_regs)
>>> + if (kvm_run->kvm_valid_regs)
>>> store_regs(vcpu);
>>> post_kvm_run_save(vcpu);
>>> kvm_sigset_deactivate(vcpu);
>>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>>> index 6d58beb65454..1e17ef719595 100644
>>> --- a/include/linux/kvm_host.h
>>> +++ b/include/linux/kvm_host.h
>>> @@ -866,7 +866,7 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct
>>> kvm_vcpu *vcpu,
>>> struct kvm_mp_state *mp_state);
>>> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>>> struct kvm_guest_debug *dbg);
>>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>>> *kvm_run);
>>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu);
>>>
>>> int kvm_arch_init(void *opaque);
>>> void kvm_arch_exit(void);
>>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>>> index 48d0ec44ad77..f5390ac2165b 100644
>>> --- a/virt/kvm/arm/arm.c
>>> +++ b/virt/kvm/arm/arm.c
>>> @@ -639,7 +639,6 @@ static void check_vcpu_requests(struct kvm_vcpu
>>> *vcpu)
>>> /**
>>> * kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute
>>> guest code
>>> * @vcpu: The VCPU pointer
>>> - * @run: The kvm_run structure pointer used for userspace state
>>> exchange
>>> *
>>> * This function is called through the VCPU_RUN ioctl called from
>>> user space. It
>>> * will execute VM code in a loop until the time slice for the
>>> process is used
>>> @@ -647,8 +646,9 @@ static void check_vcpu_requests(struct kvm_vcpu
>>> *vcpu)
>>> * return with return value 0 and with the kvm_run structure filled
>>> in with the
>>> * required data for the requested emulation.
>>> */
>>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>>> {
>>> + struct kvm_run *run = vcpu->run;
>>> int ret;
>>>
>>> if (unlikely(!kvm_vcpu_initialized(vcpu)))
>>> @@ -659,7 +659,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>>> *vcpu, struct kvm_run *run)
>>> return ret;
>>>
>>> if (run->exit_reason == KVM_EXIT_MMIO) {
>>> - ret = kvm_handle_mmio_return(vcpu, vcpu->run);
>>> + ret = kvm_handle_mmio_return(vcpu, run);
>>
>> I don't know much about ARM but this also seems redundant,
>> kvm_handle_mmio_return() is also able to extruct 'struct kvm_run' from'
>> 'struct kvm_vcpu'. This likely deserves it's own patch though.
>
> Something like this (untested):
>
> diff --git a/arch/arm64/include/asm/kvm_host.h
> b/arch/arm64/include/asm/kvm_host.h
> index 32c8a675e5a4..82978995bdd6 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -490,7 +490,7 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct
> kvm_run *run,
> void kvm_mmio_write_buf(void *buf, unsigned int len, unsigned long data);
> unsigned long kvm_mmio_read_buf(const void *buf, unsigned int len);
>
> -int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_handle_mmio_return(struct kvm_vcpu *vcpu);
> int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
> phys_addr_t fault_ipa);
>
> diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
> index 4e0366759726..3b2c822b4859 100644
> --- a/virt/kvm/arm/mmio.c
> +++ b/virt/kvm/arm/mmio.c
> @@ -77,9 +77,8 @@ unsigned long kvm_mmio_read_buf(const void *buf,
> unsigned int len)
> * or in-kernel IO emulation
> *
> * @vcpu: The VCPU pointer
> - * @run: The VCPU run struct containing the mmio data
> */
> -int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
> {
> unsigned long data;
> unsigned int len;
> @@ -93,7 +92,7 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu,
> struct kvm_run *run)
>
> if (!kvm_vcpu_dabt_iswrite(vcpu)) {
> len = kvm_vcpu_dabt_get_as(vcpu);
> - data = kvm_mmio_read_buf(run->mmio.data, len);
> + data = kvm_mmio_read_buf(vcpu->run->mmio.data, len);
>
> if (kvm_vcpu_dabt_issext(vcpu) &&
> len < sizeof(unsigned long)) {
> @@ -104,7 +103,8 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu,
> struct kvm_run *run)
> if (!kvm_vcpu_dabt_issf(vcpu))
> data = data & 0xffffffff;
>
> - trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
> + trace_kvm_mmio(KVM_TRACE_MMIO_READ, len,
> + vcpu->run->mmio.phys_addr,
> &data);
> data = vcpu_data_host_to_guest(vcpu, data, len);
> vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
>
> Overall, there is a large set of cleanups to be done when both the vcpu
> and the run
> structures are passed as parameters at the same time. Just grepping the
> tree for
> kvm_run is pretty instructive.
>
> M.
Sorry, it's my mistake, I only compiled the x86 platform, I will submit
patch again.
Thanks,
Tianjia
^ permalink raw reply
* [PATCH v3, 3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416074918.3617-1-wenhu.wang@vivo.com>
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Warning information:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram()
The function mpc85xx_l2ctlr_of_probe() references
the function __init instantiate_cache_sram().
This is often because mpc85xx_l2ctlr_of_probe lacks a __init
annotation or the annotation of instantiate_cache_sram is wrong.
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index be3aef4229d7..3de5ac8382c0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
}
EXPORT_SYMBOL(mpc85xx_cache_sram_free);
-int __init instantiate_cache_sram(struct platform_device *dev,
+int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params)
{
int ret = 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v3,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416074918.3617-1-wenhu.wang@vivo.com>
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@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calculation
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
---
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++++++
3 files changed, 168 insertions(+)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81cfc2b..9c3b47461b71 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -105,6 +105,15 @@ 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_SOC_BOOKE && PPC32
+ select 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..8701df695307
--- /dev/null
+++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
+ * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.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_INFO_VER "devicetree,pseudo"
+#define UIO_NAME "uio_cache_sram"
+
+static void uio_info_free_internal(struct uio_info *info)
+{
+ struct uio_mem *uiomem = info->mem;
+
+ while (uiomem < &info->mem[MAX_UIO_MAPS]) {
+ if (uiomem->internal_addr) {
+ mpc85xx_cache_sram_free(uiomem->internal_addr);
+ kfree(uiomem->name);
+ memset(uiomem, 0, sizeof(*uiomem));
+ }
+ 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;
+ int ret;
+
+ /* alloc uio_info for one device */
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ 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;
+ for_each_child_of_node(parent, node) {
+ void *virt;
+ phys_addr_t phys;
+
+ ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
+ if (ret) {
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ if (mem_size == 0) {
+ dev_err(&pdev->dev, "cache-mem-size should not be 0\n");
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ virt = mpc85xx_cache_sram_alloc(mem_size,
+ &phys,
+ roundup_pow_of_two(mem_size));
+ if (!virt) {
+ /* mpc85xx_cache_sram_alloc to define the real cause */
+ ret = -ENOMEM;
+ goto err_info_free_internal;
+ }
+
+ 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, "more than %d uio-maps for device.\n",
+ MAX_UIO_MAPS);
+ break;
+ }
+ }
+
+ if (uiomem == info->mem) {
+ dev_err(&pdev->dev, "error no valid uio-map configured\n");
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ info->version = UIO_INFO_VER;
+
+ /* register uio device */
+ if (uio_register_device(&pdev->dev, info)) {
+ dev_err(&pdev->dev, "uio registration failed\n");
+ ret = -ENODEV;
+ goto err_info_free_internal;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ return 0;
+err_info_free_internal:
+ uio_info_free_internal(info);
+err_info_free:
+ kfree(info);
+ 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 const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
+ { .compatible = "uio,mpc85xx-cache-sram", },
+ {},
+};
+
+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@vivo.com>");
+MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v3,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200415152442.122873-1-wenhu.wang@vivo.com>
This series add a new uio driver for freescale 85xx platforms to
access the Cache-Sram form user level. This is extremely helpful
for the user-space applications that require high performance memory
accesses.
It fixes the compile errors and warning of the hardware level drivers
and implements the uio driver in uio_fsl_85xx_cache_sram.c.
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Drop the patch that modifies Kconfigs of arch/powerpc/platforms
and modified the sequence of patches:
01:dropped, 02->03, 03->02, 04->01, 05->04
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
Wang Wenhu (4):
powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
drivers: uio: new driver for fsl_85xx_cache_sram
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++
5 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
--
2.17.1
^ permalink raw reply
* [PATCH v3, 2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416074918.3617-1-wenhu.wang@vivo.com>
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^~~~~~~~~~~~~~~~
bitmap_complement
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration]
iounmap(cache_sram->base_virt);
^~~~~~~
roundup
cc1: all warnings being treated as errors
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index f6c665dac725..be3aef4229d7 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <asm/pgtable.h>
#include <asm/fsl_85xx_cache_sram.h>
+#include <linux/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH v3, 1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
From: Wang Wenhu @ 2020-04-16 7:49 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416074918.3617-1-wenhu.wang@vivo.com>
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^~~~~~~~
pci_iomap
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 2d0af0c517bb..7533572492f0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/of_address.h>
#include <asm/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] KVM: Optimize kvm_arch_vcpu_ioctl_run function
From: Marc Zyngier @ 2020-04-16 8:28 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: christoffer.dall, wanpengli, kvm, david, heiko.carstens, peterx,
linux-kernel, hpa, kvmarm, linux-s390, frankja, joro, x86,
borntraeger, mingo, julien.thierry.kdev, thuth, gor,
suzuki.poulose, kvm-ppc, bp, tglx, linux-arm-kernel, jmattson,
tsbogend, Tianjia Zhang, cohuck, linux-mips,
sean.j.christopherson, james.morse, pbonzini, linuxppc-dev
In-Reply-To: <878sivx67g.fsf@vitty.brq.redhat.com>
On 2020-04-16 08:03, Vitaly Kuznetsov wrote:
> Tianjia Zhang <tianjia.zhang@linux.alibaba.com> writes:
>
>> In earlier versions of kvm, 'kvm_run' is an independent structure
>> and is not included in the vcpu structure. At present, 'kvm_run'
>> is already included in the vcpu structure, so the parameter
>> 'kvm_run' is redundant.
>>
>> This patch simplify the function definition, removes the extra
>> 'kvm_run' parameter, and extract it from the 'kvm_vcpu' structure
>> if necessary.
>>
>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>> ---
>>
>> v2 change:
>> remove 'kvm_run' parameter and extract it from 'kvm_vcpu'
>>
>> arch/mips/kvm/mips.c | 3 ++-
>> arch/powerpc/kvm/powerpc.c | 3 ++-
>> arch/s390/kvm/kvm-s390.c | 3 ++-
>> arch/x86/kvm/x86.c | 11 ++++++-----
>> include/linux/kvm_host.h | 2 +-
>> virt/kvm/arm/arm.c | 6 +++---
>> virt/kvm/kvm_main.c | 2 +-
>> 7 files changed, 17 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
>> index 8f05dd0a0f4e..ec24adf4857e 100644
>> --- a/arch/mips/kvm/mips.c
>> +++ b/arch/mips/kvm/mips.c
>> @@ -439,8 +439,9 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct
>> kvm_vcpu *vcpu,
>> return -ENOIOCTLCMD;
>> }
>>
>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>> *run)
>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> {
>> + struct kvm_run *run = vcpu->run;
>> int r = -EINTR;
>>
>> vcpu_load(vcpu);
>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index e15166b0a16d..7e24691e138a 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -1764,8 +1764,9 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu
>> *vcpu, struct kvm_one_reg *reg)
>> return r;
>> }
>>
>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>> *run)
>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> {
>> + struct kvm_run *run = vcpu->run;
>> int r;
>>
>> vcpu_load(vcpu);
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 19a81024fe16..443af3ead739 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -4333,8 +4333,9 @@ static void store_regs(struct kvm_vcpu *vcpu,
>> struct kvm_run *kvm_run)
>> store_regs_fmt2(vcpu, kvm_run);
>> }
>>
>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>> *kvm_run)
>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> {
>> + struct kvm_run *kvm_run = vcpu->run;
>> int rc;
>>
>> if (kvm_run->immediate_exit)
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 3bf2ecafd027..a0338e86c90f 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -8707,8 +8707,9 @@ static void kvm_put_guest_fpu(struct kvm_vcpu
>> *vcpu)
>> trace_kvm_fpu(0);
>> }
>>
>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>> *kvm_run)
>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> {
>> + struct kvm_run *kvm_run = vcpu->run;
>> int r;
>>
>> vcpu_load(vcpu);
>> @@ -8726,18 +8727,18 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>> *vcpu, struct kvm_run *kvm_run)
>> r = -EAGAIN;
>> if (signal_pending(current)) {
>> r = -EINTR;
>> - vcpu->run->exit_reason = KVM_EXIT_INTR;
>> + kvm_run->exit_reason = KVM_EXIT_INTR;
>> ++vcpu->stat.signal_exits;
>> }
>> goto out;
>> }
>>
>> - if (vcpu->run->kvm_valid_regs & ~KVM_SYNC_X86_VALID_FIELDS) {
>> + if (kvm_run->kvm_valid_regs & ~KVM_SYNC_X86_VALID_FIELDS) {
>> r = -EINVAL;
>> goto out;
>> }
>>
>> - if (vcpu->run->kvm_dirty_regs) {
>> + if (kvm_run->kvm_dirty_regs) {
>> r = sync_regs(vcpu);
>> if (r != 0)
>> goto out;
>> @@ -8767,7 +8768,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>> *vcpu, struct kvm_run *kvm_run)
>>
>> out:
>> kvm_put_guest_fpu(vcpu);
>> - if (vcpu->run->kvm_valid_regs)
>> + if (kvm_run->kvm_valid_regs)
>> store_regs(vcpu);
>> post_kvm_run_save(vcpu);
>> kvm_sigset_deactivate(vcpu);
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index 6d58beb65454..1e17ef719595 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -866,7 +866,7 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct
>> kvm_vcpu *vcpu,
>> struct kvm_mp_state *mp_state);
>> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>> struct kvm_guest_debug *dbg);
>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>> *kvm_run);
>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu);
>>
>> int kvm_arch_init(void *opaque);
>> void kvm_arch_exit(void);
>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> index 48d0ec44ad77..f5390ac2165b 100644
>> --- a/virt/kvm/arm/arm.c
>> +++ b/virt/kvm/arm/arm.c
>> @@ -639,7 +639,6 @@ static void check_vcpu_requests(struct kvm_vcpu
>> *vcpu)
>> /**
>> * kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute
>> guest code
>> * @vcpu: The VCPU pointer
>> - * @run: The kvm_run structure pointer used for userspace state
>> exchange
>> *
>> * This function is called through the VCPU_RUN ioctl called from
>> user space. It
>> * will execute VM code in a loop until the time slice for the
>> process is used
>> @@ -647,8 +646,9 @@ static void check_vcpu_requests(struct kvm_vcpu
>> *vcpu)
>> * return with return value 0 and with the kvm_run structure filled
>> in with the
>> * required data for the requested emulation.
>> */
>> -int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
>> *run)
>> +int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>> {
>> + struct kvm_run *run = vcpu->run;
>> int ret;
>>
>> if (unlikely(!kvm_vcpu_initialized(vcpu)))
>> @@ -659,7 +659,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
>> struct kvm_run *run)
>> return ret;
>>
>> if (run->exit_reason == KVM_EXIT_MMIO) {
>> - ret = kvm_handle_mmio_return(vcpu, vcpu->run);
>> + ret = kvm_handle_mmio_return(vcpu, run);
>
> I don't know much about ARM but this also seems redundant,
> kvm_handle_mmio_return() is also able to extruct 'struct kvm_run' from'
> 'struct kvm_vcpu'. This likely deserves it's own patch though.
Something like this (untested):
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 32c8a675e5a4..82978995bdd6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -490,7 +490,7 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct
kvm_run *run,
void kvm_mmio_write_buf(void *buf, unsigned int len, unsigned long
data);
unsigned long kvm_mmio_read_buf(const void *buf, unsigned int len);
-int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_mmio_return(struct kvm_vcpu *vcpu);
int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
phys_addr_t fault_ipa);
diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
index 4e0366759726..3b2c822b4859 100644
--- a/virt/kvm/arm/mmio.c
+++ b/virt/kvm/arm/mmio.c
@@ -77,9 +77,8 @@ unsigned long kvm_mmio_read_buf(const void *buf,
unsigned int len)
* or in-kernel IO emulation
*
* @vcpu: The VCPU pointer
- * @run: The VCPU run struct containing the mmio data
*/
-int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run)
+int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
{
unsigned long data;
unsigned int len;
@@ -93,7 +92,7 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu,
struct kvm_run *run)
if (!kvm_vcpu_dabt_iswrite(vcpu)) {
len = kvm_vcpu_dabt_get_as(vcpu);
- data = kvm_mmio_read_buf(run->mmio.data, len);
+ data = kvm_mmio_read_buf(vcpu->run->mmio.data, len);
if (kvm_vcpu_dabt_issext(vcpu) &&
len < sizeof(unsigned long)) {
@@ -104,7 +103,8 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu,
struct kvm_run *run)
if (!kvm_vcpu_dabt_issf(vcpu))
data = data & 0xffffffff;
- trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
+ trace_kvm_mmio(KVM_TRACE_MMIO_READ, len,
+ vcpu->run->mmio.phys_addr,
&data);
data = vcpu_data_host_to_guest(vcpu, data, len);
vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
Overall, there is a large set of cleanups to be done when both the vcpu
and the run
structures are passed as parameters at the same time. Just grepping the
tree for
kvm_run is pretty instructive.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH v2] papr/scm: Add bad memory ranges to nvdimm bad ranges
From: Santosh Sivaraj @ 2020-04-16 8:24 UTC (permalink / raw)
To: linuxppc-dev
Cc: Oliver, Santosh Sivaraj, Mahesh Salgaonkar, Ganesh Goudar,
Aneesh Kumar K.V, Vaibhav Jain
Subscribe to the MCE notification and add the physical address which
generated a memory error to nvdimm bad range.
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
---
arch/powerpc/platforms/pseries/papr_scm.c | 98 ++++++++++++++++++++++-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f35592423380..e23fd1399d5b 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -12,6 +12,8 @@
#include <linux/libnvdimm.h>
#include <linux/platform_device.h>
#include <linux/delay.h>
+#include <linux/nd.h>
+#include <asm/mce.h>
#include <asm/plpar_wrappers.h>
@@ -39,8 +41,12 @@ struct papr_scm_priv {
struct resource res;
struct nd_region *region;
struct nd_interleave_set nd_set;
+ struct list_head region_list;
};
+LIST_HEAD(papr_nd_regions);
+DEFINE_MUTEX(papr_ndr_lock);
+
static int drc_pmem_bind(struct papr_scm_priv *p)
{
unsigned long ret[PLPAR_HCALL_BUFSIZE];
@@ -356,6 +362,10 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
dev_info(dev, "Region registered with target node %d and online node %d",
target_nid, online_nid);
+ mutex_lock(&papr_ndr_lock);
+ list_add_tail(&p->region_list, &papr_nd_regions);
+ mutex_unlock(&papr_ndr_lock);
+
return 0;
err: nvdimm_bus_unregister(p->bus);
@@ -363,6 +373,70 @@ err: nvdimm_bus_unregister(p->bus);
return -ENXIO;
}
+void papr_scm_add_badblock(struct nd_region *region, struct nvdimm_bus *bus,
+ u64 phys_addr)
+{
+ u64 aligned_addr = ALIGN_DOWN(phys_addr, L1_CACHE_BYTES);
+
+ if (nvdimm_bus_add_badrange(bus, aligned_addr, L1_CACHE_BYTES)) {
+ pr_err("Bad block registration for 0x%llx failed\n", phys_addr);
+ return;
+ }
+
+ pr_debug("Add memory range (0x%llx - 0x%llx) as bad range\n",
+ aligned_addr, aligned_addr + L1_CACHE_BYTES);
+
+ nvdimm_region_notify(region, NVDIMM_REVALIDATE_POISON);
+}
+
+static int handle_mce_ue(struct notifier_block *nb, unsigned long val,
+ void *data)
+{
+ struct machine_check_event *evt = data;
+ struct papr_scm_priv *p;
+ u64 phys_addr;
+ bool found = false;
+
+ if (evt->error_type != MCE_ERROR_TYPE_UE)
+ return NOTIFY_DONE;
+
+ if (list_empty(&papr_nd_regions))
+ return NOTIFY_DONE;
+
+ /*
+ * The physical address obtained here is PAGE_SIZE aligned, so get the
+ * exact address from the effective address
+ */
+ phys_addr = evt->u.ue_error.physical_address +
+ (evt->u.ue_error.effective_address & ~PAGE_MASK);
+
+ if (!evt->u.ue_error.physical_address_provided ||
+ !is_zone_device_page(pfn_to_page(phys_addr >> PAGE_SHIFT)))
+ return NOTIFY_DONE;
+
+ /* mce notifier is called from a process context, so mutex is safe */
+ mutex_lock(&papr_ndr_lock);
+ list_for_each_entry(p, &papr_nd_regions, region_list) {
+ struct resource res = p->res;
+
+ if (phys_addr >= res.start && phys_addr <= res.end) {
+ found = true;
+ break;
+ }
+ }
+
+ if (found)
+ papr_scm_add_badblock(p->region, p->bus, phys_addr);
+
+ mutex_unlock(&papr_ndr_lock);
+
+ return found ? NOTIFY_OK : NOTIFY_DONE;
+}
+
+static struct notifier_block mce_ue_nb = {
+ .notifier_call = handle_mce_ue
+};
+
static int papr_scm_probe(struct platform_device *pdev)
{
struct device_node *dn = pdev->dev.of_node;
@@ -460,6 +534,10 @@ static int papr_scm_remove(struct platform_device *pdev)
{
struct papr_scm_priv *p = platform_get_drvdata(pdev);
+ mutex_lock(&papr_ndr_lock);
+ list_del(&(p->region_list));
+ mutex_unlock(&papr_ndr_lock);
+
nvdimm_bus_unregister(p->bus);
drc_pmem_unbind(p);
kfree(p->bus_desc.provider_name);
@@ -482,7 +560,25 @@ static struct platform_driver papr_scm_driver = {
},
};
-module_platform_driver(papr_scm_driver);
+static int __init papr_scm_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&papr_scm_driver);
+ if (!ret)
+ mce_register_notifier(&mce_ue_nb);
+
+ return ret;
+}
+module_init(papr_scm_init);
+
+static void __exit papr_scm_exit(void)
+{
+ mce_unregister_notifier(&mce_ue_nb);
+ platform_driver_unregister(&papr_scm_driver);
+}
+module_exit(papr_scm_exit);
+
MODULE_DEVICE_TABLE(of, papr_scm_match);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("IBM Corporation");
--
2.25.2
^ permalink raw reply related
* [PATCH v3,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416074141.3555-1-wenhu.wang@vivo.com>
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@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calculation
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
---
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 158 ++++++++++++++++++++++++++
3 files changed, 168 insertions(+)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81cfc2b..9c3b47461b71 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -105,6 +105,15 @@ 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_SOC_BOOKE && PPC32
+ select 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..8701df695307
--- /dev/null
+++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
+ * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.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_INFO_VER "devicetree,pseudo"
+#define UIO_NAME "uio_cache_sram"
+
+static void uio_info_free_internal(struct uio_info *info)
+{
+ struct uio_mem *uiomem = info->mem;
+
+ while (uiomem < &info->mem[MAX_UIO_MAPS]) {
+ if (uiomem->internal_addr) {
+ mpc85xx_cache_sram_free(uiomem->internal_addr);
+ kfree(uiomem->name);
+ memset(uiomem, 0, sizeof(*uiomem));
+ }
+ 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;
+ int ret;
+
+ /* alloc uio_info for one device */
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
+ 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;
+ for_each_child_of_node(parent, node) {
+ void *virt;
+ phys_addr_t phys;
+
+ ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
+ if (ret) {
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ if (mem_size == 0) {
+ dev_err(&pdev->dev, "cache-mem-size should not be 0\n");
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ virt = mpc85xx_cache_sram_alloc(mem_size,
+ &phys,
+ roundup_pow_of_two(mem_size));
+ if (!virt) {
+ /* mpc85xx_cache_sram_alloc to define the real cause */
+ ret = -ENOMEM;
+ goto err_info_free_internal;
+ }
+
+ 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, "more than %d uio-maps for device.\n",
+ MAX_UIO_MAPS);
+ break;
+ }
+ }
+
+ if (uiomem == info->mem) {
+ dev_err(&pdev->dev, "error no valid uio-map configured\n");
+ ret = -EINVAL;
+ goto err_info_free_internal;
+ }
+
+ info->version = UIO_INFO_VER;
+
+ /* register uio device */
+ if (uio_register_device(&pdev->dev, info)) {
+ dev_err(&pdev->dev, "uio registration failed\n");
+ ret = -ENODEV;
+ goto err_info_free_internal;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ return 0;
+err_info_free_internal:
+ uio_info_free_internal(info);
+err_info_free:
+ kfree(info);
+ 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 const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
+ { .compatible = "uio,mpc85xx-cache-sram", },
+ {},
+};
+
+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@vivo.com>");
+MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v3, 3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 7:41 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416074141.3555-1-wenhu.wang@vivo.com>
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Warning information:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram()
The function mpc85xx_l2ctlr_of_probe() references
the function __init instantiate_cache_sram().
This is often because mpc85xx_l2ctlr_of_probe lacks a __init
annotation or the annotation of instantiate_cache_sram is wrong.
---
Changes since v1:
* None
Changes since v2:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index be3aef4229d7..3de5ac8382c0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
}
EXPORT_SYMBOL(mpc85xx_cache_sram_free);
-int __init instantiate_cache_sram(struct platform_device *dev,
+int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params)
{
int ret = 0;
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox