Re: [PATCH v3] drm/amdgpu: fix multiple memory leaks in acp_hw_init

2019-10-02 Thread Markus Elfring
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -184,12 +184,12 @@ static struct device *get_mfd_cell_dev(const char 
> *device_name, int r)
…
> + struct i2s_platform_data *i2s_pdata = NULL;
…

I propose to reconsider this update suggestion.


> @@ -231,20 +231,21 @@ static int acp_hw_init(void *handle)
>   adev->acp.acp_cell = kcalloc(ACP_DEVS, sizeof(struct mfd_cell),
>   GFP_KERNEL);
>
> - if (adev->acp.acp_cell == NULL)
> - return -ENOMEM;
…

I suggest to keep this source code place unchanged (at the moment).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c#n456


> @@ -393,6 +399,13 @@ static int acp_hw_init(void *handle)
>   val &= ~ACP_SOFT_RESET__SoftResetAud_MASK;
>   cgs_write_register(adev->acp.cgs_device, mmACP_SOFT_RESET, val);
>   return 0;
> +
> +failure:
> + kfree(i2s_pdata);
> + kfree(adev->acp.acp_res);
> + kfree(adev->acp.acp_cell);
> + kfree(adev->acp.acp_genpd);
> + return ret;
>  }
>
>  /**

I would prefer separate jump targets for efficient exception handling.
Please choose more appropriate labels for this function implementation.


> ---

I suggest to replace this second delimiter by a blank line.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/amdgpu: fix multiple memory leaks

2019-09-29 Thread Markus Elfring
> v2: moved the released into goto error handlings

A better version comment should be moved below the triple dashes.


Will the tag “Fixes” be added?


> @@ -393,6 +395,16 @@ static int acp_hw_init(void *handle)
>   val &= ~ACP_SOFT_RESET__SoftResetAud_MASK;
>   cgs_write_register(adev->acp.cgs_device, mmACP_SOFT_RESET, val);
>   return 0;
> +
> +out4:
> + kfree(i2s_pdata);
> +out3:
> + kfree(adev->acp.acp_res);
> +out2:
> + kfree(adev->acp.acp_cell);
> +out1:
> + kfree(adev->acp.acp_genpd);
> + return ret;
>  }
>
>  /**

I suggest to reconsider the label selection according to the Linux coding style.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tegra: vic: Use devm_platform_ioremap_resource() in vic_probe()

2019-09-21 Thread Markus Elfring
From: Markus Elfring 
Date: Sat, 21 Sep 2019 20:51:52 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tegra/vic.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index cd0399fd8c63..bc72d326588b 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -370,7 +370,6 @@ static int vic_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
struct host1x_syncpt **syncpts;
-   struct resource *regs;
struct vic *vic;
int err;

@@ -384,13 +383,7 @@ static int vic_probe(struct platform_device *pdev)
if (!syncpts)
return -ENOMEM;

-   regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!regs) {
-   dev_err(&pdev->dev, "failed to get registers\n");
-   return -ENXIO;
-   }
-
-   vic->regs = devm_ioremap_resource(dev, regs);
+   vic->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(vic->regs))
return PTR_ERR(vic->regs);

--
2.23.0



[PATCH] drm/rockchip/rk3066: Use devm_platform_ioremap_resource() in rk3066_hdmi_bind()

2019-09-21 Thread Markus Elfring
From: Markus Elfring 
Date: Sat, 21 Sep 2019 20:32:25 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c 
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 85fc5f01f761..cdb401f4283d 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -743,7 +743,6 @@ static int rk3066_hdmi_bind(struct device *dev, struct 
device *master,
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = data;
struct rk3066_hdmi *hdmi;
-   struct resource *iores;
int irq;
int ret;

@@ -753,12 +752,7 @@ static int rk3066_hdmi_bind(struct device *dev, struct 
device *master,

hdmi->dev = dev;
hdmi->drm_dev = drm;
-
-   iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!iores)
-   return -ENXIO;
-
-   hdmi->regs = devm_ioremap_resource(dev, iores);
+   hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hdmi->regs))
return PTR_ERR(hdmi->regs);

--
2.23.0



[PATCH] drm/bridge/synopsys: dsi: Use devm_platform_ioremap_resource() in __dw_mipi_dsi_probe()

2019-09-21 Thread Markus Elfring
From: Markus Elfring 
Date: Sat, 21 Sep 2019 20:04:08 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 675442bfc1bd..6ada149af9ef 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -981,7 +981,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
struct device *dev = &pdev->dev;
struct reset_control *apb_rst;
struct dw_mipi_dsi *dsi;
-   struct resource *res;
int ret;

dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
@@ -997,11 +996,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
}

if (!plat_data->base) {
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return ERR_PTR(-ENODEV);
-
-   dsi->base = devm_ioremap_resource(dev, res);
+   dsi->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(dsi->base))
return ERR_PTR(-ENODEV);

--
2.23.0



[PATCH] drm/komeda: Use devm_platform_ioremap_resource() in komeda_dev_create()

2019-09-21 Thread Markus Elfring
From: Markus Elfring 
Date: Sat, 21 Sep 2019 19:43:51 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index ca64a129c594..a387d923962e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -172,19 +172,12 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
const struct komeda_product_data *product;
struct komeda_dev *mdev;
-   struct resource *io_res;
int err = 0;

product = of_device_get_match_data(dev);
if (!product)
return ERR_PTR(-ENODEV);

-   io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!io_res) {
-   DRM_ERROR("No registers defined.\n");
-   return ERR_PTR(-ENODEV);
-   }
-
mdev = devm_kzalloc(dev, sizeof(*mdev), GFP_KERNEL);
if (!mdev)
return ERR_PTR(-ENOMEM);
@@ -192,7 +185,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
mutex_init(&mdev->lock);

mdev->dev = dev;
-   mdev->reg_base = devm_ioremap_resource(dev, io_res);
+   mdev->reg_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(mdev->reg_base)) {
DRM_ERROR("Map register space failed.\n");
err = PTR_ERR(mdev->reg_base);
--
2.23.0



[PATCH] video: pxafb: Use devm_platform_ioremap_resource() in pxafb_probe()

2019-09-19 Thread Markus Elfring
From: Markus Elfring 
Date: Thu, 19 Sep 2019 16:51:38 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/pxafb.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index f70c9f79622e..237f8f436fdb 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2237,7 +2237,6 @@ static int pxafb_probe(struct platform_device *dev)
 {
struct pxafb_info *fbi;
struct pxafb_mach_info *inf, *pdata;
-   struct resource *r;
int i, irq, ret;

dev_dbg(&dev->dev, "pxafb_probe\n");
@@ -2303,14 +2302,7 @@ static int pxafb_probe(struct platform_device *dev)
fbi->lcd_supply = NULL;
}

-   r = platform_get_resource(dev, IORESOURCE_MEM, 0);
-   if (r == NULL) {
-   dev_err(&dev->dev, "no I/O memory resource defined\n");
-   ret = -ENODEV;
-   goto failed;
-   }
-
-   fbi->mmio_base = devm_ioremap_resource(&dev->dev, r);
+   fbi->mmio_base = devm_platform_ioremap_resource(dev, 0);
if (IS_ERR(fbi->mmio_base)) {
dev_err(&dev->dev, "failed to get I/O memory\n");
ret = -EBUSY;
--
2.23.0



[PATCH] video: ocfb: Use devm_platform_ioremap_resource() in ocfb_probe()

2019-09-19 Thread Markus Elfring
From: Markus Elfring 
Date: Thu, 19 Sep 2019 16:26:56 +0200

Simplify this function implementation by using a known wrapper function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/ocfb.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
index a970edc2a6f8..be308b4dc91d 100644
--- a/drivers/video/fbdev/ocfb.c
+++ b/drivers/video/fbdev/ocfb.c
@@ -297,7 +297,6 @@ static int ocfb_probe(struct platform_device *pdev)
 {
int ret = 0;
struct ocfb_dev *fbdev;
-   struct resource *res;
int fbsize;

fbdev = devm_kzalloc(&pdev->dev, sizeof(*fbdev), GFP_KERNEL);
@@ -319,13 +318,7 @@ static int ocfb_probe(struct platform_device *pdev)
ocfb_init_var(fbdev);
ocfb_init_fix(fbdev);

-   /* Request I/O resource */
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(&pdev->dev, "I/O resource request failed\n");
-   return -ENXIO;
-   }
-   fbdev->regs = devm_ioremap_resource(&pdev->dev, res);
+   fbdev->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fbdev->regs))
return PTR_ERR(fbdev->regs);

--
2.23.0



[PATCH] omapdrm/dss: Use PTR_ERR_OR_ZERO() in four functions

2019-09-06 Thread Markus Elfring
From: Markus Elfring 
Date: Fri, 6 Sep 2019 18:40:48 +0200

Simplify these function implementations by using a known function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c  | 6 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 4 +---
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 +---
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c   | 4 +---
 4 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 0f557fad4513..b1a8d4bfbe48 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -586,11 +586,7 @@ static int hdmi_audio_register(struct omap_hdmi *hdmi)
hdmi->audio_pdev = platform_device_register_data(
&hdmi->pdev->dev, "omap-hdmi-audio", PLATFORM_DEVID_AUTO,
&pdata, sizeof(pdata));
-
-   if (IS_ERR(hdmi->audio_pdev))
-   return PTR_ERR(hdmi->audio_pdev);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(hdmi->audio_pdev);
 }

 /* 
-
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
index 5d5d5588ebc1..0775109133b5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
@@ -923,8 +923,6 @@ int hdmi4_core_init(struct platform_device *pdev, struct 
hdmi_core_data *core)

res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
core->base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(core->base))
-   return PTR_ERR(core->base);

-   return 0;
+   return PTR_ERR_OR_ZERO(core->base);
 }
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 7400fb99d453..655cf2048809 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -899,8 +899,6 @@ int hdmi5_core_init(struct platform_device *pdev, struct 
hdmi_core_data *core)

res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core");
core->base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(core->base))
-   return PTR_ERR(core->base);

-   return 0;
+   return PTR_ERR_OR_ZERO(core->base);
 }
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
index 00bbf24488c1..bbc02d5aa8fb 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c
@@ -191,8 +191,6 @@ int hdmi_phy_init(struct platform_device *pdev, struct 
hdmi_phy_data *phy,

res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy");
phy->base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(phy->base))
-   return PTR_ERR(phy->base);

-   return 0;
+   return PTR_ERR_OR_ZERO(phy->base);
 }
--
2.23.0



Re: [v2] drm/amdgpu: Remove two redundant null pointer checks

2019-09-06 Thread Markus Elfring
> The functions "debugfs_remove" and "kfree" tolerate the passing
> of null pointers. Hence it is unnecessary to check such arguments
> around the calls. Thus remove the extra condition check at two places.

Will a tag like “Generated-by: scripts/coccinelle/free/ifnullfree.cocci” be 
relevant here?

How do you think about to compare this change approach with another patch 
variant?

drm/amdgpu: Delete an unnecessary check before two function calls
https://lkml.org/lkml/2019/9/4/401
https://lore.kernel.org/patchwork/patch/1123689/
https://lore.kernel.org/r/a3739125-5fa8-cadb-d2b8-8a9f12e9b...@web.de/

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/amdgpu: remove the redundant null check

2019-09-06 Thread Markus Elfring
>> Were any source code analysis tools involved for finding
>> these update candidates?
> With the help of Coccinelle. You can find out some example in 
> scripts/coccinelle/.

Thanks for such background information.
Was the script “ifnullfree.cocci” applied here?

Will it be helpful to add attribution for such tools
to any more descriptions in your patches?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/amdgpu: Delete an unnecessary check before two function calls

2019-09-05 Thread Markus Elfring
> The functions “debugfs_remove” and “kfree” test whether their argument
> is NULL and then return immediately.
> Thus the tests around the shown calls are not needed.
>
> This issue was detected by using the Coccinelle software.

I suggest to take another look at a similar patch.

drm/amdgpu: remove the redundant null check
https://lkml.org/lkml/2019/9/3/59
https://lore.kernel.org/patchwork/patch/1123118/
https://lore.kernel.org/r/1567491305-18320-1-git-send-email-zhongji...@huawei.com/

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Delete an unnecessary check before two function calls

2019-09-05 Thread Markus Elfring
From: Markus Elfring 
Date: Wed, 4 Sep 2019 12:30:23 +0200

The functions “debugfs_remove” and “kfree” test whether their argument
is NULL and then return immediately.
Thus the tests around the shown calls are not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 5652cc72ed3a..d321c72d63d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1076,10 +1076,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
kthread_unpark(ring->sched.thread);

ttm_bo_unlock_delayed_workqueue(&adev->mman.bdev, resched);
-
-   if (fences)
-   kfree(fences);
-
+   kfree(fences);
return 0;
 }

@@ -1103,8 +1100,7 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)

 void amdgpu_debugfs_preempt_cleanup(struct amdgpu_device *adev)
 {
-   if (adev->debugfs_preempt)
-   debugfs_remove(adev->debugfs_preempt);
+   debugfs_remove(adev->debugfs_preempt);
 }

 #else
--
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/11] checkpatch: check for nested (un)?likely() calls

2019-08-31 Thread Markus Elfring
> +# nested likely/unlikely calls
> +    if ($line =~ 
> /\b(?:(?:un)?likely)\s*\(\s*!?\s*(IS_ERR(?:_OR_NULL|_VALUE)?|WARN)/) {
> +    WARN("LIKELY_MISUSE",
…
>> \b(?:un)?likely\s*
>
> This pair of brackets is required to match "unlikely"
> and it's optional in order to match "likely".

I agree also to this view if you refer to the shortened regular expression here.
But I got an other development opinion for an extra pair of non-capturing 
parentheses
at the front (from the version which you suggested).

Regards,
Markus


Re: [PATCH v3 01/11] checkpatch: check for nested (un)?likely() calls

2019-08-31 Thread Markus Elfring
>>> +# nested likely/unlikely calls
>>> +    if ($line =~ 
>>> /\b(?:(?:un)?likely)\s*\(\s*!?\s*(IS_ERR(?:_OR_NULL|_VALUE)?|WARN)/) {
>>> +    WARN("LIKELY_MISUSE",
>>
>> How do you think about to use the specification 
>> “(?:IS_ERR(?:_(?:OR_NULL|VALUE))?|WARN)”
>> in this regular expression?
…
>IS_ERR
>(?:_ <- Another atomic group just to show that '_' is a common prefix?

Yes. - I hope that this specification detail can help a bit.


>Usually, Perl interpreter is very good at optimizing such things.

Would you like to help this software component by omitting a pair of
non-capturing parentheses at the beginning?

\b(?:un)?likely\s*


Regards,
Markus


Re: [PATCH v3 01/11] checkpatch: check for nested (un)?likely() calls

2019-08-31 Thread Markus Elfring

+# nested likely/unlikely calls
+   if ($line =~ 
/\b(?:(?:un)?likely)\s*\(\s*!?\s*(IS_ERR(?:_OR_NULL|_VALUE)?|WARN)/) {
+   WARN("LIKELY_MISUSE",


How do you think about to use the specification 
“(?:IS_ERR(?:_(?:OR_NULL|VALUE))?|WARN)”
in this regular expression?

Regards,
Markus


Re: drm/amd/powerplay: remove redundant memset

2019-07-15 Thread Markus Elfring
> kzalloc has already zeroed the memory.
> So the memset is unneeded.

See also a previous patch:
drm/amd/powerplay: Delete a redundant memory setting in 
vega20_set_default_od8_setttings()
https://lore.kernel.org/lkml/de3f6a5e-8ac4-bc8e-0d0c-3a4a5db28...@web.de/
https://lore.kernel.org/patchwork/patch/1089691/
https://lkml.org/lkml/2019/6/17/460

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/display: Delete a redundant memory setting in amdgpu_dm_irq_register_interrupt()

2019-06-18 Thread Markus Elfring
From: Markus Elfring 
Date: Mon, 17 Jun 2019 13:56:39 +0200

The memory was set to zero already by a call of the function “kzalloc”.
Thus remove an extra call of the function “memset” for this purpose.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index 1b59d3d42f7b..fa5d503d379c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
@@ -277,8 +277,6 @@ void *amdgpu_dm_irq_register_interrupt(struct amdgpu_device 
*adev,
return DAL_INVALID_IRQ_HANDLER_IDX;
}

-   memset(handler_data, 0, sizeof(*handler_data));
-
init_handler_common_data(handler_data, ih, handler_args, &adev->dm);

irq_source = int_params->irq_source;
--
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/powerplay: Delete a redundant memory setting in vega20_set_default_od8_setttings()

2019-06-18 Thread Markus Elfring
From: Markus Elfring 
Date: Mon, 17 Jun 2019 14:24:14 +0200

The memory was set to zero already by a call of the function “kzalloc”.
Thus remove an extra call of the function “memset” for this purpose.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c 
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index 4aa8f5a69c4c..62497ad66a39 100644
--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
@@ -1295,7 +1295,6 @@ static int vega20_set_default_od8_setttings(struct 
smu_context *smu)
if (!table_context->od8_settings)
return -ENOMEM;

-   memset(table_context->od8_settings, 0, sizeof(struct 
vega20_od8_settings));
od8_settings = (struct vega20_od8_settings 
*)table_context->od8_settings;

if (smu_feature_is_enabled(smu, FEATURE_DPM_SOCCLK_BIT)) {
--
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/12] drm/tegra: rgb: add missing of_node_put after of_device_is_available

2019-04-15 Thread Markus Elfring
> @@ -221,8 +221,10 @@  int tegra_dc_rgb_probe(struct tegra_dc *
>   int err;
>
>   np = of_get_child_by_name(dc->dev->of_node, "rgb");
> - if (!np || !of_device_is_available(np))
> + if (!np || !of_device_is_available(np)) {
> + of_node_put(np);
>   return -ENODEV;
> + }
>
>   rgb = devm_kzalloc(dc->dev, sizeof(*rgb), GFP_KERNEL);
>   if (!rgb)

How do you think about to move this function call to an additional jump target
for the desired exception handling?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: rcar-du: fix possible object reference leak

2019-04-09 Thread Markus Elfring
> v2->v1: turn the return into a goto done.

* The version identification can be shorter, can't it?

* The expection handling should be completed for the implementation
  of the function “rcar_du_of_lvds_patch” in a different way.
  
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rcar-du/rcar_du_of.c?id=ac5b84a1ffe93c9fb882c0f2bdfac1c33077b920#n195

  How do you think about to add a few jump targets (at the end)?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/meson: fix possible object reference leak

2019-04-09 Thread Markus Elfring
> v2->v1: convert a if statement into a ternary statement.

Would you like to omit the arrow in such version information?


> @@ -720,15 +720,10 @@ static bool meson_hdmi_connector_is_available(struct 
> device *dev)
>
>   /* If the endpoint node exists, consider it enabled */
>   remote = of_graph_get_remote_port(ep);
> - if (remote) {
> - of_node_put(ep);
> - return true;
> - }
> -
>   of_node_put(ep);
>   of_node_put(remote);

Can a reordering of the passed variables be useful for such function calls?

+   of_node_put(remote);
+   of_node_put(ep);

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] drm/pl111: fix possible object reference leak

2019-04-05 Thread Markus Elfring
> @@ -337,17 +338,20 @@ int pl111_versatile_init(struct device *dev, struct 
> pl111_drm_dev_private *priv)
>   pdev = of_find_device_by_node(np);
>   if (!pdev) {
>   dev_err(dev, "can't find the sysreg device, 
> deferring\n");
> + of_node_put(np);
>   return -EPROBE_DEFER;
>   }
>   map = dev_get_drvdata(&pdev->dev);
>   if (!map) {
>   dev_err(dev, "sysreg has not yet probed\n");
>   platform_device_put(pdev);
> + of_node_put(np);
>   return -EPROBE_DEFER;
>   }

How do you think about to move duplicate statements to an additional
jump target for the desired exception handling?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/omap: fix possible object reference leak

2019-04-05 Thread Markus Elfring
> @@ -208,8 +208,10 @@  static int __init omapdss_boot_init(void)
>
>   dss = of_find_matching_node(NULL, omapdss_of_match);
>
> - if (dss == NULL || !of_device_is_available(dss))
> + if (dss == NULL || !of_device_is_available(dss)) {
> + of_node_put(dss);
>   return 0;
> + }

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c?id=61de49cb596710b918f7a80839f0b6de2017bc32#n203

Can it be nicer to add a jump target here?

+   if (!dss || !of_device_is_available(dss))
-   return 0;
+   goto put_node;


>
>   omapdss_walk_device(dss, true);
>
> @@ -234,6 +236,7 @@  static int __init omapdss_boot_init(void)
>   kfree(n);
>   }
>

+put_node:

> + of_node_put(dss);
>   return 0;
>  }


Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] drm/meson: fix possible object reference leak

2019-04-05 Thread Markus Elfring
> @@ -720,13 +720,10 @@ static bool meson_hdmi_connector_is_available(struct 
> device *dev)
>
>   /* If the endpoint node exists, consider it enabled */
>   remote = of_graph_get_remote_port(ep);
> - if (remote) {
> - of_node_put(ep);
> - return true;
> - }
> -
>   of_node_put(ep);
>   of_node_put(remote);

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/meson/meson_dw_hdmi.c?id=61de49cb596710b918f7a80839f0b6de2017bc32#n712

Can the order of these put calls matter (because of processor caches)?


> + if (remote)
> + return true;
>
>   return false;

Would the use of a ternary operator be more succinct here?

+   return remote ? true : false;

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/adreno: Remove VLA usage

2018-07-02 Thread SF Markus Elfring
> @@ -91,12 +93,13 @@  static int zap_shader_load_mdt(struct msm_gpu *gpu, 
> const char *fwname)
>   ret = qcom_mdt_load(dev, fw, fwname, GPU_PAS_ID,
>   mem_region, mem_phys, mem_size, NULL);
>   } else {
> - char newname[strlen("qcom/") + strlen(fwname) + 1];
> + char *newname;
> 
> - sprintf(newname, "qcom/%s", fwname);
> + newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
> 
>   ret = qcom_mdt_load(dev, fw, newname, GPU_PAS_ID,
>   mem_region, mem_phys, mem_size, NULL);

I have taken another look also at this update suggestion.
Now I wonder why the return value is not checked for the added name construction
in the way as it is specified for the function “adreno_request_fw”.
Will another condition check make sense at this place?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/amdkfd: Delete an error message for a failed memory allocation in kfd_topology_init()

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 22:23:57 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 19ce59028d6b..610e3d4ac575 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -1019,7 +1019,6 @@ int kfd_topology_init(void)
crat_image = kmalloc(image_size, GFP_KERNEL);
if (!crat_image) {
ret = -ENOMEM;
-   pr_err("No memory for allocating CRAT image\n");
goto err;
}
ret = kfd_topology_get_crat_acpi(crat_image, &image_size);
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/amd/powerplay/hwmgr: Delete an unnecessary return statement in three functions

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:10:58 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected functions.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 3 ---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 2681c9317d25..e07b32491092 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -653,8 +653,6 @@ void phm_trim_voltage_table_to_fit_state_table(uint32_t 
max_vol_steps,
vol_table->entries[i] = vol_table->entries[i + diff];
 
vol_table->count = max_vol_steps;
-
-   return;
 }
 
 int phm_reset_single_dpm_table(void *table,
@@ -906,7 +904,6 @@ void hwmgr_init_default_caps(struct pp_hwmgr *hwmgr)
 
phm_cap_set(hwmgr->platform_descriptor.platformCaps,

PHM_PlatformCaps_FanSpeedInTableIsRPM);
-   return;
 }
 
 int hwmgr_set_user_specify_caps(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 2d55dabc77d4..fcdb3563d860 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3618,7 +3618,6 @@ static uint32_t vega10_find_highest_dpm_level(
 static void vega10_apply_dal_minimum_voltage_request(
struct pp_hwmgr *hwmgr)
 {
-   return;
 }
 
 static int vega10_get_soc_index_for_max_uclk(struct pp_hwmgr *hwmgr)
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/amd/powerplay/hwmgr: Adjust layout for source code from five if statements

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:01:24 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: Comparisons should place the constant on the right side
of the test
WARNING: else is not generally useful after a break or return

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c   | 33 +++-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c  | 31 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c |  5 ++--
 3 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index c0699b884894..870c517f2057 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -1772,37 +1772,34 @@ static int cz_read_sensor(struct pp_hwmgr *hwmgr, int 
idx,
return 0;
case AMDGPU_PP_SENSOR_UVD_VCLK:
if (!cz_hwmgr->uvd_power_gated) {
-   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   vclk = uvd_table->entries[uvd_index].vclk;
-   *((uint32_t *)value) = vclk;
-   return 0;
-   }
+
+   vclk = uvd_table->entries[uvd_index].vclk;
+   *((uint32_t *)value) = vclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
case AMDGPU_PP_SENSOR_UVD_DCLK:
if (!cz_hwmgr->uvd_power_gated) {
-   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   dclk = uvd_table->entries[uvd_index].dclk;
-   *((uint32_t *)value) = dclk;
-   return 0;
-   }
+
+   dclk = uvd_table->entries[uvd_index].dclk;
+   *((uint32_t *)value) = dclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
case AMDGPU_PP_SENSOR_VCE_ECCLK:
if (!cz_hwmgr->vce_power_gated) {
-   if (vce_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (vce_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   ecclk = vce_table->entries[vce_index].ecclk;
-   *((uint32_t *)value) = ecclk;
-   return 0;
-   }
+
+   ecclk = vce_table->entries[vce_index].ecclk;
+   *((uint32_t *)value) = ecclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ded33ed03f11..2681c9317d25 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -813,24 +813,23 @@ int 
phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr *hwmgr
/* initialize vddc_dep_on_dal_pwrl table */
table_size = sizeof(uint32_t) + 4 * sizeof(struct 
phm_clock_voltage_dependency_record);
table_clk_vlt = kzalloc(table_size, GFP_KERNEL);
-
-   if (NULL == table_clk_vlt) {
+   if (!table_clk_vlt)
return -ENOMEM;
-   } else {
-   table_clk_vlt->count = 4;
-   table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_ULTRALOW;
-   table_clk_vlt->entries[0].v = 0;
-   table_clk_vlt->entries[1].clk = PP_DAL_POWERLEVEL_LOW;
-   table_clk_vlt->entries[1].v = 720;
-   table_clk_vlt->entries[2].clk = PP_DAL_POWERLEVEL_NOMINAL;
-   table_clk_vlt->entries[2].v = 810;
-   table_clk_vlt->entries[3].clk = PP_DAL_POWERLEVEL_PERFORMANCE;
-   table_clk_vlt->entries[3].v = 900;
-   if (pptable_info != NULL)
-   pptable_info->vddc_dep_on_dal_pwrl = table_clk_vlt;
-   hwmgr->dyn_state.vddc_dep_on_dal_pwrl = table_clk_vlt;
-   }
 
+   table_clk_vlt->count = 4;
+   table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_ULTRALOW;
+   table_clk_vlt->entries[0].v = 0;
+   table_clk_vlt->entries[1].clk = PP_

[PATCH 1/3] drm/amd/powerplay/hwmgr: Delete an error message for a failed memory allocation in three functions

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 20:32:39 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 4 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 1 -
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 4 +---
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index b314d09d41af..c0699b884894 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -286,10 +286,8 @@ static int cz_init_dynamic_state_adjustment_rule_settings(
struct phm_clock_voltage_dependency_table *table_clk_vlt =
kzalloc(table_size, GFP_KERNEL);
 
-   if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate memory!\n");
+   if (!table_clk_vlt)
return -ENOMEM;
-   }
 
table_clk_vlt->count = 8;
table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_0;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 0229f774f7a9..ded33ed03f11 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -815,7 +815,6 @@ int 
phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr *hwmgr
table_clk_vlt = kzalloc(table_size, GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate space for vddc_dep_on_dal_pwrl! \n");
return -ENOMEM;
} else {
table_clk_vlt->count = 4;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index 569073e3a5a1..967b93e56113 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -107,10 +107,8 @@ static int rv_init_dynamic_state_adjustment_rule_settings(
struct phm_clock_voltage_dependency_table *table_clk_vlt =
kzalloc(table_size, GFP_KERNEL);
 
-   if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate memory!\n");
+   if (!table_clk_vlt)
return -ENOMEM;
-   }
 
table_clk_vlt->count = 8;
table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_0;
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] drm/amd/powerplay/hwmgr: Adjustments for eight function implementations

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:37:42 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in three functions
  Adjust layout for source code from five if statements
  Delete an unnecessary return statement in three functions

 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 37 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 35 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c   |  5 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c |  4 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  1 -
 5 files changed, 35 insertions(+), 47 deletions(-)

-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm_fb_cma_helper: Delete an error message for a failed memory allocation in drm_fbdev_cma_init_with_funcs()

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 19:30:06 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..59f0d8dbfa61 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -408,10 +408,9 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
int ret;
 
fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
-   if (!fbdev_cma) {
-   dev_err(dev->dev, "Failed to allocate drm fbdev.\n");
+   if (!fbdev_cma)
return ERR_PTR(-ENOMEM);
-   }
+
fbdev_cma->fb_funcs = funcs;
 
helper = &fbdev_cma->fb_helper;
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 18:42:51 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 2b8bf2dd6387..5eb0d3292525 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -286,7 +286,6 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
 
node = kcalloc(G2D_CMDLIST_NUM, sizeof(*node), GFP_KERNEL);
if (!node) {
-   dev_err(dev, "failed to allocate memory\n");
ret = -ENOMEM;
goto err;
}
@@ -1358,10 +1357,9 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, 
void *data,
return -EFAULT;
 
runqueue_node = kmem_cache_alloc(g2d->runqueue_slab, GFP_KERNEL);
-   if (!runqueue_node) {
-   dev_err(dev, "failed to allocate memory\n");
+   if (!runqueue_node)
return -ENOMEM;
-   }
+
run_cmdlist = &runqueue_node->run_cmdlist;
event_list = &runqueue_node->event_list;
INIT_LIST_HEAD(run_cmdlist);
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/gma500: Delete an unnecessary return statement in oaktrail_crtc_hdmi_dpms()

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 15:17:48 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected function.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index dbc58e5130bb..24c7c6edfca5 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -484,8 +484,6 @@ void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int 
mode)
 
/* LNC Chicken Bits - Squawk! */
REG_WRITE(0x70400, 0x4000);
-
-   return;
 }
 
 static void oaktrail_hdmi_dpms(struct drm_encoder *encoder, int mode)
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/gma500: Improve four size determinations

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 15:08:39 +0100

Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/framebuffer.c   | 3 +--
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 3ff320f3ff47..ad96a542d137 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -525,11 +525,10 @@ static int psb_fbdev_destroy(struct drm_device *dev, 
struct psb_fbdev *fbdev)
 
 int psb_fbdev_init(struct drm_device *dev)
 {
-   struct psb_fbdev *fbdev;
struct drm_psb_private *dev_priv = dev->dev_private;
int ret;
+   struct psb_fbdev *fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
 
-   fbdev = kzalloc(sizeof(struct psb_fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index d9a6d54b6641..dbc58e5130bb 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -637,11 +637,11 @@ void oaktrail_hdmi_init(struct drm_device *dev,
struct drm_connector *connector;
struct drm_encoder *encoder;
 
-   gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
+   gma_encoder = kzalloc(sizeof(*gma_encoder), GFP_KERNEL);
if (!gma_encoder)
return;
 
-   gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
+   gma_connector = kzalloc(sizeof(*gma_connector), GFP_KERNEL);
if (!gma_connector)
goto failed_connector;
 
@@ -689,7 +689,7 @@ void oaktrail_hdmi_setup(struct drm_device *dev)
if (!pdev)
return;
 
-   hdmi_dev = kzalloc(sizeof(struct oaktrail_hdmi_dev), GFP_KERNEL);
+   hdmi_dev = kzalloc(sizeof(*hdmi_dev), GFP_KERNEL);
if (!hdmi_dev)
goto out;
 
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] drm/gma500: Delete an error message for a failed memory allocation in two functions

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 14:55:49 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/gma500/framebuffer.c   | 4 +---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 5 +
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index cb0a2ae916e0..3ff320f3ff47 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -530,10 +530,8 @@ int psb_fbdev_init(struct drm_device *dev)
int ret;
 
fbdev = kzalloc(sizeof(struct psb_fbdev), GFP_KERNEL);
-   if (!fbdev) {
-   dev_err(dev->dev, "no memory\n");
+   if (!fbdev)
return -ENOMEM;
-   }
 
dev_priv->fbdev = fbdev;
 
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 8b2eb32ee988..d9a6d54b6641 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -690,11 +690,8 @@ void oaktrail_hdmi_setup(struct drm_device *dev)
return;
 
hdmi_dev = kzalloc(sizeof(struct oaktrail_hdmi_dev), GFP_KERNEL);
-   if (!hdmi_dev) {
-   dev_err(dev->dev, "failed to allocate memory\n");
+   if (!hdmi_dev)
goto out;
-   }
-
 
ret = pci_enable_device(pdev);
if (ret) {
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] GPU-DRM-GMA500: Adjustments for four function implementations

2018-02-08 Thread SF Markus Elfring
From: Markus Elfring 
Date: Thu, 8 Feb 2018 15:27:38 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in two functions
  Improve four size determinations
  Delete an unnecessary return statement in oaktrail_crtc_hdmi_dpms()

 drivers/gpu/drm/gma500/framebuffer.c   |  7 ++-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 13 -
 2 files changed, 6 insertions(+), 14 deletions(-)

-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm/msm/mdp4: Return directly after a failed kzalloc() in mdp4_kms_init()

2018-02-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Wed, 7 Feb 2018 22:34:45 +0100

* Return directly after a call of the function "kzalloc" failed
  at the beginning.

* Delete an initialisation and a check (for the local variable "kms")
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 5c5965a9d1f9..4f15cd569ee1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -411,15 +411,13 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
struct platform_device *pdev = to_platform_device(dev->dev);
struct mdp4_platform_config *config = mdp4_get_config(pdev);
struct mdp4_kms *mdp4_kms;
-   struct msm_kms *kms = NULL;
+   struct msm_kms *kms;
struct msm_gem_address_space *aspace;
int irq, ret;
 
mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
-   if (!mdp4_kms) {
-   ret = -ENOMEM;
-   goto fail;
-   }
+   if (!mdp4_kms)
+   return ERR_PTR(-ENOMEM);
 
mdp_kms_init(&mdp4_kms->base, &kms_funcs);
 
@@ -550,8 +548,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
return kms;
 
 fail:
-   if (kms)
-   mdp4_destroy(kms);
+   mdp4_destroy(kms);
return ERR_PTR(ret);
 }
 
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] drm/msm/mdp4: Delete an error message for a failed memory allocation in mdp4_kms_init()

2018-02-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Wed, 7 Feb 2018 22:22:28 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index f7f087419ed8..5c5965a9d1f9 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -417,7 +417,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
 
mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
if (!mdp4_kms) {
-   dev_err(dev->dev, "failed to allocate kms\n");
ret = -ENOMEM;
goto fail;
}
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/2] drm/msm/mdp4: Adjustments for mdp4_kms_init()

2018-02-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Wed, 7 Feb 2018 22:38:44 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation
  Return directly after a failed kzalloc()

 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/msm/mdp5: Delete an error message for a failed memory allocation in two functions

2018-02-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Wed, 7 Feb 2018 21:50:07 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 1 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 4 +---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 439e0a300e25..daa224df4457 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -717,7 +717,6 @@ struct mdp5_ctl_manager *mdp5_ctlm_init(struct drm_device 
*dev,
 
ctl_mgr = kzalloc(sizeof(*ctl_mgr), GFP_KERNEL);
if (!ctl_mgr) {
-   dev_err(dev->dev, "failed to allocate CTL manager\n");
ret = -ENOMEM;
goto fail;
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 3e9bba4d6624..5bf54ca7ab0a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -844,10 +844,8 @@ static int interface_init(struct mdp5_kms *mdp5_kms)
continue;
 
intf = kzalloc(sizeof(*intf), GFP_KERNEL);
-   if (!intf) {
-   dev_err(dev->dev, "failed to construct INTF%d\n", i);
+   if (!intf)
return -ENOMEM;
-   }
 
intf->num = i;
intf->type = intf_types[i];
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/tegra/fb: Delete an error message for a failed memory allocation in tegra_fbdev_create()

2018-02-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Wed, 7 Feb 2018 21:17:17 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tegra/fb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 001cb77e2f59..e63a0b228751 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -325,10 +325,8 @@ static struct tegra_fbdev *tegra_fbdev_create(struct 
drm_device *drm)
struct tegra_fbdev *fbdev;
 
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
-   if (!fbdev) {
-   dev_err(drm->dev, "failed to allocate DRM fbdev\n");
+   if (!fbdev)
return ERR_PTR(-ENOMEM);
-   }
 
drm_fb_helper_prepare(drm, &fbdev->base, &tegra_fb_helper_funcs);
 
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm/tilcdc: panel: Use common error handling code in of_get_panel_info()

2018-02-06 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 6 Feb 2018 22:10:11 +0100

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 0b6aa95aec89..cf9ca16fee81 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -289,10 +289,8 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
device_node *np)
}
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-   if (!info) {
-   of_node_put(info_np);
-   return NULL;
-   }
+   if (!info)
+   goto put_node;
 
ret |= of_property_read_u32(info_np, "ac-bias", &info->ac_bias);
ret |= of_property_read_u32(info_np, "ac-bias-intrpt", 
&info->ac_bias_intrpt);
@@ -311,11 +309,11 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
device_node *np)
if (ret) {
pr_err("%s: error reading panel-info properties\n", __func__);
kfree(info);
-   of_node_put(info_np);
-   return NULL;
+   info = NULL;
}
-   of_node_put(info_np);
 
+put_node:
+   of_node_put(info_np);
return info;
 }
 
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] drm/tilcdc: Delete an error message for a failed memory allocation in seven functions

2018-02-06 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 6 Feb 2018 21:51:15 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 4 +---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 4 +---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 9 ++---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 8 ++--
 4 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 8bf6bb93dc79..1b278a22c8b7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -994,10 +994,8 @@ int tilcdc_crtc_create(struct drm_device *dev)
int ret;
 
tilcdc_crtc = devm_kzalloc(dev->dev, sizeof(*tilcdc_crtc), GFP_KERNEL);
-   if (!tilcdc_crtc) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!tilcdc_crtc)
return -ENOMEM;
-   }
 
init_completion(&tilcdc_crtc->palette_loaded);
tilcdc_crtc->palette_base = dmam_alloc_coherent(dev->dev,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 1afde61f1247..b8a5e4ed22e6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -233,10 +233,8 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
int ret;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   dev_err(dev, "failed to allocate private data\n");
+   if (!priv)
return -ENOMEM;
-   }
 
ddev = drm_dev_alloc(ddrv, dev);
if (IS_ERR(ddev))
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 8eebb5f826a6..0b6aa95aec89 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -101,10 +101,8 @@ static struct drm_encoder *panel_encoder_create(struct 
drm_device *dev,
 
panel_encoder = devm_kzalloc(dev->dev, sizeof(*panel_encoder),
 GFP_KERNEL);
-   if (!panel_encoder) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!panel_encoder)
return NULL;
-   }
 
panel_encoder->mod = mod;
 
@@ -210,10 +208,8 @@ static struct drm_connector *panel_connector_create(struct 
drm_device *dev,
 
panel_connector = devm_kzalloc(dev->dev, sizeof(*panel_connector),
   GFP_KERNEL);
-   if (!panel_connector) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!panel_connector)
return NULL;
-   }
 
panel_connector->encoder = encoder;
panel_connector->mod = mod;
@@ -294,7 +290,6 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
device_node *np)
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
-   pr_err("%s: allocation failed\n", __func__);
of_node_put(info_np);
return NULL;
}
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 7e3643462a08..c45cabb38db0 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -111,10 +111,8 @@ static struct drm_encoder *tfp410_encoder_create(struct 
drm_device *dev,
 
tfp410_encoder = devm_kzalloc(dev->dev, sizeof(*tfp410_encoder),
  GFP_KERNEL);
-   if (!tfp410_encoder) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!tfp410_encoder)
return NULL;
-   }
 
tfp410_encoder->dpms = DRM_MODE_DPMS_OFF;
tfp410_encoder->mod = mod;
@@ -224,10 +222,8 @@ static struct drm_connector 
*tfp410_connector_create(struct drm_device *dev,
 
tfp410_connector = devm_kzalloc(dev->dev, sizeof(*tfp410_connector),
GFP_KERNEL);
-   if (!tfp410_connector) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!tfp410_connector)
return NULL;
-   }
 
tfp410_connector->encoder = encoder;
tfp410_connector->mod = mod;
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/2] GPU-DRM-TILCDC: Adjustments for seven function implementations

2018-02-06 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 6 Feb 2018 22:17:44 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation in seven functions
  Use common error handling code in of_get_panel_info()

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  4 +---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  4 +---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 21 +++--
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  8 ++--
 4 files changed, 11 insertions(+), 26 deletions(-)

-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/amdgpu: Use seq_putc() in two functions

2018-01-12 Thread SF Markus Elfring
From: Markus Elfring 
Date: Fri, 12 Jan 2018 22:08:50 +0100

A few single characters should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  | 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 10805edcf964..7ac233f5abe2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -806,8 +806,8 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr, 
void *data)
pin_count = READ_ONCE(bo->pin_count);
if (pin_count)
seq_printf(m, " pin count %d", pin_count);
-   seq_printf(m, "\n");
 
+   seq_putc(m, '\n');
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
index 3144400435b7..57ce42d960ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
@@ -419,11 +419,8 @@ void amdgpu_sa_bo_dump_debug_info(struct amdgpu_sa_manager 
*sa_manager,
list_for_each_entry(i, &sa_manager->olist, olist) {
uint64_t soffset = i->soffset + sa_manager->gpu_addr;
uint64_t eoffset = i->eoffset + sa_manager->gpu_addr;
-   if (&i->olist == sa_manager->hole) {
-   seq_printf(m, ">");
-   } else {
-   seq_printf(m, " ");
-   }
+
+   seq_putc(m, (&i->olist == sa_manager->hole) ? '>' : ' ');
seq_printf(m, "[0x%010llx 0x%010llx] size %8lld",
   soffset, eoffset, eoffset - soffset);
 
@@ -431,7 +428,7 @@ void amdgpu_sa_bo_dump_debug_info(struct amdgpu_sa_manager 
*sa_manager,
seq_printf(m, " protected by 0x%08x on context %llu",
   i->fence->seqno, i->fence->context);
 
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
}
spin_unlock(&sa_manager->wq.lock);
 }
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2] video: ssd1307fb: Improve a size determination in ssd1307fb_probe()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 19:27:28 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105".

 drivers/video/fbdev/ssd1307fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index f599520374dd..6439231f2db2 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -628,7 +628,8 @@ static int ssd1307fb_probe(struct i2c_client *client,
goto fb_alloc_error;
}
 
-   ssd1307fb_defio = devm_kzalloc(&client->dev, sizeof(struct 
fb_deferred_io), GFP_KERNEL);
+   ssd1307fb_defio = devm_kzalloc(&client->dev, sizeof(*ssd1307fb_defio),
+  GFP_KERNEL);
if (!ssd1307fb_defio) {
dev_err(&client->dev, "Couldn't allocate deferred io.\n");
ret = -ENOMEM;
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 3/3] video: smscufx: Delete an error message for a failed memory allocation in ufx_realloc_framebuffer()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 16:12:40 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v3:
This update suggestion was rebased on source files from the software
"Linux next-20180105".

 drivers/video/fbdev/smscufx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index abbded605d68..22b606af0a87 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1307,10 +1307,8 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev, 
struct fb_info *info)
 * Alloc system memory for virtual framebuffer
 */
new_fb = vmalloc(new_len);
-   if (!new_fb) {
-   pr_err("Virtual framebuffer alloc failed");
+   if (!new_fb)
return -ENOMEM;
-   }
 
if (info->screen_base) {
memcpy(new_fb, old_fb, old_len);
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 2/3] video: smscufx: Return an error code only as a constant in ufx_realloc_framebuffer()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 16:07:11 +0100

* Return an error code without storing it in an intermediate variable.

* Delete the label "error" and local variable "retval"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---

v3:
This update suggestion was rebased on source files from the software
"Linux next-20180105".

 drivers/video/fbdev/smscufx.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 893daeb1ffd9..abbded605d68 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1293,7 +1293,6 @@ static struct fb_ops ufx_ops = {
  * Assumes no active clients have framebuffer open */
 static int ufx_realloc_framebuffer(struct ufx_data *dev, struct fb_info *info)
 {
-   int retval = -ENOMEM;
int old_len = info->fix.smem_len;
int new_len;
unsigned char *old_fb = info->screen_base;
@@ -1310,7 +1309,7 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev, 
struct fb_info *info)
new_fb = vmalloc(new_len);
if (!new_fb) {
pr_err("Virtual framebuffer alloc failed");
-   goto error;
+   return -ENOMEM;
}
 
if (info->screen_base) {
@@ -1323,11 +1322,7 @@ static int ufx_realloc_framebuffer(struct ufx_data *dev, 
struct fb_info *info)
info->fix.smem_start = (unsigned long) new_fb;
info->flags = smscufx_info_flags;
}
-
-   retval = 0;
-
-error:
-   return retval;
+   return 0;
 }
 
 /* sets up I2C Controller for 100 Kbps, std. speed, 7-bit addr, master,
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/3] video: smscufx: Less checks in ufx_usb_probe() after error detection

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 15:56:11 +0100

Up to four checks could be repeated by the ufx_usb_probe() function
during error handling even if the relevant properties can be determined
for the involved variables before by source code analysis.

* Return directly after a call of the function "kzalloc" failed
  at the beginning.

* Adjust jump targets so that extra checks can be omitted at the end.

* Delete initialisations for the variables "info" and "retval"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---

v3:
This update suggestion was rebased on source files from the software
"Linux next-20180105".

v2:
A call of the function "fb_dealloc_cmap" was preserved for the exception
handling at the end.

 drivers/video/fbdev/smscufx.c | 46 ++-
 1 file changed, 19 insertions(+), 27 deletions(-)

diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index 8db7085e5d1a..893daeb1ffd9 100644
--- a/drivers/video/fbdev/smscufx.c
+++ b/drivers/video/fbdev/smscufx.c
@@ -1620,8 +1620,8 @@ static int ufx_usb_probe(struct usb_interface *interface,
 {
struct usb_device *usbdev;
struct ufx_data *dev;
-   struct fb_info *info = NULL;
-   int retval = -ENOMEM;
+   struct fb_info *info;
+   int retval;
u32 id_rev, fpga_rev;
 
/* usb initialization */
@@ -1631,7 +1631,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
dev_err(&usbdev->dev, "ufx_usb_probe: failed alloc of dev 
struct\n");
-   goto error;
+   return -ENOMEM;
}
 
/* we need to wait for both usb and fbdev to spin down on disconnect */
@@ -1652,9 +1652,8 @@ static int ufx_usb_probe(struct usb_interface *interface,
dev_dbg(dev->gdev, "fb_defio enable=%d\n", fb_defio);
 
if (!ufx_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
-   retval = -ENOMEM;
dev_err(dev->gdev, "ufx_alloc_urb_list failed\n");
-   goto error;
+   goto e_nomem;
}
 
/* We don't register a new USB class. Our client interface is fbdev */
@@ -1662,9 +1661,8 @@ static int ufx_usb_probe(struct usb_interface *interface,
/* allocates framebuffer driver structure, not framebuffer memory */
info = framebuffer_alloc(0, &usbdev->dev);
if (!info) {
-   retval = -ENOMEM;
dev_err(dev->gdev, "framebuffer_alloc failed\n");
-   goto error;
+   goto e_nomem;
}
 
dev->info = info;
@@ -1675,7 +1673,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
retval = fb_alloc_cmap(&info->cmap, 256, 0);
if (retval < 0) {
dev_err(dev->gdev, "fb_alloc_cmap failed %x\n", retval);
-   goto error;
+   goto destroy_modedb;
}
 
INIT_DELAYED_WORK(&dev->free_framebuffer_work,
@@ -1736,26 +1734,20 @@ static int ufx_usb_probe(struct usb_interface 
*interface,
return 0;
 
 error:
-   if (dev) {
-   if (info) {
-   if (info->cmap.len != 0)
-   fb_dealloc_cmap(&info->cmap);
-   if (info->monspecs.modedb)
-   fb_destroy_modedb(info->monspecs.modedb);
-   vfree(info->screen_base);
-
-   fb_destroy_modelist(&info->modelist);
-
-   framebuffer_release(info);
-   }
-
-   kref_put(&dev->kref, ufx_free); /* ref for framebuffer */
-   kref_put(&dev->kref, ufx_free); /* last ref from kref_init */
-
-   /* dev has been deallocated. Do not dereference */
-   }
-
+   fb_dealloc_cmap(&info->cmap);
+destroy_modedb:
+   fb_destroy_modedb(info->monspecs.modedb);
+   vfree(info->screen_base);
+   fb_destroy_modelist(&info->modelist);
+   framebuffer_release(info);
+put_ref:
+   kref_put(&dev->kref, ufx_free); /* ref for framebuffer */
+   kref_put(&dev->kref, ufx_free); /* last ref from kref_init */
return retval;
+
+e_nomem:
+   retval = -ENOMEM;
+   goto put_ref;
 }
 
 static void ufx_usb_disconnect(struct usb_interface *interface)
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 0/3] video-SMSC UFX: Adjustments for two function implementations

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 16:54:32 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Less checks in ufx_usb_probe() after error detection
  Return an error code only as a constant
in ufx_realloc_framebuffer()
  Delete an error message for a failed memory allocation
in ufx_realloc_framebuffer()

---

v3:
Rebased on Linux next-20180105.

 drivers/video/fbdev/smscufx.c | 59 ---
 1 file changed, 22 insertions(+), 37 deletions(-)

-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/2] video: udlfb: Delete an error message for a failed memory allocation in dlfb_realloc_framebuffer()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 14:07:36 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105" together with an other change combination.

 drivers/video/fbdev/udlfb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 560a6b6044a5..0c781b077aab 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1172,10 +1172,8 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
 * Alloc system memory for virtual framebuffer
 */
new_fb = vmalloc(new_len);
-   if (!new_fb) {
-   pr_err("Virtual framebuffer alloc failed\n");
+   if (!new_fb)
return -ENOMEM;
-   }
 
if (info->screen_base) {
memcpy(new_fb, old_fb, old_len);
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/2] video: udlfb: Return an error code only as a constant in dlfb_realloc_framebuffer()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 14:02:36 +0100

* Return an error code without storing it in an intermediate variable.

* Delete the label "error" and local variable "retval"
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105".

 drivers/video/fbdev/udlfb.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 99ce445986b3..560a6b6044a5 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1157,7 +1157,6 @@ static struct fb_ops dlfb_ops = {
  */
 static int dlfb_realloc_framebuffer(struct dlfb_data *dev, struct fb_info 
*info)
 {
-   int retval = -ENOMEM;
int old_len = info->fix.smem_len;
int new_len;
unsigned char *old_fb = info->screen_base;
@@ -1175,7 +1174,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
new_fb = vmalloc(new_len);
if (!new_fb) {
pr_err("Virtual framebuffer alloc failed\n");
-   goto error;
+   return -ENOMEM;
}
 
if (info->screen_base) {
@@ -1203,11 +1202,7 @@ static int dlfb_realloc_framebuffer(struct dlfb_data 
*dev, struct fb_info *info)
dev->backing_buffer = new_back;
}
}
-
-   retval = 0;
-
-error:
-   return retval;
+   return 0;
 }
 
 /*
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/2] video-UDLFB: Adjustments for dlfb_realloc_framebuffer()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 14:24:34 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Return an error code only as a constant
  Delete an error message for a failed memory allocation

---

v2:
Rebased on Linux next-20180105.

 drivers/video/fbdev/udlfb.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/2] video/fbdev/stifb: Delete an error message for a failed memory allocation in stifb_init_fb()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 12:34:22 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---

v2:
This update suggestion was rebased on source files from the software
"Linux next-20180105" together with a change for an error code.

 drivers/video/fbdev/stifb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 511a594889af..dec8efb4f256 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1126,10 +1126,8 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
int bpp, xres, yres;
 
fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
-   if (!fb) {
-   printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
+   if (!fb)
return -ENOMEM;
-   }

info = &fb->info;
 
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/2] video/fbdev/stifb: Return -ENOMEM after a failed kzalloc() in stifb_init_fb()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 11:33:59 +0100

Replace an error code for the indication of a memory allocation failure
in this function.

Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac ("Linux-2.6.12-rc2: Initial git 
repository build")
Suggested-by: Rolf Eike Beer 
Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/stifb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 6ded5c198998..511a594889af 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1128,7 +1128,7 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
fb = kzalloc(sizeof(*fb), GFP_ATOMIC);
if (!fb) {
printk(KERN_ERR "stifb: Could not allocate stifb structure\n");
-   return -ENODEV;
+   return -ENOMEM;
}

info = &fb->info;
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/2] video/fbdev/stifb: Adjustments for stifb_init_fb()

2018-01-07 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 7 Jan 2018 12:45:54 +0100

Two update suggestions were taken into account.

Markus Elfring (2):
  Return -ENOMEM after a failed kzalloc()
  Delete an error message for a failed memory allocation

 drivers/video/fbdev/stifb.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [0/4] video-UDLFB: Adjustments for five function implementations

2018-01-04 Thread SF Markus Elfring
>> * Do you find a Linux allocation failure report insufficient in this use 
>> case?
> 
> Yes,

Interesting …


> there is more information available currently in the driver and
> I see no real improvement in removing it.
> 
>> * Are you looking for any more clarification?
> 
> I will not apply any of such patches for now. The only exception
> being drivers that support hardware that can have only one instance
> in the system …

Thanks for your feedback.


> and the patch needs to be reviewed by a someone else than the author).

I am curious if this will ever happen again for my update suggestions
in such a software area.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [0/5] video-SMSC UFX: Adjustments for five function implementations

2017-12-29 Thread SF Markus Elfring
>>   Delete an error message for a failed memory allocation in two functions
> 
> This patch removes the information about the device for which the allocation 
> fails.

Should a Linux allocation failure report be sufficient here?


>>   Less checks in ufx_usb_probe() after error detection
> 
> This patch depends on the earlier patch (which is not being merged)

Partly, yes.


> so please re-base it if you want it to be applied.

Would you dare to pick another change possibility up from a patch hunk?


>>   Adjust three checks for null pointers
> 
> This patch contains unrelated change ({} braces addition) which should be 
> dropped.

I presented such an update approach so that warnings from the script 
“checkpatch.pl”
will be fixed together.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [0/2] video: ssd1307fb: Adjustments for ssd1307fb_probe()

2017-12-29 Thread SF Markus Elfring
>>   Delete an error message for a failed memory allocation
> 
> This patch removes the information about the device for which the allocation 
> fails.

How do you think about to take another look if a Linux allocation failure report
could be sufficient in this use case?


>>   Improve a size determination
> 
> This patch depends on the earlier patch (which is not being merged)

Partly, yes.


> so please re-base it if you want it to be applied.

Would you dare to reduce any context lines for this update step so that
such a small adjustment will still work?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [0/4] video-UDLFB: Adjustments for five function implementations

2017-12-29 Thread SF Markus Elfring
>>   Delete an error message for a failed memory allocation in two functions
> 
> This patch removes the information about the device for which the allocation 
> fails.

* Do you find a Linux allocation failure report insufficient in this use case?

* Are you looking for any more clarification?


>>   Improve a size determination in dlfb_alloc_urb_list()
> 
> Patch queued for 4.16, thanks.

Thanks for your acceptance of other change possibilities.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video/console/sticore: Delete an error message for a failed memory allocation in sti_try_rom_generic()

2017-12-05 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 5 Dec 2017 18:45:42 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/console/sticore.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
index d1d3796773aa..08b822656846 100644
--- a/drivers/video/console/sticore.c
+++ b/drivers/video/console/sticore.c
@@ -827,10 +827,8 @@ static struct sti_struct *sti_try_rom_generic(unsigned 
long address,
}

sti = kzalloc(sizeof(*sti), GFP_KERNEL);
-   if (!sti) {
-   printk(KERN_ERR "Not enough memory !\n");
+   if (!sti)
return NULL;
-   }
 
spin_lock_init(&sti->lock);
 
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] video: ARM CLCD: Improve a size determination in clcdfb_probe()

2017-12-05 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 5 Dec 2017 17:53:19 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/amba-clcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 79f5ebf23fcd..38c1f324ce15 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -967,7 +967,7 @@ static int clcdfb_probe(struct amba_device *dev, const 
struct amba_id *id)
goto out;
}
 
-   fb = kzalloc(sizeof(struct clcd_fb), GFP_KERNEL);
+   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (!fb) {
ret = -ENOMEM;
goto free_region;
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] video: ARM CLCD: Delete an error message for a failed memory allocation in clcdfb_probe()

2017-12-05 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 5 Dec 2017 17:50:11 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/amba-clcd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 36d25190b48c..79f5ebf23fcd 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -969,7 +969,6 @@ static int clcdfb_probe(struct amba_device *dev, const 
struct amba_id *id)
 
fb = kzalloc(sizeof(struct clcd_fb), GFP_KERNEL);
if (!fb) {
-   printk(KERN_INFO "CLCD: could not allocate new clcd_fb 
struct\n");
ret = -ENOMEM;
goto free_region;
}
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/2] video/fbdev/amba-clcd: Adjustments for clcdfb_probe()

2017-12-05 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 5 Dec 2017 18:07:06 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation
  Improve a size determination

 drivers/video/fbdev/amba-clcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-12-03 Thread SF Markus Elfring
> How many times have I told you to include the reason for your patches
> in your proposed commit message?

Will it be useful to look again at the involved circumstances?


> Too often.

Did I answer any concerns partly?


> Many people do not know that a generic kmalloc does a dump_stack() on OOM.

Do you see a need to represent such information better?

Is it expected that the function “devm_kzalloc” has got a similar property?


> That information should be part of the commit message.

How do you think about to share it also from any reference documentation
in a clearer way?

Do we stumble on a target conflict in this case?

I am generally trying to improve the software situation to some degree.
I prefer then to work with safe information sources.
Unfortunately, I might have not reached a desired confidence level here
for a more detailed commit message. I assume that software development
efforts could increase in significant ways if something should be improved
further in a direction I hope. But this could mean that time frames will
grow for corresponding clarifications.

* Does such a situation block progress on the deletion of other remaining
  questionable error messages?

* Would you like to increase the software development attention anyhow?



By the way:
It seems that my update suggestion for the directory “omapfb/dss”
could be superseded by the patch “omapfb: dss: Do not duplicate features data”
from Ladislav Michl.
https://patchwork.kernel.org/patch/10082027/
https://lkml.kernel.org/r/<20171129123308.GA26578@lenoch>

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
>> Additional improvement possibilities can be taken into account
>> after corresponding software development discussions, can't they?
> 
> Sure, but that is in contrary to all you replies.

Where do you see a contradiction in this case?


> I guess you are familiar with Documentation/process/submitting-patches.rst 
> chapter 8.

I hope so in principle.


> No matter that patch was generated or suggested by a tool, you sent
> it and normal review procedure follows.

This is generally fine.


> And here you ignored _all_ suggestions

I did not integrate a few of them for my commit message so far
because it seems that there are open issues for further clarification.

Do you want that I send a second approach for this software module
before your own evolving update suggestion?


> and concentrate solely on improving Coccinelle scripts.

I hope not.


> On kernel related lists suggestions to patch itself are discussed.

This is usual.


> Whenever you take them into account while developing Coccinelle
> is up to you (on the Cocci list).

This is also happening, isn't it?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
>> I am not going to “verify” your update suggestion by my evolving approaches
>> around the semantic patch language (Coccinelle software) at the moment.
> 
> As you are sending patches as Markus Elfring

I am contributing also some update suggestions.


> I would expect you take Coccinelle's suggestion into account

The proposed change is based on a semantic patch script which I developed
with the support of other well-known Linux contributors.


> and actually try to understand code before sending patch.

I concentrated my understanding on the concrete transformation pattern
in this use case.


> That suggestion may lead to actual bug in code which your patch just leaves
> unnoticed as it is not apparent from the patch itself

There can be other change possibilities left over as usual.


> (no, not talking about this very patch it all started with)

Thanks for your distinction.


> That said, I'm considering Markus Elfring being a human.

Thanks for this view.


> If you do not like reactions to your patches

I am looking for constructive responses. - Disagreements can trigger
special communication challenges.


> or are interested only in improving tool that generates them,

How do you think about to look at any more background information?

https://github.com/coccinelle/coccinelle/issues
https://systeme.lip6.fr/pipermail/cocci/


> it would be better to just setup a "tip bot for Markus
> Elfring" and let it send patches automatically.

There is already an other automatic source code analysis system active.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/coccinelle


> The way you are sending patches makes impression (at least to me),
> that you spent some time on fixing issue Coccinelle found

Yes. - This view is appropriate.


> and not just shut the warning up.

Additional improvement possibilities can be taken into account
after corresponding software development discussions, can't they?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
>> How will this aspect evolve further?
> 
> I do not follow.

Interesting …


> This is OMAP framebuffer driver, so in this case, there is zero variation.

How much are you interested to compare differences in build results
also for this software module because of varying parameters?

Which parameters were applied for your size comparisons so far?


> Could you, please, review following patch

I assume that other OMAP developers are in a better position to decide
about the deletion of extra memory allocations (instead of keeping
questionable error messages).


> and verify is it satisfies your automated static code analysis test?

I am not going to “verify” your update suggestion by my evolving approaches
around the semantic patch language (Coccinelle software) at the moment.

But I thank you for this contribution.
How will further feedback evolve for such an idea?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
>>> Many people do not know that a generic kmalloc does a
>>> dump_stack() on OOM.
>>
>> This is another interesting information, isn't it?
>>
>> It is expected that the function “devm_kzalloc” has got a similar property.
> 
> 
> You don't have to expect this.  Go look at the definition of devm_kzalloc
> and see whether it has the property or not.

I find that the corresponding documentation of these programming interfaces
is incomplete for a desired format which could be different than C source code.

https://elixir.free-electrons.com/linux/v4.15-rc1/source/include/linux/device.h#L657
https://elixir.free-electrons.com/linux/v4.15-rc1/source/drivers/base/devres.c#L763
https://www.kernel.org/doc/html/latest/driver-api/basics.html#c.devm_kmalloc

Can the Coccinelle software help more to determine desired function properties?


>> For which hardware and software combinations would you like to see
>> facts there?
> 
> This is not for Joe to decide,

This view is fine in principle.


> it's for the person who receives the patch to decide.

I am curious on further comments from these contributors.


> You could start with the ones for which the code actually compiles,
> using the standard make file and no special options, and a
> recent version of gcc.

The variation space could become too big to handle for me (alone).
How will this aspect evolve further?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
>> I got an other impression. The probability for disagreements is increasing
>> in relation to the number of contributors to which I show change 
>> possibilities.
> 
> No.  You should learn from the previous submissions what concerns people
> have and address them up front.

The concerns can vary as contributors and changes are different.

How would you like to “address” the data structure for a default allocation
failure report finally?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
> How many times have I told you to include the reason for
> your patches in your proposed commit message?

It might be useful to look again.


> Too often.

I answered this feedback to some degree.


> Many people do not know that a generic kmalloc does a
> dump_stack() on OOM.

This is another interesting information, isn't it?

It is expected that the function “devm_kzalloc” has got a similar property.


> That information should be part of the commit message.

How do you think about to provide it also in any reference documentation
in a clearer way?

I would be more confident then to copy it into my messages.
Do you want that I take your current answer as an official note
for my work (instead of waiting for adjustments of other areas)?


> Also removing the printk code reduces overall code size.

Such an effect can be nice if the involved contributors can agree on
the deletion of questionable error messages at all.


> The actual size reduction should be described in the
> commit message too.

For which hardware and software combinations would you like to see
facts there?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-28 Thread SF Markus Elfring
 It seems that I got no responses so far for clarification requests
 according to the documentation in a direction I hoped for.
>>>
>>> That's because you are pretty unresponsive to direction.
>>
>> From which places did you get this impression?
> 
> Perhaps from the text that you have written only four lines below.
> All comments are dismissed as "the usual mixture of disagreements and 
> acceptance".

A mixture will always evolve.

* Some acceptance might not need further considerations.

* But the disagreements are remembered differently.
  They have got a potential for further improvements in some areas.


> If you look at the patches sent by others, who learn from
> the feedback provided to them,

I am also learning to some degree continuously.


> there are not so many responses on the disagreements side.

How do you think about to look at the details for such an observation?


> So the mixture is not usual.

I find that it can be also a matter of statistics.


> Since you send lots of patches on the same issues,

Yes. - I am trying to fix some implementation details by the means
of source code analysis and corresponding transformation.
The patch count is still growing.


> there should be no disagreements at all at this point.

I got an other impression. The probability for disagreements is increasing
in relation to the number of contributors to which I show change possibilities.

There are also other open issues remaining which can get another
solution somehow.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-27 Thread SF Markus Elfring
>> It seems that I got no responses so far for clarification requests
>> according to the documentation in a direction I hoped for.
> 
> That's because you are pretty unresponsive to direction.

From which places did you get this impression?


> You've gotten _many_ replies to your patches

I got the usual mixture of disagreements and acceptance for
my selection of change possibilities.
Some constructive feedback was also provided which might need
further software development considerations.
Is the situation improvable here?


> to which you have seemingly decided to ignore.

You might eventually notice that I react to special information
occasionally with a big delay.

For which concrete details are you still waiting for a better
response from me?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-27 Thread SF Markus Elfring
> There is the generic stack dump on OOM so the module/line
> is already known.

Can such an implementation detail become better documented
than in C source code?


> The existence of these messages increases code size which
> also make the OOM condition slightly more likely.

Interesting view …


> Markus' commit messages are always really poor descriptions
> of why these removals are somewhat useful and the commit
> could/should/might be applied.

I agree that they could be improved for this transformation
pattern if other information sources would become clearer
for corresponding references.
It seems that I got no responses so far for clarification requests
according to the documentation in a direction I hoped for.

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 5/5] radeon_backlight: Delete a jump target in radeonfb_bl_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 22:03:03 +0100

* Replace a goto statement by a direct call of the function "kfree"
  in an if branch.

* Delete the jump label "error" which became unnecessary with
  this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/aty/radeon_backlight.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/aty/radeon_backlight.c 
b/drivers/video/fbdev/aty/radeon_backlight.c
index 7f7ed6f72ddb..3c5b8291e773 100644
--- a/drivers/video/fbdev/aty/radeon_backlight.c
+++ b/drivers/video/fbdev/aty/radeon_backlight.c
@@ -157,7 +157,8 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
if (IS_ERR(bd)) {
rinfo->info->bl_dev = NULL;
printk("radeonfb: Backlight registration failed\n");
-   goto error;
+   kfree(pdata);
+   return;
}
 
pdata->rinfo = rinfo;
@@ -188,11 +189,6 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
backlight_update_status(bd);
 
printk("radeonfb: Backlight initialized (%s)\n", name);
-
-   return;
-
-error:
-   kfree(pdata);
 }
 
 void radeonfb_bl_exit(struct radeonfb_info *rinfo)
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 4/5] radeon_backlight: Return directly after a failed kmalloc() in radeonfb_bl_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 21:50:28 +0100

Return directly after a call of the function "kmalloc" failed
at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/aty/radeon_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/aty/radeon_backlight.c 
b/drivers/video/fbdev/aty/radeon_backlight.c
index c5e0e3557cc2..7f7ed6f72ddb 100644
--- a/drivers/video/fbdev/aty/radeon_backlight.c
+++ b/drivers/video/fbdev/aty/radeon_backlight.c
@@ -145,7 +145,7 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
 
pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
-   goto error;
+   return;
 
snprintf(name, sizeof(name), "radeonbl%d", rinfo->info->node);
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/5] radeon_backlight: Delete an unnecessary return statement in radeonfb_bl_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 21:37:52 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected function.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/aty/radeon_backlight.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/aty/radeon_backlight.c 
b/drivers/video/fbdev/aty/radeon_backlight.c
index 78c36c8d5e57..c5e0e3557cc2 100644
--- a/drivers/video/fbdev/aty/radeon_backlight.c
+++ b/drivers/video/fbdev/aty/radeon_backlight.c
@@ -193,7 +193,6 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
 
 error:
kfree(pdata);
-   return;
 }
 
 void radeonfb_bl_exit(struct radeonfb_info *rinfo)
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/5] radeon_backlight: Delete an error message for a failed memory allocation in radeonfb_bl_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 21:27:51 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/aty/radeon_backlight.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/aty/radeon_backlight.c 
b/drivers/video/fbdev/aty/radeon_backlight.c
index 301d6d6aeead..ce5b22d710b3 100644
--- a/drivers/video/fbdev/aty/radeon_backlight.c
+++ b/drivers/video/fbdev/aty/radeon_backlight.c
@@ -144,10 +144,8 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
 #endif
 
pdata = kmalloc(sizeof(struct radeon_bl_privdata), GFP_KERNEL);
-   if (!pdata) {
-   printk("radeonfb: Memory allocation failed\n");
+   if (!pdata)
goto error;
-   }
 
snprintf(name, sizeof(name), "radeonbl%d", rinfo->info->node);
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/5] radeon_backlight: Improve a size determination in radeonfb_bl_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 21:30:06 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/aty/radeon_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/aty/radeon_backlight.c 
b/drivers/video/fbdev/aty/radeon_backlight.c
index ce5b22d710b3..78c36c8d5e57 100644
--- a/drivers/video/fbdev/aty/radeon_backlight.c
+++ b/drivers/video/fbdev/aty/radeon_backlight.c
@@ -143,7 +143,7 @@ void radeonfb_bl_init(struct radeonfb_info *rinfo)
return;
 #endif
 
-   pdata = kmalloc(sizeof(struct radeon_bl_privdata), GFP_KERNEL);
+   pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
goto error;
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/5] Radeon backlight: Adjustments for radeonfb_bl_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 22:14:04 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (5):
  Delete an error message for a failed memory allocation
  Improve a size determination
  Delete an unnecessary return statement
  Return directly after a failed kmalloc()
  Delete a jump target

 drivers/video/fbdev/aty/radeon_backlight.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-27 Thread SF Markus Elfring
>> Can a default allocation failure report provide the information
>> which you might expect so far?
> 
> You should be able to answer that question yourself.

I can not answer this detail completely myself because my knowledge
is incomplete about your concrete expectations for the exception handling
which can lead to different views for the need of additional error messages.


> And if you are unable to do so, just do not sent changes pointed
> by any code analysis tools.

They can point aspects out for further software development considerations,
can't they?


> As a side note, if you look at whole call chain, you'll find quite some
> room for optimizations - look how dev and pdev are used. That also applies
> to other patches.

Would you prefer to improve the source code in other ways?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] video: au1100fb: Delete an unnecessary variable initialisation in au1100fb_drv_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 18:40:23 +0100

The local variable "fbdev" will be reassigned by a following statement.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/au1100fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index 1e5b872f0da6..7c9a672e9811 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -410,7 +410,7 @@ static int au1100fb_setup(struct au1100fb_device *fbdev)
 
 static int au1100fb_drv_probe(struct platform_device *dev)
 {
-   struct au1100fb_device *fbdev = NULL;
+   struct au1100fb_device *fbdev;
struct resource *regs_res;
unsigned long page;
struct clk *c;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] video: au1100fb: Improve a size determination in au1100fb_drv_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 18:18:34 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/au1100fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index cae17d02d804..1e5b872f0da6 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -416,8 +416,7 @@ static int au1100fb_drv_probe(struct platform_device *dev)
struct clk *c;
 
/* Allocate new device private */
-   fbdev = devm_kzalloc(&dev->dev, sizeof(struct au1100fb_device),
-GFP_KERNEL);
+   fbdev = devm_kzalloc(&dev->dev, sizeof(*fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] video: au1100fb: Delete an error message for a failed memory allocation in au1100fb_drv_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 18:14:41 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/au1100fb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index 8de42f617d16..cae17d02d804 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -418,10 +418,8 @@ static int au1100fb_drv_probe(struct platform_device *dev)
/* Allocate new device private */
fbdev = devm_kzalloc(&dev->dev, sizeof(struct au1100fb_device),
 GFP_KERNEL);
-   if (!fbdev) {
-   print_err("fail to allocate device private record");
+   if (!fbdev)
return -ENOMEM;
-   }
 
if (au1100fb_setup(fbdev))
goto failed;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/3] video/fbdev/au1100fb: Adjustments for au1100fb_drv_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 18:53:21 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation
  Improve a size determination
  Delete an unnecessary variable initialisation

 drivers/video/fbdev/au1100fb.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-27 Thread SF Markus Elfring
>> Omit an extra message for a memory allocation failure in these functions.
…
> nak, unlike many others, these message give extra info on which
> allocation failed, that can be useful.

Can a default allocation failure report provide the information
which you might expect so far?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: auo_k190x: Delete an error message for a failed memory allocation in auok190x_common_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 17:53:05 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/auo_k190x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/auo_k190x.c b/drivers/video/fbdev/auo_k190x.c
index 0d06038324e0..971d155d250f 100644
--- a/drivers/video/fbdev/auo_k190x.c
+++ b/drivers/video/fbdev/auo_k190x.c
@@ -1081,7 +1081,6 @@ int auok190x_common_probe(struct platform_device *pdev,
 sizeof(struct fb_deferred_io),
 GFP_KERNEL);
if (!info->fbdefio) {
-   dev_err(info->device, "Failed to allocate memory\n");
ret = -ENOMEM;
goto err_defio;
}
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: bf537-lq035: Delete an error message for a failed memory allocation in bfin_lq035_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 17:27:51 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/bf537-lq035.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/bf537-lq035.c 
b/drivers/video/fbdev/bf537-lq035.c
index ef29fb425122..5142e5724f57 100644
--- a/drivers/video/fbdev/bf537-lq035.c
+++ b/drivers/video/fbdev/bf537-lq035.c
@@ -741,7 +741,6 @@ static int bfin_lq035_probe(struct platform_device *pdev)
sizeof(u32) * 16,
GFP_KERNEL);
if (bfin_lq035_fb.pseudo_palette == NULL) {
-   pr_err("failed to allocate pseudo_palette\n");
ret = -ENOMEM;
goto out_table;
}
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: bf54x-lq043fb: Delete an error message for a failed memory allocation in bfin_bf54x_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 11:04:22 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/bf54x-lq043fb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/video/fbdev/bf54x-lq043fb.c 
b/drivers/video/fbdev/bf54x-lq043fb.c
index 8f1f97c75619..69a8c5d82ad7 100644
--- a/drivers/video/fbdev/bf54x-lq043fb.c
+++ b/drivers/video/fbdev/bf54x-lq043fb.c
@@ -605,9 +605,6 @@ static int bfin_bf54x_probe(struct platform_device *pdev)
fbinfo->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
  GFP_KERNEL);
if (!fbinfo->pseudo_palette) {
-   printk(KERN_ERR DRIVER_NAME
-  "Fail to allocate pseudo_palette\n");
-
ret = -ENOMEM;
goto out4;
}
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: adv7393fb: Delete two error messages for a failed memory allocation in bfin_adv7393_fb_probe()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 10:33:19 +0100

Omit extra messages for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/bfin_adv7393fb.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/bfin_adv7393fb.c 
b/drivers/video/fbdev/bfin_adv7393fb.c
index 542ffaddc6ab..aed6b934f009 100644
--- a/drivers/video/fbdev/bfin_adv7393fb.c
+++ b/drivers/video/fbdev/bfin_adv7393fb.c
@@ -389,10 +389,8 @@ static int bfin_adv7393_fb_probe(struct i2c_client *client,
}
 
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
-   if (!fbdev) {
-   dev_err(&client->dev, "failed to allocate device private 
record");
+   if (!fbdev)
return -ENOMEM;
-   }
 
i2c_set_clientdata(client, fbdev);
 
@@ -461,7 +459,6 @@ static int bfin_adv7393_fb_probe(struct i2c_client *client,
 
fbdev->info.pseudo_palette = kzalloc(sizeof(u32) * 16, GFP_KERNEL);
if (!fbdev->info.pseudo_palette) {
-   dev_err(&client->dev, "failed to allocate pseudo_palette\n");
ret = -ENOMEM;
goto free_fb_mem;
}
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: fb_ddc: Delete an error message for a failed memory allocation in fb_do_probe_ddc_edid()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 10:12:26 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/core/fb_ddc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/core/fb_ddc.c 
b/drivers/video/fbdev/core/fb_ddc.c
index 8bf5f2f54be7..256b518d1db9 100644
--- a/drivers/video/fbdev/core/fb_ddc.c
+++ b/drivers/video/fbdev/core/fb_ddc.c
@@ -37,11 +37,8 @@ static unsigned char *fb_do_probe_ddc_edid(struct 
i2c_adapter *adapter)
}
};
 
-   if (!buf) {
-   dev_warn(&adapter->dev, "unable to allocate memory for EDID "
-"block.\n");
+   if (!buf)
return NULL;
-   }
 
if (i2c_transfer(adapter, msgs, 2) == 2)
return buf;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: fsl-diu-fb: Delete an error message for a failed memory allocation in fsl_diu_init()

2017-11-27 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 27 Nov 2017 09:56:09 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/fsl-diu-fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 25abbcf38913..1bfd13cbd4e3 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -1960,12 +1960,8 @@ static int __init fsl_diu_init(void)
 
of_node_put(np);
coherence_data = vmalloc(coherence_data_size);
-   if (!coherence_data) {
-   pr_err("fsl-diu-fb: could not allocate coherence data "
-  "(size=%zu)\n", coherence_data_size);
+   if (!coherence_data)
return -ENOMEM;
-   }
-
 #endif
 
ret = platform_driver_register(&fsl_diu_driver);
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] video: matroxfb: Delete an error message for a failed memory allocation in matroxfb_crtc2_probe()

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 22:13:55 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/matrox/matroxfb_crtc2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_crtc2.c 
b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
index 02796a4317a9..f64e1d55d7a1 100644
--- a/drivers/video/fbdev/matrox/matroxfb_crtc2.c
+++ b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
@@ -696,10 +696,9 @@ static void* matroxfb_crtc2_probe(struct matrox_fb_info* 
minfo) {
if (!minfo->devflags.crtc2)
return NULL;
m2info = kzalloc(sizeof(*m2info), GFP_KERNEL);
-   if (!m2info) {
-   printk(KERN_ERR "matroxfb_crtc2: Not enough memory for CRTC2 
control structs\n");
+   if (!m2info)
return NULL;
-   }
+
m2info->primary_dev = minfo;
if (matroxfb_dh_registerfb(m2info)) {
kfree(m2info);
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] video: fbdev-MMP: Improve a size determination in path_init()

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 21:21:33 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c 
b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
index 9f912ea0bfce..fcdbb2df137f 100644
--- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
@@ -406,7 +406,7 @@ static int path_init(struct mmphw_path_plat *path_plat,
dev_info(ctrl->dev, "%s: %s\n", __func__, config->name);
 
/* init driver data */
-   path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
+   path_info = kzalloc(sizeof(*path_info), GFP_KERNEL);
if (!path_info)
return 0;
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] video: fbdev-MMP: Delete an error message for a failed memory allocation in two functions

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 21:16:30 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/mmp/fb/mmpfb.c| 5 ++---
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 6 ++
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/mmp/fb/mmpfb.c 
b/drivers/video/fbdev/mmp/fb/mmpfb.c
index 92279e02dd94..292b3e403044 100644
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@ -495,10 +495,9 @@ static int modes_setup(struct mmpfb_info *fbi)
/* put videomode list to info structure */
videomodes = kzalloc(sizeof(struct fb_videomode) * videomode_num,
GFP_KERNEL);
-   if (!videomodes) {
-   dev_err(fbi->dev, "can't malloc video modes\n");
+   if (!videomodes)
return -ENOMEM;
-   }
+
for (i = 0; i < videomode_num; i++)
mmpmode_to_fbmode(&videomodes[i], &mmp_modes[i]);
fb_videomode_to_modelist(videomodes, videomode_num, &info->modelist);
diff --git a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c 
b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
index b6f83d5df9fd..9f912ea0bfce 100644
--- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
@@ -407,11 +407,9 @@ static int path_init(struct mmphw_path_plat *path_plat,
 
/* init driver data */
path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
-   if (!path_info) {
-   dev_err(ctrl->dev, "%s: unable to alloc path_info for %s\n",
-   __func__, config->name);
+   if (!path_info)
return 0;
-   }
+
path_info->name = config->name;
path_info->id = path_plat->id;
path_info->dev = ctrl->dev;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 0/2] video/fbdev/mmp: Adjustments for two function implementations

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 21:38:42 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation in two functions
  Improve a size determination in path_init()

 drivers/video/fbdev/mmp/fb/mmpfb.c| 5 ++---
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 8 +++-
 2 files changed, 5 insertions(+), 8 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 19:46:09 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap2/omapfb/dss/dispc.c| 4 +---
 drivers/video/fbdev/omap2/omapfb/dss/dss.c  | 4 +---
 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 4 +---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 7a75dfda9845..10164a3bae4a 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -3982,10 +3982,8 @@ static int dispc_init_features(struct platform_device 
*pdev)
struct dispc_features *dst;
 
dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(&pdev->dev, "Failed to allocate DISPC Features\n");
+   if (!dst)
return -ENOMEM;
-   }
 
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 48c6500c24e1..a5de13777e2b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -893,10 +893,8 @@ static int dss_init_features(struct platform_device *pdev)
struct dss_features *dst;
 
dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(&pdev->dev, "Failed to allocate local DSS Features\n");
+   if (!dst)
return -ENOMEM;
-   }
 
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c 
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
index 9a13c35fd6d8..d25eea10c665 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
@@ -195,10 +195,8 @@ static int hdmi_phy_init_features(struct platform_device 
*pdev)
const struct hdmi_phy_features *src;
 
dst = devm_kzalloc(&pdev->dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(&pdev->dev, "Failed to allocate HDMI PHY Features\n");
+   if (!dst)
return -ENOMEM;
-   }
 
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP4430_ES1:
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] video: omap: Delete an error message for a failed memory allocation in mipid_spi_probe()

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 18:21:25 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap/lcd_mipid.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/omap/lcd_mipid.c 
b/drivers/video/fbdev/omap/lcd_mipid.c
index e3a85432f926..e71b674b47d8 100644
--- a/drivers/video/fbdev/omap/lcd_mipid.c
+++ b/drivers/video/fbdev/omap/lcd_mipid.c
@@ -564,10 +564,8 @@ static int mipid_spi_probe(struct spi_device *spi)
int r;
 
md = kzalloc(sizeof(*md), GFP_KERNEL);
-   if (md == NULL) {
-   dev_err(&spi->dev, "out of memory\n");
+   if (!md)
return -ENOMEM;
-   }
 
spi->mode = SPI_MODE_0;
md->spi = spi;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] video: omap: Improve a size determination in omapfb_do_probe()

2017-11-26 Thread SF Markus Elfring
From: Markus Elfring 
Date: Sun, 26 Nov 2017 18:16:20 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index b0d91524bf6c..c47059430ca8 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1645,7 +1645,7 @@ static int omapfb_do_probe(struct platform_device *pdev,
goto cleanup;
}
 
-   fbdev = kzalloc(sizeof(struct omapfb_device), GFP_KERNEL);
+   fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (fbdev == NULL) {
r = -ENOMEM;
goto cleanup;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


<    1   2   3   4   5   6   7   >