[PATCH 0/2] Industry-pack bus: Adjustments for two function implementations

[PATCH 0/2] Industry-pack bus: Adjustments for two function implementations

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 13 May 2017 10:45:54 +0200

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 ipack_device_read_id()
  Improve a size determination in ipack_bus_register()

 drivers/ipack/ipack.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.12.3

[PATCH 1/2] ipack: Delete an error message for a failed memory allocation in ipack_device_read_id()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 13 May 2017 10:20:07 +0200

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

This issue was detected by using the Coccinelle software.

Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/ipack/ipack.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
index 12102448fddd..575c4f29e0f7 100644
--- a/drivers/ipack/ipack.c
+++ b/drivers/ipack/ipack.c
@@ -402,7 +402,6 @@ static int ipack_device_read_id(struct ipack_device *dev)
 	 * ID ROM contents */
 	dev->id = kmalloc(dev->id_avail, GFP_KERNEL);
 	if (!dev->id) {
-		dev_err(&dev->dev, "dev->id alloc failed.\n");
 		ret = -ENOMEM;
 		goto out;
 	}
-- 
2.12.3

[PATCH 1/2] ipack: Delete an error message for a failed memory allocation in ipack_device_read_id()

[Samuel Iglesias Gonsálvez]

From: Markus Elfring <elfring@users.sourceforge.net>

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

This issue was detected by using the Coccinelle software.

Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
---

Greg, Would you mind picking this patch series through your char-misc tree?

Sam

 drivers/ipack/ipack.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
index 12102448fddd..575c4f29e0f7 100644
--- a/drivers/ipack/ipack.c
+++ b/drivers/ipack/ipack.c
@@ -402,7 +402,6 @@ static int ipack_device_read_id(struct ipack_device *dev)
 	 * ID ROM contents */
 	dev->id = kmalloc(dev->id_avail, GFP_KERNEL);
 	if (!dev->id) {
-		dev_err(&dev->dev, "dev->id alloc failed.\n");
 		ret = -ENOMEM;
 		goto out;
 	}
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Samuel Iglesias Gonsálvez]

From: Markus Elfring <elfring@users.sourceforge.net>

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.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
---
 drivers/ipack/ipack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
index 575c4f29e0f7..a1e07a77d4e6 100644
--- a/drivers/ipack/ipack.c
+++ b/drivers/ipack/ipack.c
@@ -212,7 +212,7 @@ struct ipack_bus_device *ipack_bus_register(struct device *parent, int slots,
 	int bus_nr;
 	struct ipack_bus_device *bus;
 
-	bus = kzalloc(sizeof(struct ipack_bus_device), GFP_KERNEL);
+	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
 	if (!bus)
 		return NULL;
 
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 13 May 2017 10:37:06 +0200

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.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/ipack/ipack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
index 575c4f29e0f7..a1e07a77d4e6 100644
--- a/drivers/ipack/ipack.c
+++ b/drivers/ipack/ipack.c
@@ -212,7 +212,7 @@ struct ipack_bus_device *ipack_bus_register(struct device *parent, int slots,
 	int bus_nr;
 	struct ipack_bus_device *bus;
 
-	bus = kzalloc(sizeof(struct ipack_bus_device), GFP_KERNEL);
+	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
 	if (!bus)
 		return NULL;
 
-- 
2.12.3

Re: [PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Samuel Iglesias Gonsálvez]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Hello Markus,

Thanks for the patches!

Series is,

Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>

Greg, Would you mind picking this patch series through your char-misc
tree?

Sam

On Sat, 2017-05-13 at 10:56 +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 13 May 2017 10:37:06 +0200
> 
> 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.
> 
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
>  drivers/ipack/ipack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
> index 575c4f29e0f7..a1e07a77d4e6 100644
> --- a/drivers/ipack/ipack.c
> +++ b/drivers/ipack/ipack.c
> @@ -212,7 +212,7 @@ struct ipack_bus_device
> *ipack_bus_register(struct device *parent, int slots,
>  	int bus_nr;
>  	struct ipack_bus_device *bus;
>  
> -	bus = kzalloc(sizeof(struct ipack_bus_device), GFP_KERNEL);
> +	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
>  	if (!bus)
>  		return NULL;
>  

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[Greg Kroah-Hartman]

On Mon, May 15, 2017 at 06:52:47AM +0200, Samuel Iglesias Gonsálvez wrote:
> Hello Markus,
> 
> Thanks for the patches!
> 
> Series is,
> 
> Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
> 
> Greg, Would you mind picking this patch series through your char-misc
> tree?

I'm sorry, but this person is in my blacklist and I don't have any of
their emails, so I don't have these patches anywhere.  If you wish to
have them applied, please resend them with your acked-by, or just ignore
them, it's up to you.

good luck!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ipack: Improve a size determination in ipack_bus_register()

[SF Markus Elfring]

>> Greg, Would you mind picking this patch series through your char-misc tree?
> 
> I'm sorry, but this person is in my blacklist

Some developers know this communication setting in the meantime.


> and I don't have any of their emails, so I don't have these patches anywhere.

I find this kind of feedback inappropriate.

You chose to exclude my update suggestions at a specific point in time.
They are still publicly available as they were stored also by other
information systems despite my messages vanish from your personal mail in-box
for a while.


> If you wish to have them applied, please resend them with your acked-by,

I am curious how other contributors will think about the shown change patterns.


> or just ignore them, it's up to you.

This reaction is also a possible option depending on your development priorities
for the affected software modules.

I hope that remaining open issues can be improved as desired after a bit of
constructive software development discussion.

Regards,
Markus