* [PATCH -next 01/12] crypto: artpec6 - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:27 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/axis/artpec6_crypto.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/axis/artpec6_crypto.c b/drivers/crypto/axis/artpec6_crypto.c
index 80fa04e..4b20606 100644
--- a/drivers/crypto/axis/artpec6_crypto.c
+++ b/drivers/crypto/axis/artpec6_crypto.c
@@ -2854,7 +2854,6 @@ static int artpec6_crypto_probe(struct platform_device *pdev)
struct artpec6_crypto *ac;
struct device *dev = &pdev->dev;
void __iomem *base;
- struct resource *res;
int irq;
int err;
@@ -2867,8 +2866,7 @@ static int artpec6_crypto_probe(struct platform_device *pdev)
variant = (enum artpec6_crypto_variant)match->data;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 03/12] crypto: exynos - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/exynos-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/exynos-rng.c b/drivers/crypto/exynos-rng.c
index 2cfabb9..cbd8ca6 100644
--- a/drivers/crypto/exynos-rng.c
+++ b/drivers/crypto/exynos-rng.c
@@ -268,7 +268,6 @@ static struct rng_alg exynos_rng_alg = {
static int exynos_rng_probe(struct platform_device *pdev)
{
struct exynos_rng_dev *rng;
- struct resource *res;
int ret;
if (exynos_rng_dev)
@@ -289,8 +288,7 @@ static int exynos_rng_probe(struct platform_device *pdev)
return PTR_ERR(rng->clk);
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- rng->mem = devm_ioremap_resource(&pdev->dev, res);
+ rng->mem = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(rng->mem))
return PTR_ERR(rng->mem);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 02/12] crypto: ccp - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:27 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/ccp/sp-platform.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/ccp/sp-platform.c b/drivers/crypto/ccp/sp-platform.c
index 1b45236..831aac1 100644
--- a/drivers/crypto/ccp/sp-platform.c
+++ b/drivers/crypto/ccp/sp-platform.c
@@ -125,7 +125,6 @@ static int sp_platform_probe(struct platform_device *pdev)
struct sp_platform *sp_platform;
struct device *dev = &pdev->dev;
enum dev_dma_attr attr;
- struct resource *ior;
int ret;
ret = -ENOMEM;
@@ -146,8 +145,7 @@ static int sp_platform_probe(struct platform_device *pdev)
goto e_err;
}
- ior = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sp->io_map = devm_ioremap_resource(dev, ior);
+ sp->io_map = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(sp->io_map)) {
ret = PTR_ERR(sp->io_map);
goto e_err;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 04/12] crypto: img-hash - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/img-hash.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
index d27c812..f5a71fa 100644
--- a/drivers/crypto/img-hash.c
+++ b/drivers/crypto/img-hash.c
@@ -958,9 +958,7 @@ static int img_hash_probe(struct platform_device *pdev)
crypto_init_queue(&hdev->queue, IMG_HASH_QUEUE_LENGTH);
/* Register bank */
- hash_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- hdev->io_base = devm_ioremap_resource(dev, hash_res);
+ hdev->io_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hdev->io_base)) {
err = PTR_ERR(hdev->io_base);
dev_err(dev, "can't ioremap, returned %d\n", err);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 07/12] crypto: picoxcell - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/picoxcell_crypto.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index b985cb85..9a939b4 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1624,7 +1624,7 @@ MODULE_DEVICE_TABLE(of, spacc_of_id_table);
static int spacc_probe(struct platform_device *pdev)
{
int i, err, ret;
- struct resource *mem, *irq;
+ struct resource *irq;
struct device_node *np = pdev->dev.of_node;
struct spacc_engine *engine = devm_kzalloc(&pdev->dev, sizeof(*engine),
GFP_KERNEL);
@@ -1653,8 +1653,7 @@ static int spacc_probe(struct platform_device *pdev)
engine->name = dev_name(&pdev->dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- engine->regs = devm_ioremap_resource(&pdev->dev, mem);
+ engine->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(engine->regs))
return PTR_ERR(engine->regs);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 06/12] crypto: mediatek - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/mediatek/mtk-platform.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-platform.c b/drivers/crypto/mediatek/mtk-platform.c
index 125318a..12462136 100644
--- a/drivers/crypto/mediatek/mtk-platform.c
+++ b/drivers/crypto/mediatek/mtk-platform.c
@@ -481,7 +481,6 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
static int mtk_crypto_probe(struct platform_device *pdev)
{
- struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct mtk_cryp *cryp;
int i, err;
@@ -489,7 +488,7 @@ static int mtk_crypto_probe(struct platform_device *pdev)
if (!cryp)
return -ENOMEM;
- cryp->base = devm_ioremap_resource(&pdev->dev, res);
+ cryp->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(cryp->base))
return PTR_ERR(cryp->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 05/12] crypto: inside-secure - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/inside-secure/safexcel.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/inside-secure/safexcel.c b/drivers/crypto/inside-secure/safexcel.c
index d1f60fd..822744d 100644
--- a/drivers/crypto/inside-secure/safexcel.c
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -999,7 +999,6 @@ static void safexcel_init_register_offsets(struct safexcel_crypto_priv *priv)
static int safexcel_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct resource *res;
struct safexcel_crypto_priv *priv;
int i, ret;
@@ -1015,8 +1014,7 @@ static int safexcel_probe(struct platform_device *pdev)
safexcel_init_register_offsets(priv);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->base = devm_ioremap_resource(dev, res);
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->base)) {
dev_err(dev, "failed to get resource\n");
return PTR_ERR(priv->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 08/12] crypto: sunxi-ss - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 2e87042..9aa6fe0 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -225,7 +225,6 @@ static struct sun4i_ss_alg_template ss_algs[] = {
static int sun4i_ss_probe(struct platform_device *pdev)
{
- struct resource *res;
u32 v;
int err, i;
unsigned long cr;
@@ -240,8 +239,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
if (!ss)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- ss->base = devm_ioremap_resource(&pdev->dev, res);
+ ss->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(ss->base)) {
dev_err(&pdev->dev, "Cannot request MMIO\n");
return PTR_ERR(ss->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 09/12] crypto: rockchip - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/rockchip/rk3288_crypto.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c b/drivers/crypto/rockchip/rk3288_crypto.c
index 8d7e254..e5714ef 100644
--- a/drivers/crypto/rockchip/rk3288_crypto.c
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -311,7 +311,6 @@ MODULE_DEVICE_TABLE(of, crypto_of_id_table);
static int rk_crypto_probe(struct platform_device *pdev)
{
- struct resource *res;
struct device *dev = &pdev->dev;
struct rk_crypto_info *crypto_info;
int err = 0;
@@ -339,8 +338,7 @@ static int rk_crypto_probe(struct platform_device *pdev)
spin_lock_init(&crypto_info->lock);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- crypto_info->reg = devm_ioremap_resource(&pdev->dev, res);
+ crypto_info->reg = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(crypto_info->reg)) {
err = PTR_ERR(crypto_info->reg);
goto err_crypto;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 10/12] crypto: stm32 - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/stm32/stm32-crc32.c | 4 +---
drivers/crypto/stm32/stm32-cryp.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-crc32.c b/drivers/crypto/stm32/stm32-crc32.c
index 440c9f1..9e11c34 100644
--- a/drivers/crypto/stm32/stm32-crc32.c
+++ b/drivers/crypto/stm32/stm32-crc32.c
@@ -255,7 +255,6 @@ static int stm32_crc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct stm32_crc *crc;
- struct resource *res;
int ret;
crc = devm_kzalloc(dev, sizeof(*crc), GFP_KERNEL);
@@ -264,8 +263,7 @@ static int stm32_crc_probe(struct platform_device *pdev)
crc->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- crc->regs = devm_ioremap_resource(dev, res);
+ crc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(crc->regs)) {
dev_err(dev, "Cannot map CRC IO\n");
return PTR_ERR(crc->regs);
diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
index 98ae028..2fe6f26 100644
--- a/drivers/crypto/stm32/stm32-cryp.c
+++ b/drivers/crypto/stm32/stm32-cryp.c
@@ -1955,7 +1955,6 @@ static int stm32_cryp_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct stm32_cryp *cryp;
- struct resource *res;
struct reset_control *rst;
int irq, ret;
@@ -1969,8 +1968,7 @@ static int stm32_cryp_probe(struct platform_device *pdev)
cryp->dev = dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- cryp->regs = devm_ioremap_resource(dev, res);
+ cryp->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(cryp->regs))
return PTR_ERR(cryp->regs);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 11/12] crypto: qce - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/qce/core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index ef1d74e..08d4ce3 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -167,7 +167,6 @@ static int qce_crypto_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct qce_device *qce;
- struct resource *res;
int ret;
qce = devm_kzalloc(dev, sizeof(*qce), GFP_KERNEL);
@@ -177,8 +176,7 @@ static int qce_crypto_probe(struct platform_device *pdev)
qce->dev = dev;
platform_set_drvdata(pdev, qce);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- qce->base = devm_ioremap_resource(&pdev->dev, res);
+ qce->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(qce->base))
return PTR_ERR(qce->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH -next 12/12] crypto: qcom-rng - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:28 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/qcom-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index e54249c..4730f84 100644
--- a/drivers/crypto/qcom-rng.c
+++ b/drivers/crypto/qcom-rng.c
@@ -153,7 +153,6 @@ static struct rng_alg qcom_rng_alg = {
static int qcom_rng_probe(struct platform_device *pdev)
{
- struct resource *res;
struct qcom_rng *rng;
int ret;
@@ -164,8 +163,7 @@ static int qcom_rng_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, rng);
mutex_init(&rng->lock);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- rng->base = devm_ioremap_resource(&pdev->dev, res);
+ rng->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(rng->base))
return PTR_ERR(rng->base);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH v1 02/11] drm: drop uapi dependency from drm_print.h
From: Jani Nikula @ 2019-08-02 13:48 UTC (permalink / raw)
To: Sam Ravnborg, Koenig, Christian
Cc: Boris Brezillon, Maxime Ripard, Daniel Vetter,
Intel Graphics Development, dri-devel@lists.freedesktop.org,
David Airlie, linux-mediatek@lists.infradead.org,
Thomas Zimmermann, Matthias Brugger, Sean Paul, Thierry Reding,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190729175011.GA1753@ravnborg.org>
On Mon, 29 Jul 2019, Sam Ravnborg <sam@ravnborg.org> wrote:
> Hi Christian.
>
> On Mon, Jul 29, 2019 at 03:28:15PM +0000, Koenig, Christian wrote:
>> Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
>> >>>> Even then it so useless (which drm driver is this message for???) that I
>> >>>> want to remove them all :(
>> >>> Yeah, agree. I mean it is nice if the core drm functions use a prefix
>> >>> for debug output.
>> >>>
>> >>> But I actually don't see the point for individual drivers.
>> >> We should all migrate to the versions with device...
>> > Just to do an xkdc.com/927 I have considered:
>> >
>> > drm_err(const struct drm_device *drm, ...)
>> > drm_info(const struct drm_device *drm, ...)
>> >
>> > drm_kms_err(const struct drm_device *drm, ...)
>> > drm_kms_info(const struct drm_device *drm, ...))
>>
>> Why not get completely rid of those and just use dev_err, dev_warn,
>> pr_err, pr_warn etc?
>>
>> I mean is it useful to have this extra printing subsystem in DRM while
>> the standard Linux one actually does a better job?
> The added functionality of drm_xxx_err would be to keep the current
> drm.debug=0x1f filtering on the command-line.
> I do not think we can do this with the standard logging.
Correct. I'd love the benefits of dynamic debug, but there's no support
for the kind of message categories that we do with drm.debug.
I've contemplated switching i915 over to using the variants where you
pass the device, but I really really don't like the idea of:
- DRM_DEBUG_KMS("hello\n");
+ DRM_DEV_DEBUG_KMS(i915->drm.dev, "hello\n");
Where i915 is our private wrapper for drm_device. I think it's just too
much ugly uppercase boilerplate, and a large portion of the debugs would
have to span at least an extra line after that.
I'd also very much prefer passing just struct *drm_device instead of
struct *device. In that, I think the needs of the few have prevailed
over the needs of the many. I'd definitely prefer drm_err(const struct
drm_device *drm, ...) and friends over the current ones.
Frankly, I've actually ended up thinking about adding our own, short
i915 wrappers for our needs. :(
BR,
Jani.
>
> And then we can prefix every logging with driver name and device name.
>
> The idea is to make a thin layer on top of the existing pr_xxx() functions.
> So not a full subsystem, only a wrapper on top of what we already have.
>
> Anyway, idle talk only. We need patches and sample output if we should
> discuss more.
>
> Sam
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: topology: Use PPTT to determine if PE is a thread
From: Robert Richter @ 2019-08-02 13:44 UTC (permalink / raw)
To: Jeremy Linton
Cc: lorenzo.pieralisi, catalin.marinas, rjw, linux-acpi, sudeep.holla,
will, linux-arm-kernel, lenb
In-Reply-To: <20190801034634.26913-3-jeremy.linton@arm.com>
On 31.07.19 22:46:34, Jeremy Linton wrote:
> @@ -358,6 +356,10 @@ static int __init parse_acpi_topology(void)
> if (topology_id < 0)
> return topology_id;
>
> + is_threaded = acpi_pptt_cpu_is_thread(cpu);
> + if (is_threaded < 0)
> + is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
> +
I think the return code handling is error-prone, as in the kernel such
functions are typically used like:
if (something_is_thread) { ... }
I see this is due to acpi and arch code separation so we cannot simply
move the fallback to pptt code.
So maybe we have a static function cpu_is_thread() in this file that
handles all the logic and directly use check_acpi_cpu_flag() from
there. However, code may change here in case of a rework as I
suggested in patch #1. In both cases the acpi api is more straight
then.
-Robert
> if (is_threaded) {
> cpu_topology[cpu].thread_id = topology_id;
> topology_id = find_acpi_cpu_topology(cpu, 1);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: stm32: move ltdc pinctrl on stm32mp157a dk1 board
From: Yannick Fertré @ 2019-08-02 14:08 UTC (permalink / raw)
To: Maxime Coquelin, Alexandre Torgue, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Yannick Fertre, Philippe Cornu,
Fabrice Gasnier
The ltdc pinctrl must be in the display controller node and
not in the peripheral node (hdmi bridge).
Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
---
arch/arm/boot/dts/stm32mp157a-dk1.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index f3f0e37..1285cfc 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -99,9 +99,6 @@
reset-gpios = <&gpioa 10 GPIO_ACTIVE_LOW>;
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
interrupt-parent = <&gpiog>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <<dc_pins_a>;
- pinctrl-1 = <<dc_pins_sleep_a>;
status = "okay";
ports {
@@ -276,6 +273,9 @@
};
<dc {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <<dc_pins_a>;
+ pinctrl-1 = <<dc_pins_sleep_a>;
status = "okay";
port {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PULL 1/3] Renesas ARM64 DT updates for v5.4
From: Geert Uytterhoeven @ 2019-08-02 14:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Linux-Renesas, arm-soc, arm-soc,
Linux ARM
In-Reply-To: <20190802120355.1430-2-geert+renesas@glider.be>
On Fri, Aug 2, 2019 at 2:04 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>
> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm64-dt-for-v5.4-tag1
>
> for you to fetch changes up to 0a05b3d7fee511de8a1c9dffc3d86f1df55e1737:
>
> arm64: dts: renesas: ulcb: Sort nodes (2019-07-30 11:25:35 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM64 DT updates for v5.4
>
> - CAN support for the HiHope RZ/G2E board,
As pointed out by Chris Paterson in PM, this is for RZ/G2[MN].
I've recreated the (signed) tag accordingly.
> - BT and WLAN support for the HiHope RZ/G2[MN] boards,
> - Sound support for RZ/G2M,
> - Sort nodes in various SoC and board DTSes,
> - Small fixes and improvements.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 26/34] mm/gup_benchmark.c: convert put_page() to put_user_page*()
From: Keith Busch @ 2019-08-02 14:19 UTC (permalink / raw)
To: john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Michael S . Tsirkin, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Dan Carpenter,
Ira Weiny, Dan Williams, devel, rds-devel, linux-rdma, x86,
YueHaibing, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, John Hubbard, intel-gfx,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, Greg Kroah-Hartman, linux-fsdevel, Andrew Morton,
Kirill A . Shutemov
In-Reply-To: <20190802022005.5117-27-jhubbard@nvidia.com>
On Thu, Aug 01, 2019 at 07:19:57PM -0700, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Keith Busch <keith.busch@intel.com>
> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Looks fine.
Reviewed-by: Keith Busch <keith.busch@intel.com>
> mm/gup_benchmark.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
> index 7dd602d7f8db..515ac8eeb6ee 100644
> --- a/mm/gup_benchmark.c
> +++ b/mm/gup_benchmark.c
> @@ -79,7 +79,7 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
> for (i = 0; i < nr_pages; i++) {
> if (!pages[i])
> break;
> - put_page(pages[i]);
> + put_user_page(pages[i]);
> }
> end_time = ktime_get();
> gup->put_delta_usec = ktime_us_delta(end_time, start_time);
> --
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64/kvm: fix -Wimplicit-fallthrough warnings
From: Qian Cai @ 2019-08-02 14:23 UTC (permalink / raw)
To: maz
Cc: drjones, suzuki.poulose, linux-kernel, james.morse,
christoffer.dall, Qian Cai, julien.thierry.kdev, kvmarm,
linux-arm-kernel
The commit a892819560c4 ("KVM: arm64: Prepare to handle deferred
save/restore of 32-bit registers") introduced vcpu_write_spsr32() but
seems forgot to add "break" between the switch statements and generates
compilation warnings below. Also, adding a default statement as in
vcpu_read_spsr32().
In file included from ./arch/arm64/include/asm/kvm_emulate.h:19,
from arch/arm64/kvm/regmap.c:13:
arch/arm64/kvm/regmap.c: In function 'vcpu_write_spsr32':
./arch/arm64/include/asm/kvm_hyp.h:31:3: warning: this statement may
fall through [-Wimplicit-fallthrough=]
asm volatile(ALTERNATIVE(__msr_s(r##nvh, "%x0"), \
^~~
./arch/arm64/include/asm/kvm_hyp.h:46:31: note: in expansion of macro
'write_sysreg_elx'
#define write_sysreg_el1(v,r) write_sysreg_elx(v, r, _EL1, _EL12)
^~~~~~~~~~~~~~~~
arch/arm64/kvm/regmap.c:180:3: note: in expansion of macro
'write_sysreg_el1'
write_sysreg_el1(v, SYS_SPSR);
^~~~~~~~~~~~~~~~
arch/arm64/kvm/regmap.c:181:2: note: here
case KVM_SPSR_ABT:
^~~~
In file included from ./arch/arm64/include/asm/cputype.h:132,
from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:18,
from ./arch/arm64/include/asm/bug.h:26,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/mm.h:9,
from arch/arm64/kvm/regmap.c:11:
./arch/arm64/include/asm/sysreg.h:837:2: warning: this statement may
fall through [-Wimplicit-fallthrough=]
asm volatile("msr " __stringify(r) ", %x0" \
^~~
arch/arm64/kvm/regmap.c:182:3: note: in expansion of macro
'write_sysreg'
write_sysreg(v, spsr_abt);
^~~~~~~~~~~~
arch/arm64/kvm/regmap.c:183:2: note: here
case KVM_SPSR_UND:
^~~~
In file included from ./arch/arm64/include/asm/cputype.h:132,
from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:18,
from ./arch/arm64/include/asm/bug.h:26,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/mm.h:9,
from arch/arm64/kvm/regmap.c:11:
./arch/arm64/include/asm/sysreg.h:837:2: warning: this statement may
fall through [-Wimplicit-fallthrough=]
asm volatile("msr " __stringify(r) ", %x0" \
^~~
arch/arm64/kvm/regmap.c:184:3: note: in expansion of macro
'write_sysreg'
write_sysreg(v, spsr_und);
^~~~~~~~~~~~
arch/arm64/kvm/regmap.c:185:2: note: here
case KVM_SPSR_IRQ:
^~~~
In file included from ./arch/arm64/include/asm/cputype.h:132,
from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:18,
from ./arch/arm64/include/asm/bug.h:26,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./include/linux/mm.h:9,
from arch/arm64/kvm/regmap.c:11:
./arch/arm64/include/asm/sysreg.h:837:2: warning: this statement may
fall through [-Wimplicit-fallthrough=]
asm volatile("msr " __stringify(r) ", %x0" \
^~~
arch/arm64/kvm/regmap.c:186:3: note: in expansion of macro
'write_sysreg'
write_sysreg(v, spsr_irq);
^~~~~~~~~~~~
arch/arm64/kvm/regmap.c:187:2: note: here
case KVM_SPSR_FIQ:
^~~~
Fixes: a892819560c4 ("KVM: arm64: Prepare to handle deferred save/restore of 32-bit registers")
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/arm64/kvm/regmap.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/kvm/regmap.c b/arch/arm64/kvm/regmap.c
index 0d60e4f0af66..c94e9bc3e8eb 100644
--- a/arch/arm64/kvm/regmap.c
+++ b/arch/arm64/kvm/regmap.c
@@ -178,13 +178,20 @@ void vcpu_write_spsr32(struct kvm_vcpu *vcpu, unsigned long v)
switch (spsr_idx) {
case KVM_SPSR_SVC:
write_sysreg_el1(v, SYS_SPSR);
+ break;
case KVM_SPSR_ABT:
write_sysreg(v, spsr_abt);
+ break;
case KVM_SPSR_UND:
write_sysreg(v, spsr_und);
+ break;
case KVM_SPSR_IRQ:
write_sysreg(v, spsr_irq);
+ break;
case KVM_SPSR_FIQ:
write_sysreg(v, spsr_fiq);
+ break;
+ default:
+ BUG();
}
}
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH] ARM: UNWINDER_FRAME_POINTER implementation for Clang
From: Robin Murphy @ 2019-08-02 14:24 UTC (permalink / raw)
To: Nathan Huckleberry, linux
Cc: clang-built-linux, Tri Vo, linux-kernel, linux-arm-kernel
In-Reply-To: <20190801231046.105022-1-nhuck@google.com>
On 02/08/2019 00:10, Nathan Huckleberry wrote:
> The stackframe setup when compiled with clang is different.
> Since the stack unwinder expects the gcc stackframe setup it
> fails to print backtraces. This patch adds support for the
> clang stackframe setup.
>
> Cc: clang-built-linux@googlegroups.com
> Suggested-by: Tri Vo <trong@google.com>
> Signed-off-by: Nathan Huckleberry <nhuck@google.com>
> ---
> arch/arm/Kconfig.debug | 4 +-
> arch/arm/Makefile | 2 +-
> arch/arm/lib/backtrace.S | 134 ++++++++++++++++++++++++++++++++++++---
> 3 files changed, 128 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 85710e078afb..92fca7463e21 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -56,7 +56,7 @@ choice
>
> config UNWINDER_FRAME_POINTER
> bool "Frame pointer unwinder"
> - depends on !THUMB2_KERNEL && !CC_IS_CLANG
> + depends on !THUMB2_KERNEL
> select ARCH_WANT_FRAME_POINTERS
> select FRAME_POINTER
> help
> @@ -1872,7 +1872,7 @@ config DEBUG_UNCOMPRESS
> When this option is set, the selected DEBUG_LL output method
> will be re-used for normal decompressor output on multiplatform
> kernels.
> -
> +
>
> config UNCOMPRESS_INCLUDE
> string
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c3624ca6c0bc..a593d9c4e18a 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -36,7 +36,7 @@ KBUILD_CFLAGS += $(call cc-option,-mno-unaligned-access)
> endif
>
> ifeq ($(CONFIG_FRAME_POINTER),y)
> -KBUILD_CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
> +KBUILD_CFLAGS +=-fno-omit-frame-pointer $(call cc-option,-mapcs,) $(call cc-option,-mno-sched-prolog,)
> endif
>
> ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
> diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
> index 1d5210eb4776..fd64eec9f6ae 100644
> --- a/arch/arm/lib/backtrace.S
> +++ b/arch/arm/lib/backtrace.S
> @@ -14,10 +14,7 @@
> @ fp is 0 or stack frame
>
> #define frame r4
> -#define sv_fp r5
> -#define sv_pc r6
> #define mask r7
> -#define offset r8
>
> ENTRY(c_backtrace)
>
> @@ -25,7 +22,8 @@ ENTRY(c_backtrace)
> ret lr
> ENDPROC(c_backtrace)
> #else
> - stmfd sp!, {r4 - r8, lr} @ Save an extra register so we have a location...
> + stmfd sp!, {r4 - r8, fp, lr} @ Save an extra register
Note that the Procedure Call Standard for EABI requires that SP be
8-byte-aligned at a public interface. Pushing an odd number of registers
here looks like it will make the subsequent calls to dump_backtrace_*
and printk violate that condition.
Robin.
> + @ so we have a location..
> movs frame, r0 @ if frame pointer is zero
> beq no_frame @ we have no stack frames
>
> @@ -35,11 +33,119 @@ ENDPROC(c_backtrace)
> THUMB( orreq mask, #0x03 )
> movne mask, #0 @ mask for 32-bit
>
> -1: stmfd sp!, {pc} @ calculate offset of PC stored
> - ldr r0, [sp], #4 @ by stmfd for this CPU
> - adr r1, 1b
> - sub offset, r0, r1
>
> +#if defined(CONFIG_CC_IS_CLANG)
> +/*
> + * Clang does not store pc or sp in function prologues
> + * so we don't know exactly where the function
> + * starts.
> + * We can treat the current frame's lr as the saved pc and the
> + * preceding frame's lr as the lr, but we can't
> + * trace the most recent call.
> + * Inserting a false stack frame allows us to reference the
> + * function called last in the stacktrace.
> + * If the call instruction was a bl we can look at the callers
> + * branch instruction to calculate the saved pc.
> + * We can recover the pc in most cases, but in cases such as
> + * calling function pointers we cannot. In this
> + * case, default to using the lr. This will be
> + * some address in the function, but will not
> + * be the function start.
> + * Unfortunately due to the stack frame layout we can't dump
> + * r0 - r3, but these are less frequently saved.
> + *
> + * Stack frame layout:
> + * <larger addresses>
> + * saved lr
> + * frame => saved fp
> + * optionally saved caller registers (r4 - r10)
> + * optionally saved arguments (r0 - r3)
> + * <top of stack frame>
> + * <smaller addressses>
> + *
> + * Functions start with the following code sequence:
> + * corrected pc => stmfd sp!, {..., fp, lr}
> + * add fp, sp, #x
> + * stmfd sp!, {r0 - r3} (optional)
> + */
> +#define sv_fp r5
> +#define sv_pc r6
> +#define sv_lr r8
> + add frame, sp, #20 @ switch to false frame
> +for_each_frame: tst frame, mask @ Check for address exceptions
> + bne no_frame
> +
> +1001: ldr sv_pc, [frame, #4] @ get saved 'pc'
> +1002: ldr sv_fp, [frame, #0] @ get saved fp
> +
> + teq sv_fp, #0 @ make sure next frame exists
> + beq no_frame
> +
> +1003: ldr sv_lr, [sv_fp, #4] @ get saved lr from next frame
> +
> + //try to find function start
> + ldr r0, [sv_lr, #-4] @ get call instruction
> + ldr r3, .Ldsi+8
> + and r2, r3, r0 @ is this a bl call
> + teq r2, r3
> + bne finished_setup @ give up if it's not
> + and r0, #0xffffff @ get call offset 24-bit int
> + lsl r0, r0, #8 @ sign extend offset
> + asr r0, r0, #8
> + ldr sv_pc, [sv_fp, #4] @ get lr address
> + add sv_pc, sv_pc, #-4 @ get call instruction address
> + add sv_pc, sv_pc, #8 @ take care of prefetch
> + add sv_pc, sv_pc, r0, lsl #2 @ find function start
> + b finished_setup
> +
> +finished_setup:
> +
> + bic sv_pc, sv_pc, mask @ mask PC/LR for the mode
> +
> +1004: mov r0, sv_pc
> +
> + mov r1, sv_lr
> + mov r2, frame
> + bic r1, r1, mask @ mask PC/LR for the mode
> + bl dump_backtrace_entry
> +
> +1005: ldr r1, [sv_pc, #0] @ if stmfd sp!, {..., fp, lr}
> + ldr r3, .Ldsi @ instruction exists,
> + teq r3, r1, lsr #11
> + ldr r0, [frame] @ locals are stored in
> + @ the preceding frame
> + subeq r0, r0, #4
> + bleq dump_backtrace_stm @ dump saved registers
> +
> + teq sv_fp, #0 @ zero saved fp means
> + beq no_frame @ no further frames
> +
> + cmp sv_fp, frame @ next frame must be
> + mov frame, sv_fp @ above the current frame
> + bhi for_each_frame
> +
> +1006: adr r0, .Lbad
> + mov r1, frame
> + bl printk
> +no_frame: ldmfd sp!, {r4 - r8, fp, pc}
> +ENDPROC(c_backtrace)
> + .pushsection __ex_table,"a"
> + .align 3
> + .long 1001b, 1006b
> + .long 1002b, 1006b
> + .long 1003b, 1006b
> + .long 1004b, 1006b
> + .popsection
> +
> +.Lbad: .asciz "Backtrace aborted due to bad frame pointer <%p>\n"
> + .align
> +.Ldsi: .word 0xe92d4800 >> 11 @ stmfd sp!, {... fp, lr}
> + .word 0xe92d0000 >> 11 @ stmfd sp!, {}
> + .word 0x0b000000 @ bl if these bits are set
> +
> +ENDPROC(c_backtrace)
> +
> +#else
> /*
> * Stack frame layout:
> * optionally saved caller registers (r4 - r10)
> @@ -55,6 +161,15 @@ ENDPROC(c_backtrace)
> * stmfd sp!, {r0 - r3} (optional)
> * corrected pc => stmfd sp!, {..., fp, ip, lr, pc}
> */
> +#define sv_fp r5
> +#define sv_pc r6
> +#define offset r8
> +
> +1: stmfd sp!, {pc} @ calculate offset of PC stored
> + ldr r0, [sp], #4 @ by stmfd for this CPU
> + adr r1, 1b
> + sub offset, r0, r1
> +
> for_each_frame: tst frame, mask @ Check for address exceptions
> bne no_frame
>
> @@ -98,7 +213,7 @@ for_each_frame: tst frame, mask @ Check for address exceptions
> 1006: adr r0, .Lbad
> mov r1, frame
> bl printk
> -no_frame: ldmfd sp!, {r4 - r8, pc}
> +no_frame: ldmfd sp!, {r4 - r8, fp, pc}
> ENDPROC(c_backtrace)
>
> .pushsection __ex_table,"a"
> @@ -115,3 +230,4 @@ ENDPROC(c_backtrace)
> .word 0xe92d0000 >> 11 @ stmfd sp!, {}
>
> #endif
> +#endif
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Matthew Wilcox @ 2019-08-02 14:24 UTC (permalink / raw)
To: Jan Kara
Cc: linux-fbdev, kvm, Dave Hansen, Dave Chinner, dri-devel,
Michal Hocko, linux-mm, sparclinux, Ira Weiny, Dan Williams,
devel, rds-devel, linux-rdma, x86, amd-gfx, Christoph Hellwig,
Jason Gunthorpe, xen-devel, devel, linux-media, John Hubbard,
intel-gfx, john.hubbard, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190802124146.GL25064@quack2.suse.cz>
On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
> > [...]
> > > 2) Convert all of the call sites for get_user_pages*(), to
> > > invoke put_user_page*(), instead of put_page(). This involves dozens of
> > > call sites, and will take some time.
> >
> > How do we make sure this is the case and it will remain the case in the
> > future? There must be some automagic to enforce/check that. It is simply
> > not manageable to do it every now and then because then 3) will simply
> > be never safe.
> >
> > Have you considered coccinele or some other scripted way to do the
> > transition? I have no idea how to deal with future changes that would
> > break the balance though.
>
> Yeah, that's why I've been suggesting at LSF/MM that we may need to create
> a gup wrapper - say vaddr_pin_pages() - and track which sites dropping
> references got converted by using this wrapper instead of gup. The
> counterpart would then be more logically named as unpin_page() or whatever
> instead of put_user_page(). Sure this is not completely foolproof (you can
> create new callsite using vaddr_pin_pages() and then just drop refs using
> put_page()) but I suppose it would be a high enough barrier for missed
> conversions... Thoughts?
I think the API we really need is get_user_bvec() / put_user_bvec(),
and I know Christoph has been putting some work into that. That avoids
doing refcount operations on hundreds of pages if the page in question is
a huge page. Once people are switched over to that, they won't be tempted
to manually call put_page() on the individual constituent pages of a bvec.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/9] arm64: perf: Remove PMU locking
From: Julien Thierry @ 2019-08-02 14:26 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, peterz, Catalin Marinas, will.deacon, acme,
alexander.shishkin, mingo, namhyung, sthotton, jolsa,
linux-arm-kernel, liwei391
In-Reply-To: <20190801125821.23wt657bfs2k536f@willie-the-truck>
Hi Will,
On 01/08/2019 13:58, Will Deacon wrote:
> On Wed, Jul 17, 2019 at 09:17:05AM +0100, Julien Thierry wrote:
>> Since the PMU driver uses direct registers for counter
>> setup/manipulation, locking around these operations is no longer needed.
>>
>> For operations that can be called with interrupts enabled, preemption
>> still needs to be disabled to ensure the programming of the PMU is
>> done on the expected CPU and not migrated mid-programming.
>>
>> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
>> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>> Cc: Jiri Olsa <jolsa@redhat.com>
>> Cc: Namhyung Kim <namhyung@kernel.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> arch/arm64/kernel/perf_event.c | 30 ++----------------------------
>> 1 file changed, 2 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index 838758f..0e2cf5d 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -673,15 +673,10 @@ static inline u32 armv8pmu_getreset_flags(void)
>>
>> static void armv8pmu_enable_event(struct perf_event *event)
>> {
>> - unsigned long flags;
>> - struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
>> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>> -
>> /*
>> * Enable counter and interrupt, and set the counter to count
>> * the event that we're interested in.
>> */
>> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
>>
>> /*
>> * Disable counter
>> @@ -702,21 +697,10 @@ static void armv8pmu_enable_event(struct perf_event *event)
>> * Enable counter
>> */
>> armv8pmu_enable_event_counter(event);
>> -
>> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>> }
>
> With the implicit ISBs now removed by virtue of addressing the counter
> register directly, what prevents the programming of the evtype being
> reordered with respect to disabling/enabling the counter?
I agree, it seems an ISB is missing here. It should probably be fixed in
the previous patch.
However, I notice that even before that patch, there is no ISB between
the enabling of the IRQ for the counter and the enabling of the counter
itself.
Meaning we might start counting events before the IRQ is enabled.
Should we have something like the following?
armv8pmu_disable_event_counter(event);
isb();
armv8pmu_write_event_type(event);
armv8pmu_enable_event_irq(event);
isb();
armv8pmu_enable_event_counter(event);
>
>> static void armv8pmu_disable_event(struct perf_event *event)
>> {
>> - unsigned long flags;
>> - struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
>> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>> -
>> - /*
>> - * Disable counter and interrupt
>> - */
>> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> -
>> /*
>> * Disable counter
>> */
>> @@ -726,30 +710,20 @@ static void armv8pmu_disable_event(struct perf_event *event)
>> * Disable interrupt for this counter
>> */
>> armv8pmu_disable_event_irq(event);
>> -
>> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>> }
>>
>> static void armv8pmu_start(struct arm_pmu *cpu_pmu)
>> {
>> - unsigned long flags;
>> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>> -
>> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> + WARN_ON_ONCE(preemptible());
>> /* Enable all counters */
>> armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
>> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>> }
>>
>> static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
>> {
>> - unsigned long flags;
>> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
>> -
>> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
>> + WARN_ON_ONCE(preemptible());
>
> I don't think we need these WARN_ONs -- these are very much per-CPU
> operations from the context of the perf core, so we'll be ok.
>
If they are not necessary we can get rid of them.
Thanks,
--
Julien Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/kvm: fix -Wimplicit-fallthrough warnings
From: Marc Zyngier @ 2019-08-02 14:32 UTC (permalink / raw)
To: Qian Cai
Cc: drjones, suzuki.poulose, linux-kernel, james.morse,
christoffer.dall, julien.thierry.kdev, kvmarm, linux-arm-kernel
In-Reply-To: <1564755788-28485-1-git-send-email-cai@lca.pw>
On 02/08/2019 15:23, Qian Cai wrote:
> The commit a892819560c4 ("KVM: arm64: Prepare to handle deferred
> save/restore of 32-bit registers") introduced vcpu_write_spsr32() but
> seems forgot to add "break" between the switch statements and generates
> compilation warnings below. Also, adding a default statement as in
> vcpu_read_spsr32().
See
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/commit/?id=3d584a3c85d6fe2cf878f220d4ad7145e7f89218
The default statement is pretty pointless by construction.
Thanks,
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] usb: dwc3: meson-g12a: use devm_platform_ioremap_resource() to simplify code
From: Neil Armstrong @ 2019-08-02 14:33 UTC (permalink / raw)
To: YueHaibing, balbi, gregkh, khilman
Cc: linux-amlogic, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <20190802130408.20336-1-yuehaibing@huawei.com>
On 02/08/2019 15:04, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/usb/dwc3/dwc3-meson-g12a.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
> index bca7e92..d73ccd9 100644
> --- a/drivers/usb/dwc3/dwc3-meson-g12a.c
> +++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
> @@ -386,7 +386,6 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> void __iomem *base;
> - struct resource *res;
> enum phy_mode otg_id;
> int ret, i, irq;
>
> @@ -394,8 +393,7 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - base = devm_ioremap_resource(dev, res);
> + base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(base))
> return PTR_ERR(base);
>
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/9] arm: perf: save/resore pmsel
From: Julien Thierry @ 2019-08-02 14:34 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, peterz, liwei391, will.deacon, Russell King, acme,
alexander.shishkin, mingo, stable, namhyung, sthotton, jolsa,
linux-arm-kernel
In-Reply-To: <20190801130126.xxsot2mabvisq76e@willie-the-truck>
On 01/08/2019 14:01, Will Deacon wrote:
> [typo in subject: resore ->restore]
>
> On Wed, Jul 17, 2019 at 09:17:06AM +0100, Julien Thierry wrote:
>> The callback pmu->read() can be called with interrupts enabled.
>> Currently, on ARM, this can cause the following callchain:
>>
>> armpmu_read() -> armpmu_event_update() -> armv7pmu_read_counter()
>
> Why can't we just disable irqs in armv7pmu_read_counter() ?
>
We could. But since we get rid of the lock after (otherwise it is the
only reason we have to keep the lock) we might as well find another
solution.
Thanks,
--
Julien Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/9] arm: perf: Remove Remove PMU locking
From: Julien Thierry @ 2019-08-02 14:36 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, peterz, liwei391, will.deacon, Russell King, acme,
alexander.shishkin, mingo, namhyung, sthotton, jolsa,
linux-arm-kernel
In-Reply-To: <20190801130640.4ed5bcy2rdgdtztq@willie-the-truck>
On 01/08/2019 14:06, Will Deacon wrote:
> [extra 'Remove' in subject]
>
> On Wed, Jul 17, 2019 at 09:17:07AM +0100, Julien Thierry wrote:
>> Since the PMU interrupt saves and restores the value of the selector
>> register, there is no need to serialize register accesses against the
>> interrupt contexts.
>>
>> For operations that can be called with interrupts enabled, preemption
>> still needs to be disabled to ensure the programming of the PMU is
>> done on the expected CPU and not migrated mid-programming.
>>
>> Signed-off-by: Julien Thierry <julien.thierry@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
>> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>> Cc: Jiri Olsa <jolsa@redhat.com>
>> Cc: Namhyung Kim <namhyung@kernel.org>
>> Cc: Russell King <linux@armlinux.org.uk>
>> ---
>> arch/arm/kernel/perf_event_v7.c | 54 ++---------------------------------------
>> 1 file changed, 2 insertions(+), 52 deletions(-)
>
> I'm struggling to see why this patch is needed or, if it is, why we're not
> doing something similar for v6 and xscale.
We can't do a similar things for v6 because it doesn't have set/clear
registers for event enabling/disabling. To do that on v6 we must do
read-modify-write, so we need to keep a spinlock.
For v7 we can do without it.
Thanks,
--
Julien Thierry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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